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 Principal Security Specialist at GitHub at the time of publishing this blog post.
With DevSecOps and Product Security gaining traction, security teams are quickly becoming essential during 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” - and it’s up to security teams to catch up.
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:
Geriatric technologies are the darling products of years past: they are well known, designed to solve yesterday’s problems, appear in the “top right” segments of market analysis materials, and have probably been acquired by a hedge fund or holding company that draws as much revenue (with as little investment) as possible. You’ve probably experienced immature teams trying to force the implementation of these technologies at some point in your career.