27.1: OWASP Standards for Supply Chain Security¶

Disclaimer: This chapter describes voluntary security standards and frameworks developed by the Open Web Application Security Project (OWASP). While these standards represent industry best practices, they are not legal requirements (except where explicitly adopted by regulation or contract). Implementation of OWASP standards does not guarantee security or compliance with legal obligations. Organizations should assess their specific risk profile, regulatory requirements, and business needs with qualified security and legal professionals before adopting any framework. Standards evolve over time; verify current versions and recommendations.

The Open Web Application Security Project (OWASP) has established itself as the preeminent source of practical security guidance for software development. Unlike regulatory requirements that mandate compliance, OWASP standards provide voluntary frameworks that organizations adopt to improve security outcomes. This voluntary nature has paradoxically increased their influence—OWASP standards represent community consensus on effective practices, refined through real-world implementation and continuous feedback.

For supply chain security specifically, OWASP has developed standards addressing both traditional software composition concerns and emerging risks from AI systems. These standards complement regulatory requirements by providing the technical detail that regulations often lack. When the EU Cyber Resilience Act requires "appropriate cybersecurity" or NIST SSDF calls for managing third-party components, OWASP standards offer concrete criteria for what "appropriate" and "managed" mean in practice.

Software Component Verification Standard (SCVS)¶

The OWASP Software Component Verification Standard (SCVS) provides a framework for evaluating the security of software supply chains and the components within them. First released in 2017 and maintained by an active community, SCVS establishes measurable requirements that organizations can use to assess their supply chain security maturity and identify improvement priorities.

The standard gained significant traction when NIST incorporated SCVS into the Secure Software Development Framework (SSDF) Version 1.1 in 2022, adding it alongside other supply chain references based on public input. This endorsement by NIST validated SCVS as a practical framework that organizations could use to implement Executive Order 14028's supply chain security requirements.

SCVS organizes requirements into three progressive levels, allowing organizations to adopt practices appropriate to their risk profile and maturity:

Level 1 (Foundational) establishes basic supply chain hygiene suitable for all software. Organizations at this level maintain awareness of their dependencies and have basic processes for managing them. Level 1 requirements focus on: - Maintaining a software bill of materials - Using components from known, reputable sources - Identifying components with known vulnerabilities - Basic provenance verification

Level 2 (Standard) represents industry best practice for most commercial software. Organizations at this level have mature processes for component selection, monitoring, and response. Level 2 requirements add: - Automated dependency analysis - License compliance verification - Component update processes - Vulnerability response procedures - Integrity verification of components

Level 3 (Advanced) addresses high-assurance environments where supply chain compromise could have severe consequences—critical infrastructure, financial systems, healthcare devices, and similar contexts. Level 3 requirements include: - Cryptographic verification of component integrity - Comprehensive provenance documentation - Analysis of transitive dependencies - Reproducible builds - Component security assessment beyond known vulnerabilities

The standard organizes requirements into six verification categories:

V1: Inventory Requirements

Effective supply chain security begins with knowing what components you use. SCVS V1 requirements progress from basic awareness to comprehensive tracking:

• V1.1 (L1): An inventory exists listing all third-party components
• V1.2 (L1): The inventory includes component versions
• V1.3 (L2): The inventory is automatically generated during build
• V1.4 (L2): The inventory includes all transitive dependencies
• V1.5 (L3): The inventory includes component modification history

V2: SBOM Requirements

SCVS V2 addresses software bill of materials creation and management, aligning with regulatory requirements while providing additional technical depth:

• V2.1 (L1): An SBOM exists for the application
• V2.2 (L2): SBOM is in a machine-readable standard format (SPDX, CycloneDX)
• V2.3 (L2): SBOM includes license information for all components
• V2.4 (L2): SBOM includes component hash values
• V2.5 (L3): SBOM is cryptographically signed
• V2.6 (L3): SBOM includes provenance information for all components

