Compliance and assurance evidence

Write testable security requirements and a security Definition of Done

Derive security requirements from OWASP ASVS 5.0, abuse cases and the threat model, write them as acceptance criteria a test can fail, trace each one to a test or evidence, and close stories against a short security Definition of Done.

Planning, Design, Testing, Security program · Developers, AppSec engineers

Respond to product security incidents: plan, tabletop and postmortem

An incident response plan for product security incidents (exploited vulnerabilities, compromised releases, leaked signing keys, malicious dependencies shipped to customers), aligned with NIST SP 800-61 Rev. 3, with reporting clocks, a two-scenario tabletop exercise template and a blameless postmortem template.

Maintenance, Security program · AppSec engineers, Platform engineers and SREs, Security leaders

Open source license compliance: SPDX expressions, obligations and SBOM checks

Know which licenses you ship, read SPDX license expressions correctly, meet the obligations of common licenses for the way you distribute, and enforce a license policy in CI from the SBOM.

Development, Release, Security program · AppSec engineers, Security leaders

Choose cloud security posture tools and apply zero trust

What CSPM, CWPP, CIEM, CNAPP, DSPM and ASPM each find and miss, how they overlap, how to evaluate one on your own accounts, and how zero trust as defined in NIST SP 800-207 uses what they measure.

Testing, Release, Maintenance, Security program · Platform engineers and SREs

Harden the images you ship against CIS, STIG and SCAP benchmarks

Hold each image your team ships (container base images, golden VM images, Kubernetes node images) to a published benchmark through a pinned SCAP Security Guide profile, scan every build with OpenSCAP, and fail the build on any failure that a deviation register does not explain with an owner, an approver and an expiry.

Development, Release, Maintenance, Security program · Developers, AppSec engineers, Platform engineers and SREs

ASVS 5.0 verification records: requirement, test and evidence another engineer can repeat

Scope edition-qualified requirements, connect them to implementation and tests, and separate a passing check from an unsupported assurance claim.

Testing, Security program · AppSec engineers, Security leaders

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.

Release, Security program · Security leaders

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.

Security program · AppSec engineers, Security leaders

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.

Security program · AppSec engineers, Security leaders

Supplier software assurance: check SOC 2 reports, SBOMs and signed updates against your use

Connect supplier claims to product scope, supported versions, release integrity and vulnerability handling before making a procurement decision.

Release, Security program · AppSec engineers, Platform engineers and SREs, Security leaders

ISO 27001, SOC 2, NIST CSF or FedRAMP: choose the framework by the question it answers

Distinguish management systems, technical controls, risk outcomes, independent reports and government cloud requirements before reusing evidence.

Security program · Security leaders

Map PCI DSS Requirement 6 to engineering practice and evidence

Turn PCI DSS v4.0.1 Requirement 6 into engineering work: secure development, review, patching, web-attack protection, payment-page script control and change management, with the records an assessor samples and the parts that became mandatory on 31 March 2025.

Security program · AppSec engineers, Platform engineers and SREs, Security leaders

Run a developer security training program that changes code

Build role-based, hands-on developer security training from this site's learning paths, labs and fix cards, meet PCI DSS 6.2.2, NIST SSDF PO.2.2 and ISO/IEC 27001 A.6.3 with real evidence, and measure the effect with repeat findings instead of completion rates.

Security program · Developers, AppSec engineers, Security leaders

SOC 2 for engineering teams: CC6, CC7 and CC8 controls and the evidence auditors test

What a SOC 2 report covers, which Trust Services Criteria engineering owns (CC6 logical access, CC7 system operations, CC8 change management), the controls that meet them in a modern pipeline, and how to export a complete change population for a Type 2 period.

Security program · Platform engineers and SREs, Security leaders

ISO 27001 secure development: Annex A 8.25 to 8.33 as engineering practice and evidence

How ISO/IEC 27001:2022 treats secure development, what the Annex A development controls (8.4, 8.8, 8.9 and 8.25 to 8.33) look like as engineering practice, and how to keep the Statement of Applicability and its evidence honest with checks in code.

Security program · Platform engineers and SREs, Security leaders

NIST CSF 2.0 for product teams: the outcomes you own and the evidence for them

Find the CSF 2.0 outcomes a product team actually owns, including GOVERN and supply-chain risk management (GV.SC), write a current and target profile for one product, and check it against NIST's own catalog in CI.

Security program · AppSec engineers, Security leaders

Regulated product security lifecycles: IEC 62443-4-1, FDA 524B, ISO/SAE 21434 and UN R155/R156

What the secure development lifecycles for industrial, medical and automotive products require, the practices they share (threat modeling, SBOM, vulnerability handling and updates), and how to build that evidence once and package it for each instrument.

Planning, Security program · AppSec engineers, Security leaders

Compliance evidence reuse: one evidence set for SSDF, PCI DSS, ISO 27001, SOC 2 and the CRA

Keep one set of release-bound engineering evidence (SBOM, provenance, review records, scan results, ASVS results and vulnerability handling) and map it to several frameworks: a worked crosswalk, an evidence index checked in CI with a CSV export, and an OSCAL component definition.

Release, Security program · AppSec engineers, Platform engineers and SREs, Security leaders

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.

Release, Security program · Security leaders

Turn NIST AI RMF, ISO/IEC 42001 and EU AI Act duties into engineering evidence

What the NIST AI RMF and its Generative AI Profile, ISO/IEC 42001 and the EU AI Act, as amended in 2026, ask of teams that build AI features, turned into engineering practices and one set of evidence. Not legal advice.

Planning, Testing, Security program · Developers, AppSec engineers, Platform engineers and SREs, Security leaders

Release evidence lab: Keep stale test evidence out of a release decision

A release report says every required check passed, but some evidence belongs to an old commit or another service. Repair the evidence-selection function before the report hides those gaps.