For security leaders
Leads and managers who run security programs, set policy and answer to customers and regulators.
Application security
6 guidesRun coordinated vulnerability disclosure from report to advisory
Make private reporting discoverable, verify reports, coordinate a tested remedy, and give affected users enough information to act.
Maintenance · Developers, AppSec engineers, Security leaders
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.
Testing, Maintenance, Security program · AppSec engineers, Platform engineers and SREs, Security leaders
Start with a VDP, then add bug bounties and penetration tests
Publish a vulnerability disclosure policy and security.txt first, add a bug bounty only when you can triage and fix at the pace rewards bring, and buy penetration tests with a written scope, rules of engagement and a retest.
Testing, Maintenance · AppSec engineers, Security leaders
Set up a PSIRT: services, intake, triage, SLAs and the CNA role
How to structure and run a product security incident response team on the FIRST PSIRT Services Framework: organizational models, intake channels, triage, response targets, a case record and SLA script, becoming a CVE Numbering Authority under the CNA rules 4.2.0, and coordinating with other vendors.
Maintenance · AppSec engineers, Security leaders
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
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.
Development, Testing, Maintenance, Security program · Developers, AppSec engineers, Security leaders
Software supply chain
1 guideGovernance & frameworks
29 guidesStart 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
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
Approve, expire and measure security exceptions without hiding risk
Keep temporary acceptance separate from remediation and measure outcomes using definitions that survive changing visibility.
Maintenance, Security program · 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
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.
Planning, Maintenance, Security program · AppSec engineers, 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
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.
Planning, Design, 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
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.
Maintenance, Security program · AppSec engineers, 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 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.
Testing, Security program · AppSec engineers, Security leaders
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.
Maintenance, Security program · AppSec engineers, Security leaders
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.
Security program · AppSec engineers, 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
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.
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
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.
Planning, Design, Security program · Platform engineers and SREs, Security leaders
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.
Planning, Security program · Security leaders
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.
Maintenance, 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