SSDF and SAMM mapping
Framework mapping is a table that links each practice of a framework, such as the 19 practices of NIST SSDF 1.1 or the 15 of OWASP SAMM, to what your teams actually do and to the records that show it. Questionnaires, attestations and maturity assessments then become lookups instead of new projects.
Customers, auditors and agencies ask the same questions in different words. Without one mapping, each request starts from scratch and the answers drift: a questionnaire says every risky change is reviewed while the review records cover only some. A mapping backed by evidence shows which claims you can support today and which practices are missing, such as role-based training with no records.
- Who
- AppSec or the program lead owns the mapping; product and platform teams supply the evidence
- When
- Before answering a questionnaire or attestation, before a maturity assessment, and when a framework edition changes
- How often
- Evidence added with each release; the whole mapping reviewed at least yearly and when a framework, product or evidence source changes
- You end up with
- One evidence matrix: each SSDF task or SAMM activity with its edition, status, evidence link, owner and gap plan
Do this
Pick the framework for the question
Use SSDF 1.1 as the list of outcomes customers and agencies ask you to evidence; NIST describes it as a common vocabulary for secure development. Use SAMM to score your own maturity and plan the next improvements. BSIMM describes what participating firms were observed to do, so use it only to compare with peers. The table below compares them.
Pin the edition and the scope
Record the editions: SSDF 1.1 (SP 800-218, February 2022) is final, and the 1.2 draft's new practices belong on separate rows, never in a 1.1 result. Name the products, teams and period the mapping covers, so nobody reads a pilot as company-wide coverage.
Map each practice to what teams do
For each SSDF task or SAMM activity, name the practice that carries it out, such as Threat modeling for PW.1.1 or Role-based training for PO.2.2. Start from SSDF's informative references, which already cite SAMM and BSIMM activities, and check BSIMM IDs against the current edition, since BSIMM renumbers activities between editions.
Link evidence from real releases
Attach records of operation: a review on a merged change, a test run bound to an artifact, a triaged vulnerability report. A policy or a tool setting shows intent; a branch rule shows what would be enforced, while sampled merged changes show what happened. Sample several changes when you claim a practice operates repeatedly.
Mark status and plan the gaps
Use a few fixed statuses, such as operating, partial, missing, not applicable and not assessed. Give each gap an owner, a date and the practice page that closes it, and fix live exposure before paperwork. A short CI check can reject unknown practice IDs, operating claims without an evidence ID and rows without an owner.
State relationships, not equivalence
When you map one framework to another, say how the requirements relate, such as supports, subset of or intersects with, in the vocabulary of NIST IR 8477, and record what the mapping does not cover. A mapping row says how two requirements relate; it never shows that either is implemented.
Answer requests from the same rows
Answer a customer's SSDF questionnaire, a SAMM assessment or CISA's Secure Software Development Attestation Form from the same evidence; since OMB M-26-05 of January 2026, agencies may choose to use the form rather than having to. See Answer a US federal secure software attestation request in 2026: the CISA form, its SSDF mapping and the evidence behind each statement. Review the mapping at least yearly and when an edition changes, as SSDF's PO.1 examples suggest for security requirements.
Done when
Each SSDF practice or SAMM activity you claim links to current evidence, and each gap has an owner and a date.
Mark it in the gap checkCommon mistakes
- Claiming SSDF compliance from a policy or a tool list, with no task-level evidence from a real release.
- Citing the SSDF 1.2 draft as if it were final, or counting its new practices in a 1.1 result.
- Comparing a SAMM score with a BSIMM scorecard: they measure different things on different scales.
- Scoring SAMM across the whole company with no defined scope, so next year's score cannot be compared with this one.
- Treating a crosswalk from another source as proof. It can seed your mapping, but only your own records show what you do.
- Building a separate evidence set for each framework instead of one store with several views, so the answers drift apart.
SSDF, SAMM or BSIMM?
They answer different questions. Many programs use SSDF as the outcome list, SAMM for the roadmap, and BSIMM only for an external benchmark.
| Question | NIST SSDF 1.1 | OWASP SAMM 2.2.0 | BSIMM16 |
|---|---|---|---|
| What kind of model? | Outcome list: 19 practices with their tasks, in four groups | Prescriptive maturity model: 15 practices in five business functions | Descriptive: what participating firms were observed to do |
| Maintained by | NIST | OWASP | Black Duck |
| Result | Each task evidenced or not | A score from 0 to 3 per practice, for a defined scope | Activities observed, compared with the data pool of 111 firms |
| Best for | Customers, contracts, questionnaires and attestations | Planning the next improvements and tracking progress | Comparing with peers |
| How you assess | Self-assessment against the tasks, or a customer's questionnaire or attestation | Self-assessment with the SAMM toolbox, a spreadsheet that scores each activity | An assessment that begins with interviews by BSIMM consultants |
Tools and guides
- Workflow: Build an AppSec program
- Standards and identifiers
- Apply NIST SSDF (SP 800-218) to one product: practices, evidence and attestation in 2026
Connect secure-development practices to an actual product’s work, artifacts and responsibilities instead of a questionnaire full of unsupported yes answers.
- Run an OWASP SAMM assessment with evidence and a practical roadmap
Use OWASP SAMM to distinguish isolated successes from repeatable practices and choose improvements the organization can sustain.
- BSIMM vs SAMM vs SSDF: what each is for and which to use
How BSIMM16, OWASP SAMM 2.2.0 and NIST SSDF 1.1 differ, what each measures and does not, a chooser by situation, and a verified SSDF-to-BSIMM16-and-SAMM crosswalk with a script that reports evidence gaps.
- Answer a US federal secure software attestation request in 2026: the CISA form, its SSDF mapping and the evidence behind each statement
Know what is and isn't required after OMB M-26-05, then answer an agency's request statement by statement, with the SSDF tasks the form maps and release evidence for each claim.
- Control mapping between frameworks: state the relationship without overstating equivalence
Record exactly how an implementation supports a requirement, which evidence is reusable and which obligations remain unresolved.
Standards
- NIST SSDF 1.1
- PO.1 Define Security Requirements for Software Development
- OWASP SAMM 2
- Policy and ComplianceStrategy and Metrics
Sources
- NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1. February 2022.
- NIST SP 800-218 Rev. 1 (SSDF 1.2), initial public draft. Initial public draft, December 2025.
- NIST OSCAL content: SP 800-218 version 1.1 catalog (PO.1 tasks, examples and references). oscal-content v1.5.0.
- OWASP SAMM: the model
- OWASP SAMM core model release v2.2.0
- OWASP SAMM: assessment toolbox
- OWASP SAMM: Policy and Compliance, stream B (Compliance Management)
- Black Duck: BSIMM report page. BSIMM16, January 2026.
- BSIMM16 report (Black Duck). January 2026.
- CISA: Secure Software Development Attestation Form. Revision date 14 May 2024.
- NIST IR 8477: Mapping Relationships Between Documentary Standards, Regulations, Frameworks, and Guidelines. February 2024.