Scanners, pentest reports and audits name problems by identifier. Look one up to see what it means, how to prevent it and which guides cover it, or start from the standard itself: which edition is current, what is still a draft, and what changed.
The 2025 CWE Top 25 Most Dangerous Software Weaknesses and every other CWE the guides, fix cards and labs cite, each with the material that covers it.
OWASP Top 10The ten OWASP Top 10:2025 web application risk categories, A01 to A10, with prevention basics, mapped CWEs and the Software Security guides for each.
OWASP API SecurityThe OWASP API Security Top 10 2023 risks, API1 to API10, explained with prevention basics, related CWEs and the Software Security guides that cover each.
OWASP GenAI Security ProjectThe OWASP Top 10 for LLM Applications 2026, LLM01 to LLM10, with each risk’s 2025 ID, prevention basics and the Software Security guides that cover it.
OWASP GenAI Security ProjectThe OWASP Top 10 for Agentic Applications 2026, ASI01 to ASI10, with prevention basics for each agent risk and the Software Security guides that apply.
Application Security Verification StandardThe 17 chapters of OWASP ASVS 5.0.0, V1 to V17, with every requirement and its level, how to meet them and the Software Security guides for each.
OWASP Kubernetes Top 10The OWASP Kubernetes Top 10 2025 risks, K01 to K10: what each means for teams that run workloads on Kubernetes, how to prevent it and the guides that cover it.
OWASP CI/CD SecurityThe OWASP Top 10 CI/CD Security Risks, CICD-SEC-1 to CICD-SEC-10: what each means for teams that build and ship software, how to prevent it and the guides here.
Mobile Application Security Verification StandardThe 24 OWASP MASVS 2.1.0 controls in eight groups, mapped to the mobile guides and to the MASTG tests that the iOS and Android projects run.
CrosswalkOne table from guides, fix cards and labs to CWE, OWASP Top 10, API, LLM, Agentic, Kubernetes and CI/CD Top 10, ASVS 5.0, MASVS and NIST SSDF, with JSON and CSV downloads.
42 current editions, 2 draft and 15 superseded, checked against their publishers on 10 October 2026. Status: current is the latest final or stable edition, draft is a public draft that is not final yet, and superseded has been replaced by a newer final edition or retired. Each family lists the pages its dates were checked against.
What to require of an application, and how to test it.
A list of 345 testable security requirements for web applications and services, organized into 17 chapters and three levels. Teams use it to set security requirements, guide code review and scope security testing.
On this site: OWASP ASVS 5.0.0 chapters · ASVS 5.0 verification records: requirement, test and evidence another engineer can repeat
Checked against:
The security standard for mobile apps: high-level controls grouped into storage, crypto, auth, network, platform, code, resilience and privacy. Use it to set mobile security requirements; the MASTG explains how to test them.
On this site: OWASP MASVS 2.1.0 controls · Review mobile storage, links and platform permissions · Harden an Android app's storage, network and entry points · Harden an iOS app's storage, network and entry points · Worked threat model: a mobile banking app
Checked against:
The testing guide for mobile apps: atomic tests, techniques, tools and runnable demos linked to MASVS controls and MASWE weaknesses. Use it to verify Android and iOS apps against MASVS.
Checked against:
OWASP's manual for testing web applications and APIs, with test cases identified by WSTG IDs. v4.2 is the latest stable release; version 5.0 is in development.
Checked against:
The identifiers scanners, reports and tickets use to name a problem.
The community catalog of software and hardware weakness types (CWE IDs) used to classify the root causes of vulnerabilities. Use CWE IDs in findings, tickets and CVE records.
On this site: CWE weaknesses
Checked against:
A ranking of the 25 weakness types behind the most severe and common CVEs published from June 2024 to June 2025, led by cross-site scripting (CWE-79). Use it to decide which bug classes to eliminate first.
On this site: CWE weaknesses
Checked against:
OWASP's awareness list of the ten most critical web application security risks, now including software supply chain failures and mishandling of exceptional conditions. Use it for training and as a minimum checklist, not as a complete standard.
On this site: OWASP Top 10:2025
Checked against:
The ten most critical API security risks, led by broken object-level authorization. Use it to review API authorization, resource limits, inventory, and how your API consumes third-party APIs.
On this site: OWASP API Security Top 10 2023
Checked against:
The ten most critical security risks for applications that use large language models as components, from prompt injection to improper output handling. Use it to threat-model LLM features; pair it with the Agentic Top 10 when the model can act on its own.
On this site: OWASP Top 10 for LLM Applications 2026
Checked against:
The ten most critical risks for autonomous, tool-using AI agents (ASI01 Agent Goal Hijack to ASI10 Rogue Agents). Use it when your system lets a model call tools, keep memory or talk to other agents.
On this site: OWASP Top 10 for Agentic Applications 2026
Checked against:
The ten main risks of running workloads on Kubernetes, from K01 Insecure Workload Configurations to K10 Inadequate Logging And Monitoring, with new entries for exposed cluster components (K06) and cluster-to-cloud lateral movement (K08). Despite its name, the 2025 edition was published in March 2026.
On this site: OWASP Kubernetes Top 10 2025 · Run Kubernetes workloads with only the privileges they need · Prove network and admission policies enforce the intended boundary · Harden managed Kubernetes on EKS, AKS and GKE · Case study: ingress-nginx CVE-2025-1974 and the exposed admission webhook (2025)
Checked against:
Ten ways attackers abuse the systems that build and ship software, CICD-SEC-1 Insufficient Flow Control Mechanisms to CICD-SEC-10 Insufficient Logging and Visibility. It has no edition year and no revision since 2022 beyond a one-line edit in 2025.
On this site: OWASP Top 10 CI/CD Security Risks · Protect the path from pull request to release · Keep untrusted CI work outside the release boundary · Workload identity federation: short-lived, scoped identities for services and CI · Place each security control in the pipeline and decide what it blocks and 4 more guides
Checked against:
How an organization builds software securely and measures its program.
A core set of high-level secure development practices that can be built into any SDLC, grouped as prepare the organization, protect the software, produce well-secured software, and respond to vulnerabilities. Teams map their existing process to its practices and tasks; buyers use it as a shared vocabulary with suppliers.
Version 1.2 (Initial Public Draft) is a draft: track it, but assess against the current edition.
On this site: Crosswalk · Apply NIST SSDF (SP 800-218) to one product: practices, evidence and attestation in 2026 · Set remediation SLAs and measure AppSec outcomes · BSIMM vs SAMM vs SSDF: what each is for and which to use · Answer a US federal secure software attestation request in 2026: the CISA form, its SSDF mapping and the evidence behind each statement
Checked against:
A maturity model for software security programs, with 15 security practices across five business functions (Governance, Design, Implementation, Verification, Operations). Use it to assess your current program and plan improvements.
On this site: Run an OWASP SAMM assessment with evidence and a practical roadmap · Set remediation SLAs and measure AppSec outcomes · Run a security champions program with protected time and outcome metrics · BSIMM vs SAMM vs SSDF: what each is for and which to use
Checked against:
A descriptive model of what real software security programs do, built from assessments of 111 organizations and covering 128 activities. Use it to compare your program with peers, not as a checklist.
On this site: Set remediation SLAs and measure AppSec outcomes · Run a security champions program with protected time and outcome metrics · BSIMM vs SAMM vs SSDF: what each is for and which to use
Checked against:
Joint guidance that urges software makers to ship products that are secure by design, built on three principles: take ownership of customer security outcomes, embrace radical transparency and accountability, and lead from the top.
On this site: Apply CISA Secure by Design: principles, pledge goals and evidence · UK Software Security Code of Practice: the 14 principles as engineering practice
Checked against:
The secure development lifecycle standard for suppliers of industrial automation and control products: security management, requirements, secure design and implementation, verification, defect and update management, and product documentation. Edition 2.0 is in preparation and not yet published.
On this site: Regulated product security lifecycles: IEC 62443-4-1, FDA 524B, ISO/SAE 21434 and UN R155/R156
Checked against:
Provenance, build integrity and software bills of materials.
A specification of supply chain security levels for how software is built and, since v1.2, how source code is managed. It asks you to produce verifiable build provenance and to harden build and source platforms.
On this site: Read SLSA provenance and verify the claim you need
Checked against:
A bill-of-materials standard for software components, services, cryptographic assets (CBOM) and more. Version 1.7 adds citations, patent information and expanded cryptography support. Use it to generate SBOMs from your build pipeline.
On this site: SBOM checker · Generate an SBOM for the software you actually release · Choose SBOM formats and identify components accurately · Review SBOM changes between releases · Use VEX without losing vulnerability evidence
Checked against:
An open standard for describing software packages, files, licenses and their relationships as a software bill of materials (SBOM). Use it to produce and exchange SBOMs.
On this site: SBOM checker · Generate an SBOM for the software you actually release · Choose SBOM formats and identify components accurately
Checked against:
Security requirements for open-source projects in eight families (access control, build and release, documentation, governance, legal, quality, security assessment, vulnerability management), each first required at maturity Level 1, 2 or 3. Maintainers self-attest a level for a dated version.
On this site: Protect the source repository: rulesets, reviews and signed commits · Meet the OpenSSF OSPS Baseline as a maintainer: the levels, every Level 1 control on GitHub, and the evidence
Checked against:
How organizations should consume open source: eight practices (ingest, scan, inventory, update, audit, enforce, rebuild, fix and upstream) with 25 requirements at four maturity levels. The spec ties a compliance claim to Level 3.
On this site: Adopt the OpenSSF S2C2F as a consumer: the eight practices, the four maturity levels and a staged plan with evidence
Checked against:
The machine-readable JSON format for security advisories and VEX statements, so customers can match vulnerabilities to products automatically. CSAF 2.0 is also ISO/IEC 20153:2025; emit 2.0 until 2.1 becomes a standard.
Version 2.1, Committee Specification Draft 03 is a draft: track it, but assess against the current edition.
On this site: Use VEX without losing vulnerability evidence · Publish security advisories with CSAF, VEX, CVE records and OSV
Checked against:
Severity, likelihood of exploitation and known exploitation.
FIRST's standard for scoring vulnerability severity from 0 to 10 using base, threat, environmental and supplemental metrics. Report CVSS-B for base-only scores, and add threat and environmental data when you have it.
On this site: Prioritize vulnerabilities by exploitation, exposure and impact
Checked against:
A daily, data-driven estimate of the probability that a CVE will be exploited in the next 30 days. Use it together with CVSS and KEV to prioritize patching; scores shift when the model version changes.
On this site: Prioritize vulnerabilities by exploitation, exposure and impact
Checked against:
CISA's continuously updated list of CVEs with reliable evidence of active exploitation and an available fix. Prioritize patching anything on it; US federal civilian agencies must remediate on BOD 26-04 timelines.
On this site: Respond to an exploited or malicious dependency · Prioritize vulnerabilities by exploitation, exposure and impact
Checked against:
Obligations and control frameworks that engineering evidence feeds.
EU law that sets cybersecurity requirements for products with digital elements sold in the EU, including vulnerability handling, security updates and a machine-readable SBOM. Since September 11, 2026, manufacturers must report actively exploited vulnerabilities (early warning within 24 hours) and severe incidents to their CSIRT and ENISA.
On this site: Cyber Resilience Act and payment pages: turn product-security obligations into an engineering evidence plan · Build a runbook for CRA vulnerability and incident reporting
Checked against:
The payment card industry's security standard for systems that store, process or transmit cardholder data. For software teams it includes secure development requirements and multi-factor authentication for all non-console access into the cardholder data environment.
On this site: Cyber Resilience Act and payment pages: turn product-security obligations into an engineering evidence plan · Map PCI DSS Requirement 6 to engineering practice and evidence
Checked against:
The international standard for an information security management system (ISMS), with Annex A referencing the 93 controls in ISO/IEC 27002:2022. Engineering teams usually supply evidence for its controls on secure development, change management and vulnerability management.
On this site: ISO 27001, SOC 2, NIST CSF or FedRAMP: choose the framework by the question it answers · ISO 27001 secure development: Annex A 8.25 to 8.33 as engineering practice and evidence
Checked against:
A taxonomy of high-level cybersecurity outcomes, organized into six functions: Govern, Identify, Protect, Detect, Respond and Recover. It does not prescribe how to achieve them; engineering teams usually meet it through organizational profiles and control mappings.
On this site: ISO 27001, SOC 2, NIST CSF or FedRAMP: choose the framework by the question it answers
Checked against:
NIST's catalog of security and privacy controls for information systems and organizations. Release 5.2.0 added SA-15(13) Logging Syntax, SA-24 Design for Cyber Resiliency and SI-02(07) Root Cause Analysis, and revised SI-07(12) Integrity Verification.
On this site: ISO 27001, SOC 2, NIST CSF or FedRAMP: choose the framework by the question it answers
Checked against:
The UK government’s voluntary baseline for organizations that develop or sell software: 14 principles in four themes (secure design and development, build environment security, secure deployment and maintenance, and communication with customers), with a Senior Responsible Owner accountable for them. The principles have not changed since publication.
On this site: UK Software Security Code of Practice: the 14 principles as engineering practice
Checked against:
EU law that requires essential and important entities in 18 sectors to manage cybersecurity risk, including supply-chain security and secure development, and to report significant incidents, with management bodies accountable. Software suppliers feel it directly when they are in scope and through the contracts of customers who are.
On this site: NIS2 and DORA for software suppliers: what reaches you and the evidence to keep
Checked against:
EU regulation, applying since 17 January 2025, that sets ICT risk-management, incident-reporting, resilience-testing and ICT third-party risk rules for financial entities and puts critical ICT providers under direct EU oversight. Software and cloud suppliers to EU financial firms meet it through contract terms, the register of information and audits.
On this site: NIS2 and DORA for software suppliers: what reaches you and the evidence to keep
Checked against:
The control criteria a CPA examines in a SOC 2 report (security, availability, processing integrity, confidentiality and privacy), used with the 2018 description criteria (DC 200). The 2022 revision changed the points of focus, not the criteria. AICPA’s pages give no issue date for it; the date shown is that of the updated SOC 2 Guide.
On this site: ISO 27001, SOC 2, NIST CSF or FedRAMP: choose the framework by the question it answers · SOC 2 for engineering teams: CC6, CC7 and CC8 controls and the evidence auditors test
Checked against:
The US government’s security certification for cloud services used by federal agencies. Since June 2026 one rule set (CR26) covers both the Rev5 process, built on NIST SP 800-53 Rev. 5, and FedRAMP 20x, which validates key security indicators continuously. 20x is in Phase 3; Class D (high) is planned for Phase 4.
On this site: ISO 27001, SOC 2, NIST CSF or FedRAMP: choose the framework by the question it answers
Checked against:
Risk frameworks, taxonomies and law for AI systems.
A cross-sector profile of, and companion to, the NIST AI Risk Management Framework (AI RMF 1.0) for generative AI. Use it to scope risk reviews of generative AI features.
On this site: Turn NIST AI RMF, ISO/IEC 42001 and EU AI Act duties into engineering evidence
Checked against:
A taxonomy and glossary for adversarial machine learning: types of attacks on predictive and generative AI systems, attacker goals and capabilities, and mitigations. Use it to name and scope AI threats consistently.
Checked against:
EU law that bans some AI practices, sets duties for general-purpose AI model providers, and regulates high-risk AI systems. The adopted 2026 Digital Omnibus on AI delayed the high-risk obligations to December 2027 (Annex III) and August 2028 (Annex I).
On this site: Turn NIST AI RMF, ISO/IEC 42001 and EU AI Act duties into engineering evidence
Checked against:
A management system standard with requirements for establishing, running and improving an AI management system in organizations that provide or use AI systems. It follows the same management system structure as ISO/IEC 27001.
On this site: Turn NIST AI RMF, ISO/IEC 42001 and EU AI Act duties into engineering evidence
Checked against:
Dated changes to these standards in the year before 10 October 2026 and those scheduled after it.
Sources: ASVS 5.0.0: Changes Compared to v4.x · ASVS 5.0.0: What is the ASVS (level definitions) · ASVS mapping 4.0.3 to 5.0.0 · ASVS mapping 5.0.0 to 4.0.3 · ASVS 4.0.3 flat JSON (counted: 286 IDs, 8 deleted, 128 L1) · ASVS 5.0.0 flat JSON (counted: 345 requirements; L1 70, L2 183, L3 92)
Sources: OWASP Top 10:2025 Introduction · OWASP Top 10:2025 index
Sources: GenAI-LLM-Top10 2026 preface: What's New in the 2026 Top 10 · GenAI-LLM-Top10 2026 release overview (final list) · GenAI-LLM-Top10 2025 source files (2025 IDs) · OWASP GenAI LLM Top 10 2026 publication page
Sources: OWASP Kubernetes Top 10 (both lists)
The identifier pages keep the earlier codes: A01:2025 lists A01:2021 and A10:2021, and each LLM Top 10 2026 entry gives its 2025 ID, so the lookup box opens the current entry for either code.