--- title: "SAMM 0→3 in an SMB: 12 months, five practices, and the order that matters - OkamiOps Insights" description: "OWASP SAMM has 90 activities and a 0-to-3 scale per practice. In the official benchmark, dominated by multinationals, the average is 1.44 — and" url: https://okamiops.com/insights/appsec-maturity-smb-2026/ lang: en alternates: en: https://okamiops.com/insights/appsec-maturity-smb-2026/ pt-BR: https://okamiops.com/pt/insights/appsec-maturity-smb-2026/ de: https://okamiops.com/de/insights/appsec-maturity-smb-2026/ x-default: https://okamiops.com/insights/appsec-maturity-smb-2026/ lastmod: 2026-09-10 --- # SAMM 0→3 in an SMB: 12 months, five practices, and the order that matters APPSEC · FEV · 2026 · 8 min OWASP SAMM has 90 activities and a 0-to-3 scale per practice. In the official benchmark, dominated by multinationals, the average is 1.44 — and Verification sits at 1.12. The bar for mature is lower than the word suggests. With tight scope and the right order, an SMB reaches level 3 on the critical practices in four quarters. - **Category**: AppSec - **Date**: FEV · 2026 - **Read time**: 8 min - **Sources**: 8 Level 0 in OWASP SAMM doesn't mean the team is bad. It means the practice doesn't exist in any recognizable form: nobody wrote it down, nobody repeats it, nobody measures it. That's where almost every 20-to-200-person company starts, including the ones that have run CI/CD for years and have a scanner switched on somewhere. The question a client asks isn't what SAMM is worth. It's how long until this stops hurting. The honest answer: on the practices that matter, nine to twelve months. What holds you back isn't the model's complexity. It's the order in which you attack. **The roadmap in three numbers** - **9–12 months** — to level 3 on the critical practices - **5 practices** — concentrate the risk drop per euro invested - **8h + 2h /week** — one senior owner + 2h per squad, no dedicated hire ## The model is smaller than it looks SAMM v2 has five business functions: Governance, Design, Implementation, Verification and Operations. Each function holds three security practices, which makes fifteen. Each practice splits into two streams and each stream has three levels. Five times three times two times three: ninety activities. That's the whole model, and it fits in a spreadsheet. Level 0 is implicit — the activity doesn't happen. Level 1 usually means do it deliberately, even if ad hoc. Level 2 means standardize and automate. Level 3 means enforce it as a rule and optimize with data. The progression is the same across all fifteen practices, which makes the model predictable to plan around. SAMM's own guide says that preparing, assessing, setting the target and building the plan — the first four steps — take one person one to two days. Steps 5 and 6, execute and roll out, are what consume months. Diagnosis was never the bottleneck. The official benchmark calibrates expectations. It covers 30 assessments, more than 80% run by third-party assessors and around 60% coming from multinationals. The overall average is 1.44 out of 3.0. By function: Operations 1.81, Design 1.50, Implementation 1.46, Governance 1.35 and Verification 1.12. The report acknowledges that smaller companies are underrepresented. Read the lowest number again. Verification — security testing, requirements review, architecture assessment — sits at 1.12 in a set dominated by large companies. AppSec maturity is not a budget privilege. It's a consequence of method. ## The five practices that move risk first Not every practice pays the same. Five of them concentrate the risk reduction per euro invested, and the order among them matters more than the choice of tool. Secure Build. Level 1: the build process is written down and repeatable, and you keep a bill of materials of your dependencies. Level 2: automated pipeline, hardened build tooling, security checks running. Level 3: the checks are mandatory and building a non-compliant artifact fails. It's the cheapest jump of the set, because it's pipeline configuration and not team reorganization. And it's the only one that prevents regression. Secure Deployment. Level 1: formalized deployment, hardened tooling, restricted access to production secrets. Level 2: deployment automated across all stages, with security verification tests, and secrets injected dynamically from a vault, with human access audited. Level 3: the integrity of all deployed software verified automatically. Cheap up to level 2. Expensive at 3, because it demands signing and provenance. Defect Management. Level 1: structured tracking of security defects. Level 2: severity rated consistently and an SLA per class. Level 3: SLAs enforced and the defect system integrated with the rest of the tooling. Near-zero cost in licenses, high cost in discipline. This is where most teams stall, and the benchmark reading points at exactly that weak spot: the absence of useful metrics. Security Testing. Level 1: automated tools running, plus manual testing of the highest-risk components. Level 2: application-specific automation and manual penetration testing. Level 3: security testing integrated into build, deploy and the development process. Level 1 is an afternoon of work. Level 2 requires writing abuse cases for your own business rules, and that's where the benchmark shows most companies stopping. Threat Assessment. Level 1: a basic application risk profile and best-effort threat modeling, using brainstorming, the diagrams you already have and a simple checklist. Level 2: standardized training, process and tools. Level 3: continuously optimized and automated methodology. Threat modeling is among the lowest-scoring practices in the benchmark, and the assessors' reading is blunt: companies treat it as esoteric. The pragmatic version fits in a two-hour session per service. **What level 1, 2 and 3 mean across the five practices** (OWASP SAMM v2 · 0–3 scale per stream) | | Level 1 | Level 2 | Level 3 | | --- | --- | --- | --- | | Secure Build | Documented, repeatable build process, with an SBOM of dependencies | Automated pipeline, hardened tooling, checks running | Mandatory checks — a non-conformant artifact build fails | | Secure Deployment | Formalized deployment, hardened tooling, restricted secret access | Automated deployment with verification tests; secrets via vault | Integrity of all deployed software verified automatically | | Defect Management | Structured tracking of security defects | Severity assessed consistently + SLA per class | SLA enforced and system integrated with the rest of the tooling | | Security Testing | Automated tools + manual testing of the highest risk | Application-specific automation + manual pentest | Testing integrated into build, deployment and development | | Threat Assessment | Basic risk profile + best-effort threat modeling | Standardized training, process and tools | Methodology continuously optimized and automated | ## AI writes half the code; review never caught up Veracode's 2026 GenAI Code Security report tested more than 100 models on code generation tasks. The average security pass rate is 56%, against 55% in the first report. Around 44% of tasks produced a vulnerability. The best model in the set, GPT-5.5, reaches 68% and still fails nearly one security task in three. The distribution is more useful than the average. Cryptography passes 87% of the time and SQL injection 83%. XSS passes 15%. Log injection, 12%. Translated: the model learned to use parameterized queries and still concatenates output for the user. And Veracode estimates AI already writes roughly half the committed code in organizations using these tools. Dependency volume follows. Sonatype identified more than 454,600 new malicious packages in 2025, in a running total of 1.233 million blocked packages. In 55.9% of cases the vector is abuse of the public registry itself. The effect shows up as debt. In Veracode's 2026 State of Software Security, security debt reaches 82% of organizations, against 74% in 2025 and 71% in 2024. Critical debt — a severe flaw left open for more than a year — climbs to 60%. High-risk vulnerabilities grew 36% in twelve months. The practical conclusion isn't stop using AI. It's that the bottleneck moved from writing to review. Build gates and automated testing stopped being good practice and became a condition of operating. No SMB team manually reviews twice the code with the same headcount. ## The plan, quarter by quarter Assumptions change the timeline, so they're worth stating: 15 to 40 people in engineering, 3 to 8 services in production, a single CI provider, one senior engineer as technical owner at 8 hours a week, plus 2 hours a week from each squad, and open tooling — SAST, dependency and image scanning, DAST and a secrets vault. No dedicated hire. With 40 repositories and three CI providers, add a quarter. Quarter 1 — Secure Build to level 2, Defect Management to level 1. A reference pipeline, an SBOM generated on every build, dependency and secret scanning in warning mode, and a single queue for security defects. Nothing blocks yet. The goal of the quarter is to have numbers, not gates. Quarter 2 — Secure Build to level 3, Security Testing to level 1. The checks become mandatory and the build fails on a new critical finding. The rule that saves the schedule: block only what's new. Old debt goes through the queue with an SLA, not through the gate. Otherwise the team switches the gate off on the first Friday. Quarter 3 — Threat Assessment to levels 1 and 2, Secure Deployment to level 2. A risk profile per service, one threat modeling session per service with a checklist, and secrets moving out of environment variables into a vault with dynamic injection and audited human access. It's the quarter with the most conversation and the least tooling. Quarter 4 — Security Testing to level 2, Defect Management to levels 2 and 3. Abuse cases written for the critical business rules, an external penetration test commissioned, an SLA per severity published and enforced. By the end of the fourth quarter there is level 3 where it changes risk and level 2 across the rest of the core. Governance and Operations rise along the way: versioned policy and incident response become a consequence of what was built. **The plan, quarter by quarter** - **Q1** — Secure Build to level 2 + Defect Management to level 1 — measure only, nothing blocks yet - **Q2** — Secure Build to level 3 + Security Testing to level 1 — mandatory gate on new findings only - **Q3** — Threat Assessment to levels 1–2 + Secure Deployment to level 2 — secrets move from .env to a vault - **Q4** — Security Testing to level 2 + Defect Management to levels 2–3 — external pentest and published SLA ## Measuring without gaming the score The SAMM score is a byproduct. Turn it into a target and the team learns to tick boxes. Four measures resist manipulation better. Share of builds that passed through the mandatory gate, not share of repositories with a scanner installed. Median time from detection to fix per severity, measured in the defect queue and compared against the published SLA. Age of the oldest open critical finding, the one number that exposes hidden debt. And the share of findings coming from the pipeline rather than from external audit: if the pentest keeps finding what the pipeline should catch, the pipeline is decorative. **Four measures that resist gaming** 1. **% of builds through the mandatory gate** — Not the share of repos with a scanner installed — measures what actually blocks, not what's merely switched on. 2. **Median time from detection to fix** — By severity, measured in the defect queue and checked against the published SLA. 3. **Age of the oldest open critical finding** — The one number that exposes hidden debt. 4. **Share of findings coming from the pipeline** — Rather than from external audit: if the pentest still finds what the pipeline should catch, the pipeline is decorative. Two hygiene rules. Freeze the assessment scope, with the same set of services each round, or the average rises without anything changing. And demand evidence: an artifact, a log, a versioned configuration. In the SAMM benchmark, more than 80% of assessments were run by third parties, and that isn't an accident. If you need to translate into another vocabulary, NIST SSDF (SP 800-218) carries 19 practices and 42 tasks across four groups and works well as common language with clients and auditors. OWASP DSOMM descends to the level of the technical pipeline activity. And ENISA's 12-step guide covers what sits outside the code. **SAMM on the critical practices · SMB · month 0 vs month 12** (level 3 = the model's maximum) | Item | Value | | --- | --- | | secure build · M0 | 0 | | secure build · M12 | 3 | | security testing · M0 | 0 | | security testing · M12 | 2 | | threat assessment · M0 | 0 | | threat assessment · M12 | 2 | | defect management · M0 | 1 | | defect management · M12 | 2 | > **What to do tomorrow**: Start with Secure Build: a mandatory gate that blocks new findings only, with old debt routed into a queue under an SLA. It's the one change that prevents regression while everything else climbs. ## Sources for this analysis - **01**: [OWASP SAMM · The Model (v2)](https://owaspsamm.org/model/) - **02**: [OWASP SAMM · The SAMM Benchmark Report](https://owaspsamm.org/benchmark/benchmark-report/) - **03**: [OWASP SAMM · Quick Start Guide](https://owaspsamm.org/docs/getting-started/) - **04**: [Veracode · 2026 State of Software Security](https://www.veracode.com/blog/2026-state-of-software-security-report-risky-security-debt/) - **05**: [Veracode · 2026 GenAI Code Security Report](https://www.veracode.com/blog/2026-genai-code-security-report-ai-risk/) - **06**: [Sonatype · 2026 State of the Software Supply Chain](https://www.sonatype.com/state-of-the-software-supply-chain/2026/open-source-malware) - **07**: [NIST · SP 800-218 Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final) - **08**: [ENISA · Cybersecurity guide for SMEs: 12 steps](https://www.enisa.europa.eu/publications/cybersecurity-guide-for-smes) ## Keep reading - **CONSULTORIA · AGO · 2026**: [What AI really costs in 2026: three bands, with the arithmetic shown](https://okamiops.com/insights/quanto-custa-implementar-ia-2026/) (6 min) - **GATEWAY · JUL · 2026**: [LLM output prices vary 106× between vendors. Your SMB pays the ceiling.](https://okamiops.com/insights/llm-cost-spread-2026/) (6 min) - **APPSEC · ABR · 2026**: [OWASP LLM Top 10 (2025): five risks already in the incident record — and how to cover each](https://okamiops.com/insights/owasp-llm-top-10-2025/) (8 min) ## No loose opinions. Every number has a source, every article ends with what to do. We write what we learn solving the problem for a client. If your situation looks like one of these, the conversation starts here.