Security Maturity: Immature Technologies
TL;DR / Summary at the end of the post. The information shared in this series is derived from my experience building the DevSecOps program at Thermo Fisher Scientific (a global Fortune 100 laboratory sciences company).
Full Disclosure up-front: I am employed as a Code Scanning Architect at GitHub at the time of publishing this blog post.
Recapping Security Maturity in relation to DevSecOps
With the advent of DevSecOps, security has become part of the design and build process; the maturity required from both teams and their technologies in order to integrate seamlessly into the development process has changed significantly from the days of “put a firewall in front of it and call it done”.
As it stands today, Security Maturity - in terms of both teams and their technologies - can be measured across four stages based on the direction they’re heading in (forward ➡️ or backward ⬅️), and the outcomes they produce. I think of these four stages in terms of breadth and depth as follows:
Immature Technologies
While they are often the newest entries into a technology category, immature technologies can make for great experimental tools on a smaller scale - and will sometimes unlock new capabilities for mature teams. Unfortunately, immature teams are often sold on such technologies due to favorable pricing (in order for the vendor to gain market share) or industry popularity - for which they endure a lot of pain in the process of implementing such tools.
Capabilities
Immature technologies usually come to market with just one stand-out quality in regard to the Speed, Accuracy, or Completeness of the solution. I wrote a series of posts on this topic in the Static Analysis space, but to summarize what I mean: speed is how fast the technology completes its task; accuracy is about how actionable the results are; and completeness is how thorough the technology is with its assigned task.
In order for immature technologies to grow-up, they need to shore up at-least one of the other capabilities before moving on to other challenges. Unfortunately, they often overlook this important foundation and ride the hype train toward higher-order functionality - such as implementation.
Implementation
While immature technologies might be easy to implement for an individual or small team, the challenges they face in scalability make them difficult to use in a DevSecOps program. Coverage, usability, and ease of management at scale is no simple matter - and this is where many shortcomings of immature technologies come to light.
For example - even if you’ve deployed at scale, the update process post-deployment can often be a nightmare. Ensuring that you have the same version running across your ecosystem, with the same minimum baseline for checks, alerts, blocking, etc. is an infinite game. The moment you stop documenting and refining the system, the wheels come off.
Speaking of documentation, immature technologies tend to have either poor documentation (in terms of navigation, content, examples, etc.) or no documentation. This is a big reason why such technologies make for great experimental investments - but rarely make for great investments at scale.
How to support this content: If you find this post useful, enjoyable, or influential (and have the coin to spare) - you can support the content I create via Patreon.️ Thank you to those who already support this blog! 😊 And now, back to that content you were enjoying! 🎉
Customization
Immature technologies can be measured by how much customization they need (do they lack sensible defaults, completeness of coverage, etc.) and how easy it is to go about customizing the solution to fit the business’ needs. Does customizing require knowledge specific to the solution? Does it require knowledge of a language of some kind? Is that language easy to learn? Are there examples to work from?
Likewise, how flexible and precise can you be with customization? Are there open source projects where people develop customizations that you can pull into the solution? Immature technologies tend to leave customer’s wanting in both situations. This is where mature teams can help immature technologies grow by experimenting to find the problem/solution fit that the vendor can go back and invest in.
Data
With immature technologies, one of the greatest challenges is making the data they produce consumable by the target audience. Often this requires integration into other platforms that development, security, and/or operations teams utilize as a monitoring and alerting system or work queue.
The difficulty with immature technologies is that these integrations either don’t exist, or feel like they were built on a shoe-string budget in order to check a box during the sales process. To make up for this, immature technologies usually build APIs that their customers can pull from, which makes the data portable - at least when the documentation for the API is actually useful.
Success
When it comes to measuring success, immature technologies bank on popularity above all else. Don’t get me wrong - this is the life blood for new companies, as it tends to drive further venture capital rounds and increase market share. That being said, some companies never grow out of this phase; it shows in the ways they pull from their engineering and security budgets to pay for overblown marketing campaigns.
As immature technology companies mature, they work to turn that popularity into a community, with a lot of attention put on product support - and most importantly, customer outcomes. More on that will come in the next couple of technology posts in this series.
TL;DR / Summary
Immature technologies are often the newest players in a market sector, which sometimes offers mature teams the opportunity to expand their capabilities. Unfortunately, immature teams buy into these technologies due to favorable pricing (in order for the vendor to gain market share) or industry popularity. What such teams fail to realize is how much work goes into making the technology work for them.
When it comes to capabilities, immature technologies will usually check at-least one of the boxes when it comes to speed, accuracy, or completeness of the solution; if they are maturing as a product, they will usually get at least two of these right before moving on to implementation challenges.
And this is where immature technologies really differentiate themselves: they are easy for individuals and small teams to use - but difficult to implement, utilize, and manage at scale. This is why immature technologies make for great experimental purchases, but require more investment from the vendor in order for them to grow out of this stage.
Likewise, having sensible defaults and being able to customize the solution is increasingly becoming a differentiator when it comes to product maturity. The need for customization, as well as the ease with which customizations can be written and implemented, says a lot about modern products - and should be considered when making an investment in immature technologies.
Beyond customization, the data produced from technology investments needs to be useful for the target audience. To do this successfully at scale requires integrations which may not exist or be very fragile - which is again why mature teams can make better use of immature technologies than immature teams can.
Finally, immature technologies measure success on popularity. Sure, they need to be popular in order to raise their next venture round and/or grow market adoption - but maturing technologies recognize the value in building a community to support their product. On the other hand, immature technologies tend to pull from engineering and security budgets to pay for marketing hype at the expense of their product.
As always, thanks again for stopping by to read my pseudo-random musing 😊 While I work on the next blog post about Adolescent Teams, you can git checkout other (usually off-topic) content I’m reading over at Instapaper, or read my recent series on the DevSecOps Essentials.
Until next time, remember to git commit && stay classy!
Cheers,
Keith // securingdev
If you found this post useful or interesting, I invite you to support my content through Patreon 😊 and thanks once again to those who already support this content!😊