Press Release
Last Updated on January 19, 2024
Noted for its flexibility and comprehensiveness, the OWASP Software Assurance Maturity Model V2 (OWASP SAMM) is one of the top trusted frameworks for ensuring and validating software security. SAMM encompasses the end-to-end software development lifecycle (SDLC), from how you govern your software program to how you deploy and maintain production code.
How is SAMM organized and how does its organization support secure software development?
To cover critical details of OWASP SAMM, Taylor Smith, Network & Application Penetration Testing Lead at Pivot Point Security, joined a recent episode of The Virtual CISO Podcast. Pivot Point Security CISO and Managing Partner, John Verry, is the show’s host.
Governance
The first of SAMM’s 5 business functions is Governance. Like all the SAMM business functions, Governance is broken down into 3 practices: Strategy & Metrics, Policy & Compliance, and Education & Guidance.
Governance is about maintaining a development strategy and program, but a lot of those pieces relate to the overall company culture. It covers all the requirements associated with maintaining logs and metrics, meeting policies and complying with governmental and industry regulations. It also covers training staff to follow secure practices, which is challenging on the development side.
“Governance is more the management of people rather than strictly the application, and then strategy, metrics and compliance fall into that,” summarizes Taylor.
Design
Introducing security in the design phase is about securing the application from the core out, before it gets into production. This includes threat assessment (quantifying your attack risks), defining firm security requirements, and securing the application architecture.
“Suppliers come into this one a lot,” advises Taylor. “If you’re getting code or testing materials from someone else, that falls into the security requirements of design. It’s evaluating the supplier, making sure requirements are available for suppliers to see, and making sure you have all the documentation and maturity levels for that design element.”
Secure design is growing in importance with emphasis from the US federal government and elsewhere on a software bill of materials (SBOM) and ensuring that third-party libraries and APIs are secure.
Implementation
SAMM’s Implementation business function covers all the activities related to deployment, such as builds, versioning, and defect management. The different SAMM maturity levels relate to the process for handling the overall development pipeline and making sure nothing gets lost (or injected!) in the process, and that any defects are managed properly.
Taylor observes, “It’s like, ‘Okay, here are the things you need to have ready for deployment. Here are the things you need to have ready for release.’ A lot of basic protection measures. A lot of lifecycle tracking. Documentation all day long.”
Verification
No surprise since she’s a pen tester at heart, Verification is Taylor’s favorite SAMM business function.
Verification is making sure that all your security policies are working as intended. The three Verification practices are architecture assessment, requirements-driven testing, and security testing. Each of these practices calls for a different kind of assessment.
“Looking at your architecture, making sure you’ve got proper testing and documentation, and then having third-party or internal review of that documentation, architecture and inventory to make sure everything is where it’s supposed to be,” clarifies Taylor. “This is one of the harder areas to mature because you oftentimes need to get specially trained, and that can be very time-consuming. But once you’ve got that implemented into your development routine, it’s awesome.”
Operations
As you can tell from its three practices—incident management, environment management, and operational management—the Operations business function is all about management.
“It’s all the things you have to do every day to maintain the C-I-A triad,” recaps Taylor. “It’s the operational lifetime of an application and all the data it handles. It’s making sure that your confidentiality, integrity, and availability stick around.”
Operations can be challenging to mature because it’s always changing and there are multiple dependencies. Some of the Operations activities include logging data, documenting incident response processes, implementing environmental and operational controls, and managing access and users.
“It makes developers think in the long-term,” Taylor states. “When you’re building something and you’re on SCRUM and working day-to-day, and you finally get down to the crunch of an application, the idea of keeping it for 10, 15, 20 years can be really exhausting. So, this helps a lot.”
What’s next?
To listen to the full podcast with penetration testing expert Taylor Smith, click here.
Interested in application security testing? Here’s a post you’ll find useful: OWASP ASVS: Web Application Testing Comes of Age
Free OWASP ASVS Testing Guide
If you are just learning about OWASP’s testing standard or are considering the best way to prove the security of an application, this guide is meant for you!
