Security Maturity: Mature 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

As DevSecOps continues to gain traction, security teams are becoming part of the design and build process. The maturity required from both teams and their technologies to integrate seamlessly with their colleague’s process(es) 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:

Security Maturity, where the first three stages are making forward progress from Immature, Adolescent, to Mature, and the last stage of Geriatric regresses

Mature Technologies

Mature technologies have reached the apex of their field: they are well known, widely adopted, relatively straightforward to implement, appropriately priced - and most importantly, solve the problem(s) they were designed for exceptionally well. There are less than three companies today that I can think of who meet this criteria - which is both a sign of how difficult it is to build mature technologies, and a reflection of market pressures preventing companies from achieving this level of technological maturity.


Like all other technologies, products that reach this stage of maturity have had their share of growing pains - but the one thing that sets mature technologies apart from the rest is the focus placed on solving their customer’s problems simply, elegantly, and at scale. Yes they will have all of the usual capabilities you might expect in a mature technology, like a well documented API and useful out-of-the-box reporting, but there’s something different about the technologies in this category.

For mature technologies, it’s not about adding new capabilities - it’s about being the best in the market at solving the problem(s) they are designed to solve, and being very easy to use at scale. In many ways you might say that mature technologies follow the Unix principle of doing one thing exceedingly well.

On the other hand, what often causes otherwise great security products to tip into the geriatric category is a loss of focus. Acquiring and bundling newfangled solutions in a disjointed way, splitting the attention of the engineering organization to build new capabilities in order to explore market opportunities, and otherwise chasing new shiny ideas can lead to forgetting about the core capabilities which lead the company to produce a mature technology.


In regards to implementation, mature technologies make their products extremely easy to implement - and difficult to live without once you’ve put them to use. And while mature teams will be able to leverage such products to their fullest extent, mature technologies are generally approachable and useful for virtually all team maturity levels. The ease with which a product can be integrated into modern security practices is a definitive measure when it comes to technology maturity.

That being said, what leads to mature technologies aging into becoming geriatric technologies often comes from a failure to adapt the implementation to changes in customer environments and processes. For example, building software intended for on-premise environments has needed to adapt substantially to support implementation in the cloud. Some companies have done this well - but many have not. To avoid becoming a geriatric technology, companies need to keep up with the pace of innovation.

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! 🎉


Mature technologies generally cover all - if not a vast majority of - use cases which they help their customers solve for. This makes customization generally unnecessary - but when it is needed, mature technologies make the customization process simple and elegant. More than that, such technologies make customizations easy to develop and maintain at scale - ensuring they are reliable over long periods of time.

On the other hand, some mature technologies require a moderate amount of domain specific knowledge to develop customizations. The ease with which that knowledge can be found in hire-able talent or trained for is an excellent measure for how mature a technology is.

Although as customization becomes brittle and underlying functionality changes (or talent becomes hard to hire / train) over time, mature technologies eventually fade into a geriatric state. One such technology that comes to mind is mainframe systems. These systems continue to operate much of the world’s business processes - and businesses fear making changes to them lest the changes break significant elements of their revenue stream.


Mature technologies have it all when it comes to delivering proof of value - whether you want a PDF report, spreadsheet export, or data consumable via APIs or WebHooks, you can be sure that it’s readily available for your consumption. In many ways this is part of what makes mature technologies easy for teams of all maturity levels to adopt. If you can easily show that the solution is solving the problem it is designed for, it becomes that much easier to discuss the company’s return on its investment.

That being said, if mature technologies fail to keep up with process and environment changes over time they will some day wake up and find they’ve become a geriatric technology. For example, if a technology offers PDF reports and / or its own web portal as a means for consuming data - but does not integrate natively with the ways their customers are now working (such as developing from a centralized version control system), then the technology definitely hasn’t managed to keep up with the pace of innovation.


For mature technologies, success comes in the form of stability, reliability, and solving their customer’s problems at scale and / or over long periods of time. While I doubt many technologies will withstand the test of time given the pace of innovation today, I’m also mindful of the many companies now over 200 years old - with more than half residing in Japan. Given the ability to adapt to change, we might just witness a handful of today’s companies delivering mature technologies in the next century. Did you know that Nintendo was founded in 1889?

I digress. Anyway - the thing that makes mature technologies successful largely derives from being laser focused on their core capabilities - all while avoiding the urge to chase new, shiny market opportunities. When companies lose that focus, they almost always begin to slip into that degraded state of geriatric technologies as they begin to multi-task on new ideas to the detriment of their existing technologies and customers.

TL;DR / Summary

Mature technologies have reached the zenith of their industry, eclipsing the geriatric technologies who are waning - and outshining the immature and adolescent technologies still trying to ascend toward maturity. They have achieved this through focused dedication to their core capabilities, allowing them to solve customer’s problems simply, elegantly, and at scale. There are less than three companies today who’s products I would consider to be mature technologies, which is both a sign of how difficult it is to achieve this level of maturity - as well as a reflection on market pressures preventing companies from getting there.

What differentiates mature technologies from others is that they achieve “best in class” status through offering no-more-than a few capabilities that are done exceedingly well. This allows the company building a mature technology to focus on making the adoption process as seamless as possible - all while growing a community around the product due to how elegant their solution is.

And for those times when a mature technology requires some level of domain expertise to be useful, companies leverage the community to help market and sell their product by making the solution accessible to individuals - as well as offering trainings and certifications at a reasonable price (or free!). If a technology is good enough, word-of-mouth adoption will lead an early majority picking up the skills to use it - thus making it easier for companies to hire talent that can maximize the technology’s return on investment.

With regard to customization, mature technologies will cover most-of (if not all of) the use cases they help their customers solve for out-of-the-box. Even so, due to the dedicated focus on offering no more than a few capabilities that are exceptionally well built, customization is often fairly easy to implement when necessary because the company building the technology has focused on making the experience simple and elegant. There’s usually a lot of complicated effort going on behind the scenes to make this possible, but end-users don’t see or experience any of that in mature technologies.

Likewise, the data produced by mature technologies is often available in the exact format you want - whether that’s a PDF report, spreadsheet export, API endpoint, or WebHook event. The flexibility that mature technologies offer on this front make it easy for teams of varying maturity to adopt the solution and prove value quickly. Here again, the ability to consume the product’s data multiple ways is largely a result of the company’s focus on just a few core capabilities - which leaves room for delighting customers in other ways.

Finally, what makes mature technologies successful is their ability to deliver stable, reliable solutions that solve their customer’s problems at scale and / or over long periods of time. By offering a few capabilities performed exceedingly well, while also adapting the technology when business processes and systems evolve, mature technologies (and their companies) retain their market position far longer than the competition.

And when technologies eventually stray from their core capabilities, they regress toward becoming geriatric - but I’ll discuss more on that in my final post of this series 😉

As always, thanks again for stopping by to read my pseudo-random musing 😊 While I work on the next blog post about Geriatric Teams, you can git checkout other (usually off-topic) content I’m reading over at Instapaper, or read my {:target=”_blank”}{:rel=”noopener noreferrer”}.

Until next time, remember to git commit && stay classy!


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!

This post is licensed under CC BY 4.0 by the author.