Secure development lifecycle

Review a code change through its trust boundaries

Turn a pull request into a small set of security claims that can be checked against the surrounding system and tests.

Development, Testing · Developers, AppSec engineers

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

Abuse case library: tests and controls by feature

Recurring abuse cases for sign-up and login, password reset, MFA enrolment, invites, file upload, payments and coupons, webhooks, search, export, admin and AI chat or agents: the attacker goal, preconditions, a concrete test and the control, each linked to CWE and CAPEC.

Planning, Design, Testing · Developers, AppSec engineers

Protect the source repository: rulesets, reviews and signed commits

Configure the controls every repository that ships software needs: protected branches and tags, required review with CODEOWNERS, signed commits, secret push protection and account security, mapped to the SLSA Source track, the OpenSSF OSPS Baseline and Scorecard.

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

Meet the OpenSSF OSPS Baseline as a maintainer: the levels, every Level 1 control on GitHub, and the evidence

Walk through the eight control families and three maturity levels of OSPS Baseline v2026.08.28, meet each Level 1 requirement on a GitHub repository, and keep evidence a consumer can check.

Development, Release, Security program · Developers

Staged rollout and rollback for security-critical updates

Ship security fixes, detection content and configuration quickly without taking the fleet down: rollout rings and canaries, content validation, kill switches and rollback that works on a broken host.

Release · AppSec engineers, Platform engineers and SREs

Start a minimal AppSec program with owners, triggers and metrics

Begin with ownership, a few risk-triggered activities, and evidence that findings are resolved; expand from demonstrated needs.

Security program · AppSec engineers, Security leaders

Run an AppSec program: owners, finding states, deadlines and champions

Translate a security baseline into service ownership, change triggers, reusable patterns and evidence that work reaches deployment.

Security program · AppSec engineers, Security leaders

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

Set remediation SLAs and measure AppSec outcomes

Set vulnerability SLAs by exploitation and exposure, route misses through expiring exceptions, and measure the program with cohort-based, censoring-aware metrics that resist gaming.

Maintenance, Security program · AppSec engineers, Platform engineers and SREs, 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

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.

Security program · AppSec engineers, 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

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

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

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

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.