# Producer Guide (/docs/roles/producer)

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 [#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](/docs/content-requirements) define the fields, identifiers, and structures that make each artifact actionable.

<Callout title="Where are you starting from?" type="info">
  **New to SBOMs?** Begin with SBOM generation. The [Generate SBOMs](/docs/operational-model/workflows/generate-sboms) workflow covers when to generate, what lifecycle phase to target, and where to store results.

  **Already generating SBOMs?** Focus on content quality and VEX adoption. Review [Content Requirements](/docs/content-requirements) to benchmark your SBOMs against the framework's expectations, then read the vulnerability communication section below.
</Callout>

## Communicating vulnerability impact [#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](/docs/operational-model/core-concepts/vex) for the full concept, status definitions, and lifecycle, and [VEX/VDR Requirements](/docs/content-requirements/vex-vdr) for field-level specifications.

## Distributing artifacts [#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](/docs/operational-model/use-cases/release-management) use case covers delivery cadence, release coordination, and update notification in detail.

## Transparency in the release process [#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](/docs/operational-model/workflows/generate-sboms) for the full generation workflow and [Release Management](/docs/operational-model/use-cases/release-management) for how transparency fits broader release coordination.

## Regulatory and sector context [#regulatory-and-sector-context]

EU regulations set baseline transparency requirements. The Cyber Resilience Act (CRA) requires manufacturers of products with digital elements to document components in an SBOM and to maintain vulnerability handling processes. NIS2 extends transparency obligations to operators of essential services and their supply chains. See [Regulatory Compliance](/docs/operational-model/use-cases/regulatory-compliance) for obligations and dates.

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 fall under NIS2 and pass its supply chain requirements on to their suppliers. Producers selling to them should expect SBOM and VEX requirements in procurement.
* **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](/docs/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](/docs/operational-model/core-concepts/maturity-levels) defines corresponding operational expectations: L1 covers semi-automated generation at release milestones, L2 adds fully automated CI/CD integration with quality gates. L1 covers the regulatory minimum; L2 satisfies the expectations of regulated-sector customers.

## Related workflows and use cases [#related-workflows-and-use-cases]

Browse all [Use Cases](/docs/operational-model/use-cases) and [Workflows](/docs/operational-model/workflows), or start with the most relevant for producers:

<Cards>
  <Card title="Generate SBOMs" href="/docs/operational-model/workflows/generate-sboms" description="When to generate, what lifecycle phase to target, and where to store results." />

  <Card title="Release Management" href="/docs/operational-model/use-cases/release-management" description="Coordinate transparency artifacts with release timing, delivery, and updates." />

  <Card title="Vulnerability Disclosure" href="/docs/operational-model/workflows/vulnerability-disclosure" description="Responding to CVE advisories and communicating impact via VEX." />

  <Card title="Vulnerability Management" href="/docs/operational-model/use-cases/vulnerability-management" description="Using SBOMs and VEX for impact assessment and prioritization." />

  <Card title="Release Management" href="/docs/operational-model/use-cases/release-management" description="Coordinating transparency artifacts with the release lifecycle." />
</Cards>

Organisations with existing SBOM practices can use the [Maturity Assessment](/docs/assessments/maturity) to benchmark current capabilities and identify specific areas for improvement across generation, distribution, and vulnerability communication.