V3: Build Environment Requirements

The build environment represents a critical attack surface—compromising build systems enables attackers to inject malicious code into legitimate software. SCVS V3 addresses this risk:

• V3.1 (L1): Build systems are documented
• V3.2 (L2): Build systems use current, patched software
• V3.3 (L2): Build systems are isolated from development environments
• V3.4 (L2): Build outputs are signed
• V3.5 (L3): Builds are reproducible
• V3.6 (L3): Build systems are hardened and monitored

V4: Package Management Requirements

How organizations acquire and store components affects their exposure to supply chain attacks:

• V4.1 (L1): Components are obtained from documented sources
• V4.2 (L2): Package integrity is verified before use
• V4.3 (L2): Private package repositories are used for internal components
• V4.4 (L2): Dependency confusion attacks are mitigated
• V4.5 (L3): Components are obtained through secure channels exclusively

V5: Component Analysis Requirements

Beyond inventory, organizations must assess component security:

• V5.1 (L1): Components are checked against known vulnerability databases
• V5.2 (L2): Vulnerability checking is automated and continuous
• V5.3 (L2): Components are evaluated for security risk before adoption
• V5.4 (L2): Vulnerability response processes exist and are tested
• V5.5 (L3): Components undergo security assessment beyond CVE checking

The progression from Level 1 to Level 2 vulnerability management represents a critical maturity step. Many organizations implement V5.1 by running periodic dependency scans, generating reports with thousands of findings. Without V5.2's automation and continuous monitoring, these reports become stale within days as new vulnerabilities are disclosed. The SolarWinds attack in December 2020 demonstrated this gap—organizations using the compromised Orion platform had no automated way to detect the malicious SUNBURST code, even though their dependency inventories listed Orion as a component.

V6: Pedigree and Provenance Requirements

Understanding where components come from and how they reached you provides crucial context for trust decisions:

• V6.1 (L1): Component sources are documented
• V6.2 (L2): Component integrity is verified against published signatures
• V6.3 (L2): Component authenticity is verified
• V6.4 (L3): Complete chain of custody is documented and verified
• V6.5 (L3): Components can be traced to specific source commits

OWASP Top 10 for LLM Applications¶

The OWASP Top 10 for Large Language Model Applications addresses security risks specific to systems incorporating large language models. First released in 2023 and updated in 2025, this standard identifies critical vulnerabilities in LLM-powered applications, several of which directly concern supply chain security.

The rapid adoption of LLMs created a new category of supply chain risk. Organizations downloading pre-trained models from Hugging Face, using third-party embedding services, or integrating LLM API providers faced questions that traditional SCVS didn't address: How do you verify model integrity? What happens if training data was poisoned? Can you trust model outputs that influence downstream systems? The LLM Top 10 emerged from community recognition that AI systems required supply chain thinking adapted to their unique architecture.

LLM03: Supply Chain Vulnerabilities

This category addresses risks from compromised components in the LLM application stack:

• Vulnerable third-party packages and libraries
• Compromised pre-trained models
• Poisoned training data from external sources
• Outdated or deprecated model versions with known weaknesses

The standard recommends: - Vetting model providers and data sources - Verifying model integrity through checksums and signatures - Monitoring for model behavioral changes indicating compromise - Maintaining inventory of all models and their versions

LLM05: Improper Output Handling

While not directly a supply chain issue, improper output handling becomes a supply chain concern when LLM outputs are consumed by downstream systems. Malicious content generated by a compromised model can propagate through application chains.

LLM06: Excessive Agency

LLM systems with excessive permissions can be exploited to access supply chain infrastructure—package repositories, build systems, or deployment pipelines. The standard emphasizes least-privilege principles for LLM system access.

LLM08: Vector and Embedding Weaknesses

Vector databases and embedding models represent supply chain components that can be compromised: - Malicious embeddings in shared vector stores - Compromised embedding models affecting retrieval - Data poisoning in retrieval-augmented generation (RAG) systems

