Every day, you are probably pestered with yet another story about AI taking over software development. A few years ago, they told everyone that we wouldn’t need developers anymore. In 2026, that hasn’t happened, and it doesn’t seem likely to happen anytime soon. Globally, there is a full spectrum of the level of AI integration into the software development lifecycle, from nothing to almost completely automated.
Several people and organizations are declaring how they see the new world of AI-Driven Development, AIDLC, AI-SDLC, AI-Native SDLC, and the list goes on. There is no consensus on what this should or will look like in the future. It ranges from using AI for various tasks in the SDLC to letting AI run almost everything.
You are being asked, “What do we do now?”
We are being asked, “Is SAMM still relevant?”
Let’s step back and look at how SAMM is structured. SAMM was originally built in 2008, when waterfall was the predominant software development methodology. When we updated SAMM to v2.0 in 2020, we added the Implementation business function to help address the work being done in DevOps and Agile. SAMM is built to be an abstract model for secure development and the supporting functions around it, like governance and operations. We have worked hard to abstract the goals of each of the security activities and streams so that it applies to waterfall, agile, agilefall, and many other methodologies and for many types of software, firmware, and so on. More than ever, we need to ensure we have an appropriate level of assurance for the software we develop and provide to users. AI may be doing more in the process, but we remain responsible and liable for the results.
We’ve reviewed the various new AI development models; most are focused on a much narrower space than SAMM covers. Many are largely ignoring or reducing the work in the design phases. Governance and Operations are generally ignored or left for someone else to address. We see people throwing away important security lessons learned the hard way over the last 20 years in the name of generating overwhelming amounts of code in a short amount of time. I thought we’d realized that measuring success in application development by counting lines of code (LoC) written was a losing endeavor, since it told you nothing about the application’s quality or resilience. Only that it was becoming harder and harder to maintain.
At this point, we’ve come to the conclusion that there are some places in the current SAMM model that should be updated to ensure that the language can be interpreted and applied when using AI in those areas. Without assuming everyone will use AI. Some questions and quality criteria will see updates in the near future to ensure that they are properly handling some of the new ways of designing, building, and validating software. We are also going to be publishing AI guidance for SAMM. This is basically a translation layer to help provide a link from the more abstract language in SAMM to how it may apply in an AI-centric development process.
In the longer term, we are keeping an eye on how AI is impacting software development. There may be a point where the whole methodology of software development changes into something no one expected or has seen before. The field is very fluid right now, and it wouldn’t help to try to chase it as a maturity model. One of the primary functions of a maturity model is to provide a solid, relevant foundation for measurable improvement in how people securely develop software. We would be doing the industry a disservice if we swayed with the breeze and changed SAMM weekly or monthly. It’s the same foundational reason that the OWASP Top 10 only updates every 3-4 years, as the industry needs some baselines and models to provide stable and foundational guidance.
Stable is not stale. If we didn’t update SAMM for several years, then we may run into a stale problem. However, we are actively researching and reviewing what is changing and checking it against how SAMM is built to help ensure that it is still providing appropriate and relevant guidance for organizations. We will continue to do this to ensure that SAMM remains one of the few stable software assurance maturity models to help organizations make measurable improvements in their secure development efforts.