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. Published as a versioned OWASP standard 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 referenced SCVS² in the Secure Software Development Framework (SSDF) Version 1.1 in 2022, listing it alongside other supply chain resources in its references section based on public input. This reference by NIST—while not a formal incorporation or endorsement—validated SCVS as a practical framework that organizations could use to implement Executive Order 14028's supply chain security requirements. Organizations seeking to implement SSDF's high-level practices can look to SCVS for more detailed, verifiable 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 build-time visibility to continuously maintained inventories:

• V1.1 (L1-L3): All direct and transitive components and their versions are known at completion of a build
• V1.3 (L1-L3): An accurate inventory of all third-party components is available in a machine-readable format
• V1.4 (L1-L3): Software bills of materials are generated for publicly or commercially available applications
• V1.5 (L2-L3): Software bills of materials are required for new procurements
• V1.6 (L3): Software bills of materials are continuously maintained and current for all systems

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-L3): A structured, machine-readable SBOM format is present (for example, SPDX³ or CycloneDX⁴)
• V2.2 (L2-L3): SBOM creation is automated and reproducible
• V2.4 (L2-L3): SBOMs are signed by the publisher, supplier, or certifying authority
• V2.5 (L2-L3): SBOM signature verification exists
• V2.14 (L1-L3): Components defined in SBOMs have accurate license information
• V2.18 (L3): Components defined in SBOMs have one or more file hashes

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-L3): The application uses a repeatable build
• V3.2 (L1-L3): Documentation exists on how the application is built and how to repeat the build
• V3.3 (L1-L3): The application uses a continuous integration build pipeline
• V3.4 (L2-L3): The build pipeline prohibits alteration of the build outside the job performing the build
• V3.10 and V3.11 (L2-L3): The build pipeline enforces authentication and authorization with default-deny behavior
• V3.18 (L1-L3): Checksums of all first-party and third-party components are documented for every build

V4: Package Management Requirements

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

• V4.1 (L1-L3): Binary components are retrieved from a package repository
• V4.3 (L2-L3): Package repositories require strong authentication
• V4.4 (L2-L3): Package repositories support multi-factor authentication for component publishing
• V4.13 and V4.14 (L1-L3): Package managers verify package integrity when retrieving packages from remote repositories or file systems
• V4.15 and V4.16 (L1-L3): Package repositories enforce TLS, and package managers validate TLS certificate chains
• V4.18 (L1-L3): Package managers do not execute component code

V5: Component Analysis Requirements

Beyond inventory, organizations must assess component security:

• V5.1 (L1-L3): Components can be analyzed with linters or static analysis tools
• V5.2 (L2-L3): Components are analyzed with linters or static analysis tools before use
• V5.4 (L1-L3): An automated process identifies publicly disclosed vulnerabilities in third-party and open source components
• V5.7 (L1-L3): An automated process identifies out-of-date components
• V5.8 (L3): An automated process identifies end-of-life or end-of-support components
• V5.12 (L1-L3): An automated process identifies component licenses

The progression from inventory to automated component analysis represents a critical maturity step. Many organizations run periodic dependency scans, generating reports with thousands of findings. Without automated vulnerability identification and version 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 (L2-L3): Point of origin is verifiable for source code and binary components
• V6.2 (L3): Chain of custody is auditable for source code and binary components
• V6.3 (L1-L3): Provenance of modified components is known and documented
• V6.4 (L2-L3): Pedigree of component modification is documented and verifiable
• V6.5 (L2-L3): Modified components are uniquely identified and distinct from the origin component

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

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. Published as a 2026 framework, this emerging standard recognizes that agentic AI systems create novel supply chain risks.

Tool Misuse and 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

Memory and 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

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

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 component adoption decisions aligned with SCVS component analysis practices.

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