Electrifiedby vlvd.net

OWASP SAMM: assess and plan your software security program

OWASP SAMM, the Software Assurance Maturity Model, is a free framework for measuring how your organization builds secure software and planning what to improve next. You score yourself on 15 security practices, set a target for each, and turn the gap into a roadmap. The first four steps are planning work that one person can finish in one to two days, and this post walks you through them with an example.

If you want an outside view while you do it, whitehatstoic gives independent advice and tests web apps and AI systems, so your plan rests on both a written review and real test results.

OWASP SAMM in plain terms

The OWASP SAMM project page calls it an open framework to help organizations build and carry out a software security strategy tailored to their own risks. It says SAMM helps you do four things:

  • Evaluate the software security practices you already have.
  • Build a balanced security program in well-defined steps.
  • Show concrete improvements to that program.
  • Define and measure security activities across the organization.

SAMM is technology and process agnostic, and it is risk-driven on purpose, because, in the project's words, there is no single recipe that works for every organization. The latest version listed on the project page is 2.2.0.

The difference from a test standard matters. A standard like OWASP ASVS asks whether one application meets a list of requirements. SAMM asks how your team works: do you model threats, review architecture, test, and respond to incidents, and how consistently.

Five business functions, fifteen practices

The SAMM model splits software security into five business functions, each with three security practices.

Grid of the five OWASP SAMM business functions, Governance, Design, Implementation, Verification and Operations, each with its three security practices

From the OWASP SAMM model page.

  • Governance: Strategy and Metrics, Policy and Compliance, Education and Guidance.
  • Design: Threat Assessment, Security Requirements, Secure Architecture.
  • Implementation: Secure Build, Secure Deployment, Defect Management.
  • Verification: Architecture Assessment, Requirements-driven Testing, Security Testing.
  • Operations: Incident Management, Environment Management, Operational Management.

The spread is the point. Many teams put all their effort into testing and none into design or operations. Scoring all 15 makes that imbalance visible.

How maturity levels and streams work

Each practice has three maturity levels, and each level has its own objective. Each practice is also split into two streams, so you can be strong in one half and weak in the other.

Take Security Testing. Its first stream, Scalable Baseline, grows from using automated testing tools, to tests written for your own application, to automated testing built into the build and deploy process. Its second stream, Deep Understanding, grows from manual testing of high-risk components, to manual penetration testing, to security testing built into how you develop. The model's reasoning: the more bugs automation catches, the more time experts have for complex attacks and business logic.

Threat Assessment works the same way. Its Threat Modeling stream starts at maturity 1 with best-effort, risk-based threat modeling using brainstorming, existing diagrams and simple checklists. That is where most small teams can begin; our one-afternoon threat modeling plan is a practical way in.

Run your first assessment

SAMM's quick start guide has six steps: prepare, assess, set the target, define the plan, implement, and roll out. Preparing means defining the scope, naming the people involved and telling them why you are doing it. Scope can be one product, one team or the whole company. Start small.

For the assessment itself, the project offers a free toolbox as an Excel or Google spreadsheet. Its Interview tab lists questions for each activity in the model, each with quality criteria beneath it. The rule is strict: if the criteria are not completely met, the answer is "No". As you answer, the Scorecard tab works out your current maturity score.

Run the interview with the people who do the work, not only managers. A developer, a tester and whoever handles incidents will give a truer answer than a single lead filling in the sheet alone. SAMM's own guide says you can run the self-assessment together with others in your development process.

Set a target and build the roadmap

Step 3 is setting a target score that points you to the activities that matter most for your situation. Step 4 is a roadmap that takes you to the next maturity level. Do not aim for maturity 3 everywhere. Pick targets from your risk: a team that ships payments weekly needs Secure Build and Security Testing to move before Education and Guidance does.

Strategy and Metrics is the practice that holds this together. Its first level asks you to identify what drives your organization and its tolerance for risk, and to define metrics that show whether the program is working. Two or three honest numbers beat twenty that nobody reads.

Worked example: two days of planning for a small product team

Say you lead a ten-person team running one web app with sign-in and payments. You have no security lead. Here is steps 1 to 4 in two days.

  1. Morning, day 1: prepare. Set the scope to the one web app. Book two hours with a developer, your tester and whoever is on call.
  2. Afternoon, day 1: assess. Download the toolbox and work through the Interview tab together. Answer "No" wherever the criteria are not fully met. Note one line of evidence for every "Yes".
  3. Morning, day 2: set the target. Read the scorecard. Say it shows tools running in CI but no threat modeling, no written security requirements and no incident plan. Pick four practices to raise by one level each: Threat Assessment, Security Requirements, Incident Management and Security Testing's Deep Understanding stream.
  4. Afternoon, day 2: define the plan. Turn each into one dated action with an owner: a threat model of sign-in and payments, an ASVS level chosen as your security requirements, a one-page incident plan, and a manual test of the payment flow before the next major release.

That roadmap fits on one page. Steps 5 and 6, doing the work and making sure the whole team uses it, are where sustained effort starts, and the guide says they usually run in phases over months.

Keep it going after the first round

Run the assessment again after each phase of the roadmap, with the same scope and the same strict "No" rule, so the scores mean the same thing each time. A rising score in the practices you targeted is the concrete improvement SAMM is built to show.

Be honest about what a score is. It measures how your team works, not whether your app has weak spots today. Pair it with real tests, and with a way for outsiders to tell you what they find, such as a vulnerability disclosure policy.

Frequently asked questions

What is the difference between OWASP SAMM and ASVS?

SAMM measures how mature your organization's software security practices are. ASVS lists the security requirements one application should meet, so many teams use ASVS inside SAMM's Security Requirements and testing practices.

How long does a SAMM assessment take?

SAMM's quick start guide says one person can complete the first four steps, preparing, assessing, setting a target and planning, in one to two days. Carrying out the plan usually takes months, in phases.

Is OWASP SAMM free to use?

Yes. It is an open OWASP project, and the assessment toolbox is free to download as an Excel or Google spreadsheet.

Do small teams need SAMM?

A small team can use it lightly: one product in scope, one honest assessment, and a few targets raised by one level. The point is to spend effort where your risk is, not to score high everywhere.

Get started

A SAMM roadmap is easier to trust when someone outside the team checks it. whitehatstoic offers independent reviews, a plain written verdict on a project, codebase or vendor before you commit, and security tests on web apps and AI systems with a written report and fixes. Every engagement is scoped and priced after a short call.

Building something that has to be safe? Book a meeting with whitehatstoic: tell us the product, the deadline and your biggest worry, and we reply with a plan and a price.

Build it right. Test it thoroughly. Keep it safe.

Visit whitehatstoic.com
whitehatstoic on desktop
whitehatstoic on tablet
whitehatstoic on phone
0 likes

Comments

No comments yet.

or make an account to comment.