Today we're going to discuss OWASP. More specifically, we'll focus on SAMM and how it pairs with DevOps.
If you're not familiar with OWASP or SAMM v2 (software assurance maturity model), everything can be found at https://owasp.org, along with some of the flagship projects.
There are several DevOps maturity models; however, they are exclusively for DevOps. SAMM v2 aims to add security to the software development life cycle (SDLC), in other words, it adds a secured layer to development operations.Useful for organizations small or big, SAMM adds assurance to the DevOps process.
In this All Day DevOps talk, Seba Deleersnyder (@sebadele) introduces SAMM v2 and walks us through the new features added in this version of the model, how it integrates into the DevOps workflow, and how it differentiates itself from other maturity models.
Why do I need a maturity model?
Before we get ahead of ourselves, you might be wondering why you need a maturity model.
Adding a security layer to the SDLC isn't easy. A maturity model like SAMM helps you with this by adding security levels in an iterative way, rather than in a "big bang" approach. SAMM is something you need to adapt to your development process. It's not a silver bullet for your day-to-day operation processes, and it must be adapted to your unique development target.
A good maturity model provides enough details to the users while being simple, well-defined, and measurable.
What's SAMM all about?
SAMM is, fundamentally, a set of security practices organized in five main business functions:
- Governance
- Design
- Implementation
- Verification
- Operations
Previously familiar users will see a new item: the implementation security practice.
This includes:
- Secure build
- Secure deployment
- Defect management
The new version incorporates these features given their increase in importance over the past years.
Defect management
Just for the sake of time, we're going to focus on just one of the new security practices: Defect management.
SAMM v2 is built following three levels of maturity and two streams, which we can easily compare with similar DevOps models. Maturity levels 1 through 3 are similar to what in other models are known as crawling, walking, and running. A simplified way to think through the different layers is:
- Maturity 1 means tracking all bugs and defects.
- Reaching maturity 2 would require fixing the errors.
- As the development process grows, we'd need to implement maturity 3, which includes adding agreements and compliances.
As with other DevOps practices, it's not a goal for every organization to reach maturity 3. Moreover, adapting the model or deciding which phases to integrate will depend on what suits your development operation. Several factors, like how quickly you move across different maturity levels, will have an impact on the final maturity level.
How do we get started?
To get started, we first need to assess the state of the development operation. A very straightforward tool we've included as part of the new release is a simple spreadsheet that's designed to feel like an interview. It'll measure your operations in terms of streams and maturity levels. Each level has questions linked to a security activity.
In the end, the tool provides a maturity score with color-coded results split by business function. It also provides the ability to add a roadmap with guidance on what to do next with security activities.
It's truly an educational tool for your organization.
Start applying SAMM
If you're not familiar with DevOps, a book called The Phoenix Project is a great place to start learning.
In essence, DevOps provide a list of common workflows within your development team to create value for your organization. Ideally, using the right model provides instant feedback cycles and a shared culture on how to improve as a team.
Adding security to the DevOps workflow should be part of the organization's culture. The process consists of three steps:
- Awareness training
- Security champions
- Security culture
Once your team goes through those, you include security practices to your typical DevOps cycle.
Should you need help with that, OWASP provides guidance, which is publicly available, in order to better orient people on where to start. Whether the model is agnostic or not, the process is very collaborative, and there's plenty of help available.
Visiting owaspsamm.org provides a community and living documentation. It mostly highlights the past version (v1.5), however, it's still relevant and worthwhile to browse the website.
By following a continuous integration process, the SAMM creators are able to iterate quickly and distribute information a lot faster. The information on the website is also broken down in easy to manage pieces.
What's next?
After SAMM v2, the improvements and iterations to the model can be applied faster, and, of course, there's a bigger community willing to help collaboratively. More OWASP references are on the way, along with more consistent guidance. People are now able to use the toolbox spreadsheet discussed above. Additionally, they'll include it as part of the website so that benchmarks can be provided.
Collaborating is easy through the OWASP Slack channel as well as in GitHub. You're also free to join the mailing list. You'll receive updates occasionally.
The SAMM v2 project is not a one-man show. It's a collaborative effort from an international team. By all means, everyone is welcome to join or sponsor the project.
