Governance & frameworks
Turn security expectations into an accountable, measurable engineering program.
29 guides · 1 lab · 1 learning path
Start here
Start a minimal AppSec program with owners, triggers and metrics
Frameworks and verificationApply NIST SSDF (SP 800-218) to one product: practices, evidence and attestation in 2026
Frameworks and verificationASVS 5.0 verification records: requirement, test and evidence another engineer can repeat
Programs and operations
Start a program teams can operate, add champions, prioritize findings, set SLAs and measure it.
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.
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.
Run a security champions program with protected time and outcome metrics
Put a trained engineer with protected hours in every in-scope team, write the role into a one-page charter, route sensitive changes and findings through champions and AppSec, and judge the program by coverage and outcomes instead of attendance.
Prioritize vulnerabilities by exploitation, exposure and impact
Rank vulnerabilities with CISA KEV, EPSS, CVSS 4.0 vectors and SSVC decision points, adjust for presence, reachability and asset value, and turn the result into due dates. Covers NVD's 2026 enrichment changes and CISA BOD 26-04.
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.
Approve, expire and measure security exceptions without hiding risk
Keep temporary acceptance separate from remediation and measure outcomes using definitions that survive changing visibility.
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.
Build an application security career: roles, skills, portfolio and certifications
The main application security role tracks (AppSec engineer, product security engineer, security champion, platform security engineer, security architect), the skills expected at each level, how to build a portfolio a hiring team can verify using this site's labs, projects and fix cards, and what common certifications do and do not show.
Case study: First American's EaglePro document exposure (2019)
How sequential IDs in unauthenticated links exposed First American's title documents in 2019, after its own penetration test found the flaw and a clerical error let it go unfixed.
Case study: Storm-0558 and the forged Microsoft tokens (2023)
How a stolen 2016 consumer signing key and a token validation gap let Storm-0558 read enterprise Exchange Online mail in 2023, and what the review board found about rotation, logging and culture.
Frameworks and verification
Apply SSDF, SAMM and ASVS, and map requirements without overstating them.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Apply CISA Secure by Design: principles, pledge goals and evidence
What CISA's Secure by Design guidance and pledge ask of software manufacturers as of October 2026, and how to turn each of the three principles, the seven pledge goals and the Product Security Bad Practices into engineering actions, metrics and evidence.
Suppliers, products and regulation
Supplier assurance, product-security obligations such as CRA reporting, PCI DSS and privacy law.
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.
Cyber Resilience Act and payment pages: turn product-security obligations into an engineering evidence plan
Determine the relevant actor, product, market and requirement before connecting CRA or payment-security expectations to implementation work.
Build a runbook for CRA vulnerability and incident reporting
Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform within 24 and 72 hours. Decide what is reportable, start the clock at the right moment, file through the platform and keep an evidence trail.
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.
GDPR, CCPA, HIPAA or the FTC rule: scope privacy and health-data obligations before choosing controls
Map data, actors and processing purposes to the relevant GDPR, California or HIPAA requirements and preserve uncertainty about applicability.
GDPR privacy by design for engineers: Articles 25, 32 and 35 in code
Turn GDPR data protection by design and by default, security of processing and DPIA triggers into engineering work: a personal-data inventory checked in CI, defaults that collect and share less, a DPIA screen at design time, and access and erasure requests that reach every store.
NIS2 and DORA for software suppliers: what reaches you and the evidence to keep
Work out whether NIS2 applies to your software company directly or only through customers, what Article 21 risk-management measures and DORA's ICT third-party rules ask of suppliers, and how to keep one assurance pack and register data sheet for both.
UK Software Security Code of Practice: the 14 principles as engineering practice
What the UK government's voluntary Software Security Code of Practice (May 2025) asks of software vendors, each of its 14 principles mapped to engineering practice, NIST SSDF and the EU Cyber Resilience Act, and a CI check for the support-period principles.
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.
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 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.
CVSS v4.0 calculator
Score CVSS v4.0 vectors with Base, Threat, Environmental and Supplemental metrics. Paste or build a vector; scores match FIRST’s reference calculator.
ASVS 5.0 checklist export
Export the 345 OWASP ASVS 5.0.0 requirements as a CSV or JSON checklist, filtered by level (L1, L2 or L3) and chapter, with official IDs and the CC BY-SA 4.0 attribution.