Producer Guide

Organisations that build and ship software are expected to provide machine-readable evidence of what their products contain. Customers ask for it, and regulations like the EU Cyber Resilience Act (CRA) and NIS2 require it. Automotive, critical infrastructure, financial services, and government sectors set additional bars.

This guide covers what producers are expected to provide, how to communicate vulnerability impact at scale, and how transparency fits the release process.

What producers provide

Producers are responsible for three types of transparency artifacts:

SBOM. A Software Bill of Materials is a machine-readable inventory of the components in a software product: names, versions, and dependency relationships. Producers generate an SBOM for every release. It is the foundation for all downstream transparency activities.

VEX. A Vulnerability Exploitability eXchange document communicates whether a known vulnerability in a component affects the product. Producers issue VEX statements as vulnerabilities are disclosed and analysis progresses.

VDR. A Vulnerability Disclosure Report documents all known vulnerabilities across a product's components. Where VEX filters to specific impact assessments, VDR provides the complete inventory.

Content Requirements define the fields, identifiers, and structures that make each artifact actionable.

Communicating vulnerability impact

A CVE in a component does not mean the product is vulnerable. The vulnerable code path may be unreachable, a configuration may neutralize the issue, or the affected function may not be called. Producers who have done the analysis need a way to communicate that result.

VEX provides that mechanism. The producer performs the analysis once and publishes a machine-readable statement that all downstream consumers can process, replacing individual customer inquiries with a single authoritative assessment. VEX statuses tell customers where in the process the producer is regarding a specific vulnerability: under investigation, not affected, affected, or fixed.

These statuses evolve as analysis progresses and patches ship. Producers need a process that tracks open investigations and issues updated statements at each transition.

See VEX for the full concept, status definitions, and lifecycle, and VEX/VDR Requirements for field-level specifications.

Distributing artifacts

Producers distribute artifacts through controlled channels: customer portals with access controls, artifact repositories alongside release packages, or direct delivery as part of contractual obligations.

A commercial vendor serving enterprise customers may deliver SBOMs through a dedicated portal. An open-source project may publish them alongside release assets.

The Release Management use case covers delivery cadence, release coordination, and update notification in detail.

Transparency in the release process

SBOM generation aligns with the release lifecycle. Generate an SBOM for every release. Three other events trigger regeneration:

• A supplier corrects a component or license in their upstream SBOM.
• The producer discovers incorrect data in their own SBOM (wrong version, missing component).
• A generation tool update produces materially different output for the same input.

VEX follows a different cadence. New vulnerability disclosures trigger under_investigation statements regardless of the release schedule. Status updates follow as analysis completes or patches ship. A product in long-term support may receive VEX updates long after its last release.

The CRA requires producers to maintain current SBOMs throughout a product's support period. Generation continues as long as the product is supported.

See Generate SBOMs for the full generation workflow and Release Management for how transparency fits broader release coordination.

Regulatory and sector context

EU regulations set baseline transparency requirements. The Cyber Resilience Act (CRA) mandates that producers of products with digital elements provide SBOMs and maintain vulnerability handling processes. NIS2 extends transparency obligations to operators of essential services and their supply chains.

Sector-specific expectations often go further:

• Automotive. Sector-specific regulatory frameworks require vulnerability management across the vehicle lifecycle. SBOMs and VEX feed into type-approval documentation.
• Critical infrastructure. Energy, water, and transport operators face both CRA and NIS2. Their suppliers (producers) must deliver artifacts that meet both regulatory sets.
• Financial services. DORA requires ICT risk management, including third-party software assessment. Transparency artifacts support the due diligence process.
• Government. Public-sector procurement includes SBOM requirements in tender specifications, following CISA guidance and EU member-state directives.

The framework defines two maturity levels across both content and operations. Content Requirements specify the data quality bar: L1 (Basic) covers minimum viable fields, L2 (Advanced) adds complete dependency trees and signed artifacts. The Operational Model defines corresponding operational expectations: L1 covers semi-automated generation at release milestones, L2 adds fully automated CI/CD integration with quality gates. L1 meets baseline compliance; L2 satisfies the expectations of regulated-sector customers.

Related workflows and use cases

Browse all Use Cases and Workflows, or start with the most relevant for producers:

Organisations with existing SBOM practices can use the Maturity Assessment to benchmark current capabilities and identify specific areas for improvement across generation, distribution, and vulnerability communication.