Supply Chain-Specific Recommendations

The LLM Top 10 provides specific guidance for supply chain security in AI contexts:

1. Model provenance verification: Verify that models come from claimed sources and have not been tampered with
2. Training data auditing: Understand and verify the sources of training data
3. Plugin and tool vetting: Assess security of plugins and tools integrated with LLM systems
4. Continuous monitoring: Monitor model behavior for signs of compromise or drift
5. Dependency management: Apply traditional supply chain security practices to ML frameworks and libraries

OWASP Top 10 for Agentic AI¶

The OWASP Top 10 for Agentic Applications addresses risks specific to autonomous AI systems that take actions in the world—booking appointments, executing code, managing infrastructure, or interacting with other systems. Released in late 2025, this emerging standard recognizes that agentic AI systems create novel supply chain risks.

ASI02: Tool Misuse & Exploitation

Agentic AI systems typically integrate with external tools and services, creating supply chain dependencies:

• Compromised tool APIs that agents call
• Malicious responses from integrated services
• Vulnerable connector libraries
• Unauthorized tool additions or modifications

Mitigations include: - Vetting all integrated tools and services - Implementing tool allowlists - Validating tool responses before acting on them - Monitoring tool integration behavior

ASI06: Memory & Context Poisoning

Agentic systems often maintain persistent memory or context that influences future behavior. This memory can be poisoned through: - Injection attacks that persist malicious instructions - Compromised data sources that agents consult - Manipulation of shared context between agents

ASI07: Insecure Inter-Agent Communication

Systems employing multiple AI agents create internal supply chains where agents depend on outputs from other agents: - Compromised agents propagating malicious outputs - Trust transitivity problems in agent networks - Lack of authentication between agents

ASI04: Agentic Supply Chain Vulnerabilities

This category directly addresses traditional and AI-specific supply chain risks: - Compromised base models affecting all derived agents - Malicious fine-tuning data - Vulnerable orchestration frameworks - Compromised agent deployment infrastructure

The standard recommends comprehensive supply chain security extending to: - Model selection and verification - Training and fine-tuning pipeline security - Orchestration framework security - Runtime environment hardening

Assessment Methodology¶

OWASP standards support both self-assessment and third-party evaluation. Effective assessment requires systematic approach:

Step 1: Scope Definition

Define assessment boundaries: - Which applications or systems are in scope? - What components (direct dependencies, transitive, development tools) are included? - Which SCVS level is the target?

Step 2: Evidence Collection

Gather documentation and artifacts: - SBOM files and generation procedures - Build system configurations and logs - Vulnerability scanning results - Component selection policies and records - Incident response procedures

Step 3: Control Evaluation

Assess each requirement against collected evidence: - Is the control implemented? - Is implementation effective? - Is implementation documented? - Can implementation be demonstrated?

Step 4: Gap Analysis

Document gaps between current state and target level: - Which requirements are not met? - What remediation is required? - What resources are needed? - What timeline is realistic?

Step 5: Remediation Planning

Prioritize gaps based on risk and effort: - High-risk gaps first - Quick wins to build momentum - Dependencies between controls - Resource constraints

Tool Support for OWASP Standards¶

Several tools support OWASP SCVS assessment and implementation. The challenge many organizations face is not lack of tools, but tool proliferation—security teams often discover they're running three different SBOM generators, four vulnerability scanners, and have no unified view of their supply chain posture. Effective SCVS implementation requires selecting an integrated toolchain rather than accumulating point solutions.

SBOM Generation - syft: Generates SBOMs from container images and filesystems. Particularly effective for organizations using containerized applications, as it can analyze layers to identify components across the entire image stack. - cdxgen: CycloneDX SBOM generator supporting multiple languages. Strong ecosystem support—over 20 programming languages and package managers. - trivy: Multi-purpose scanner including SBOM generation. Many organizations start with Trivy because it combines SBOM creation, vulnerability scanning, and misconfiguration detection in a single tool.

