PS Product SecurityKnowledge Base

📝 Self-Assessment Report Examples for OWASP SAMM and BSIMM

Purpose: use these example artifacts as a starting point when you need to run an internal Product Security self-assessment, socialize the results with leadership, or structure a maturity review workshop.

Important: these are illustrative skeletons, not official OWASP SAMM or BSIMM scoring tools. They should be adapted to your organization, evidence model, operating cadence, and assessment scope.

What is included

OWASP SAMM example set

BSIMM example set

Shared workbook

How to use the examples

Use the SAMM examples when you need:

  • a structured maturity conversation across governance, design, implementation, verification, and operations;
  • a target-state roadmap with incremental improvement steps;
  • a format that works well for internal workshops, quarterly planning, and capability sequencing.

Use the BSIMM examples when you need:

  • a benchmark-style discussion framed around what mature software security initiatives actually do;
  • a more executive-friendly narrative focused on observed practices, gaps, and comparative operating maturity;
  • a document that can support leadership reviews, external benchmarking conversations, or program-reset discussions.

Suggested evidence to attach during a real assessment

Area Typical evidence
Governance policies, standards, ownership matrices, exception records, quarterly review packs
Design threat models, design review notes, architecture decisions, abuse-case analysis
Implementation secure coding standards, code review evidence, SAST/SCA baselines, IDE/pre-commit controls
Verification DAST reports, penetration test findings, fuzzing records, release gates
Operations incident runbooks, runtime detections, logging standards, secrets rotation evidence
Supply chain provenance, signing, dependency update policy, release evidence, approval records

Practical adaptation pattern

  1. define the assessment scope: business unit, product family, platform, or entire Product Security program;
  2. state the scoring logic and evidence standard before the workshop begins;
  3. keep the workbook as the working sheet, and treat the DOCX/HTML reports as the communication layer;
  4. record disagreements, assumptions, and missing evidence explicitly;
  5. convert the final results into a 90-day roadmap, not just a maturity snapshot.

What not to do

  • do not present maturity scores without narrative context;
  • do not claim that the example reports are vendor- or methodology-authorized templates;
  • do not run a score-only exercise with no owners, no evidence, and no next-step decisions;
  • do not mix benchmark language and roadmap language carelessly; explain whether the document is being used for comparison, planning, or governance.
  1. BSIMM and OWASP SAMM — Overview, Value, and Comparison
  2. OWASP SAMM Deep Dive — Business Functions, Practices, and Roadmapping
  3. BSIMM Deep Dive — Domains, Practices, and Manager Use
  4. this page and the attached sample artifacts
  5. Using BSIMM and SAMM Together — Assessments, Roadmaps, and Quarterly Reviews

Official references

Ivan Piskunov · 2026 · educational and defensive-engineering use.