Security program
The work around every phase: owners and champions, training, metrics and exceptions, and the frameworks that tie it together.
Who owns security, and how do you know the practices are working?
Start here: Build an AppSec program
The practices around the phases
Owners and champions
Give each product an accountable owner for its security work, and support a security champion in each team with protected time.
Done when: Every product, finding and exception has a named owner, and each team's champion has protected time and takes part in design reviews.
Role-based training
Train developers on the weaknesses their stack produces, with hands-on practice, and measure the effect on the code rather than course completion.
Done when: Each team's training topics come from the findings it actually gets, and its repeat findings are compared before and after.
Exceptions and metrics
Track time to fix and recurring weakness classes, and give every accepted risk an owner and an expiry date.
Done when: Metrics are reviewed on a set schedule, and every open exception has a risk owner and an expiry date.
SSDF and SAMM mapping
Map what you do to NIST SSDF or OWASP SAMM, so gaps and the evidence for attestations come from one place.
Done when: Each SSDF practice or SAMM activity you claim links to current evidence, and each gap has an owner and a date.
Guides
52 guides- 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.
- 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.
- 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.
- Approve, expire and measure security exceptions without hiding risk
Keep temporary acceptance separate from remediation and measure outcomes using definitions that survive changing visibility.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Also part of the program
- Review dependency health without treating a score as a guarantee
Combine security practices, maintenance, licensing and product exposure into a recorded adoption or replacement decision.
- 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.
- Data minimization and retention: collect less and prove that deletion works
Design collection and deletion around a data-flow graph that includes logs, derived tables, exports and restored backups, and use per-person keys so deletion can reach copies you cannot edit.
- Tokenization, pseudonymization and privacy transformations: choose deliberately
Choose between vault tokens, keyed pseudonyms, format-preserving encryption, aggregation and differential privacy by the joins, reversibility and leakage each allows, and test re-identification on the data you release.
- Build evaluations around prohibited outcomes
Test the application’s actual security boundaries, preserve legitimate tasks and distinguish deterministic enforcement from variable model behavior.
- Red-team LLM applications and agents by their effects
A red-teaming method for LLM features and agents: scope the whole system, map attacks to OWASP and MITRE ATLAS identifiers, score trials from observed effects, report rates with confidence intervals and retest on every model or provider change.
- Protect training and retrieval data from targeted poisoning
Track who can influence datasets, keep evaluation independent and investigate targeted behavior changes without relying on aggregate accuracy.
- 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.
- Choose and evaluate application security testing tools
What SAST, DAST, IAST, SCA, secrets, IaC, container and API scanners and ASPM each find and miss, where each runs, how to evaluate them on a seeded repository with per-CWE scoring and triage cost, and which to adopt first.
- Case study: the xz Utils backdoor (CVE-2024-3094)
How a multi-year maintainer takeover planted a backdoor in xz Utils release tarballs, how build-time injection hid it from the git repository, why a performance anomaly exposed it, which systems shipped it, and what it teaches about reproducible builds and maintainer health.
- Case study: event-stream and ua-parser-js, two npm package takeovers
Two ways attackers took over popular npm packages: event-stream (2018), handed to a stranger who added a targeted, encrypted payload through a new dependency, and ua-parser-js (2021), whose maintainer's account was hijacked to publish versions that installed malware for four hours. Timelines, detection and the controls that stop both.
- Case study: the polyfill.io CDN takeover (2024)
How the sale of the polyfill.io domain and project in February 2024 turned a script tag on more than 100,000 websites into a channel for malicious redirects by June, why Subresource Integrity could not have protected it, and the controls that would have.
- Case study: MOVEit Transfer mass exploitation (CVE-2023-34362)
How one unauthenticated SQL injection in an internet-facing file transfer product let the Cl0p group steal data from thousands of organizations in days in 2023, how defenders found the web shell, and the vendor and customer controls that would have limited it.
- 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.
- 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.
- 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.
- 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.
- 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.
- Adopt the OpenSSF S2C2F as a consumer: the eight practices, the four maturity levels and a staged plan with evidence
Assess how your organization takes in open source against the Secure Supply Chain Consumption Framework's 25 requirements, then reach each maturity level in turn with evidence an assessor can check.
- 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.
- 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.
- 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.
- Contain LLM misinformation (OWASP LLM07:2026)
Stop plausible but wrong model output from driving decisions and actions: ground answers in sources, verify every citation, separate generation from execution with a claim-check-act pattern, gate consequential actions on a human, and evaluate factuality on your own domain.
- 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.
- 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.