Vulnerability Scanning - grype: Vulnerability scanner consuming SBOMs. Designed to work seamlessly with Syft-generated SBOMs, providing an integrated workflow from inventory to vulnerability detection. - dependency-check: OWASP's own dependency vulnerability scanner. The longest-established tool in this category, with extensive vulnerability database coverage. - osv-scanner: Google's open source vulnerability scanner. Uses the OSV database, which aggregates vulnerability data across multiple ecosystems.

Build Security - SLSA: Framework for build integrity (supports SCVS V3). Provides a roadmap from basic build documentation (SLSA Level 1) to fully verified, non-falsifiable provenance (SLSA Level 4). - Sigstore: Signing and verification toolchain. Addresses the key distribution problem that has historically made signing impractical for many projects—developers can sign artifacts using identity-based certificates rather than managing long-lived keys. - in-toto: Supply chain integrity framework. Allows organizations to define and verify the entire software supply chain, ensuring each step was performed by authorized personnel using approved tools.

Compliance Assessment - OWASP Dependency-Track: Platform for SBOM analysis and vulnerability tracking. Provides a central repository for SBOMs across an organization, enabling portfolio-level visibility into component usage and vulnerabilities. - Scorecard: OpenSSF tool assessing project security practices. Evaluates open source projects against criteria like branch protection, dependency update tools, and security policy presence—helping organizations make informed adoption decisions per SCVS V5.3.

Implementation Roadmap¶

Organizations adopting OWASP supply chain standards should follow a phased approach:

Phase 1: Foundation (Months 1-3)

Achieve SCVS Level 1 baseline: 1. Deploy SBOM generation in build pipelines 2. Implement vulnerability scanning for dependencies 3. Document component sources 4. Establish component inventory

Organizations often struggle with the first step—determining which SBOM tool to use. A pragmatic approach: if you're primarily containerized, start with Syft; if you have a polyglot codebase across multiple repositories, start with cdxgen; if you want an all-in-one solution and can accept vendor lock-in, evaluate commercial platforms like Snyk or GitHub Advanced Security. The key is to start generating SBOMs, even if imperfect, rather than spending months evaluating tools.

Phase 2: Standardization (Months 4-6)

Progress toward SCVS Level 2: 1. Automate dependency analysis 2. Implement license compliance checking 3. Establish vulnerability response procedures 4. Configure package repository security

Phase 2 is where organizations typically encounter policy questions that tools can't answer: What's our acceptable timeline for remediating a high-severity vulnerability? Do we block builds on critical findings or just alert? Who decides when a vulnerability in a transitive dependency is acceptable risk? These policy decisions require involving engineering leadership, not just security teams.

Phase 3: Advancement (Months 7-12)

Address Level 3 requirements for critical systems: 1. Implement cryptographic verification 2. Achieve reproducible builds 3. Document complete provenance 4. Conduct component security assessments

Most organizations never reach Level 3 for their entire codebase—and that's acceptable. Level 3 is designed for high-assurance requirements. A healthcare device manufacturer might implement Level 3 controls for firmware components while accepting Level 2 for internal administrative tools. The framework allows risk-appropriate implementation rather than demanding uniform perfection.

For AI/LLM Systems

Parallel track for organizations deploying AI: 1. Inventory all models and their sources 2. Implement model integrity verification 3. Establish model update procedures 4. Assess plugin and tool security 5. Monitor model behavior for anomalies

We recommend organizations:

1. Start with SCVS Level 1 regardless of ultimate target—foundational practices enable everything else
2. Automate early—manual processes don't scale and create assessment challenges
3. Integrate with existing workflows—supply chain security should be part of development, not separate
4. Extend to AI components as you adopt LLM and agentic systems
5. Reassess regularly—the threat landscape evolves, and your practices should evolve with it