SBOM and VEX Lifecycle

One of the most common questions organizations ask is: "When do I update my SBOM versus my VEX?"

Understanding the distinct lifecycles of SBOMs (static snapshots) and VEX documents (dynamic updates) is critical for effective software transparency operations. Mismanaging these lifecycles leads to confusion, wasted effort, and gaps in vulnerability disclosure.

Fundamental principle

SBOMs are static artifacts tied to software releases. VEX documents are dynamic artifacts tied to vulnerability discoveries.

• SBOM = "Here are the components in version 1.2.0 of our software" (changes when software changes)
• VEX = "Here's the current status of CVE-2024-1234 affecting those components" (changes when analysis changes)

SBOM lifecycle

When SBOMs are generated

Create a new SBOM when:

SBOM versioning strategy

Each SBOM document has:

1. Serial number — unique identifier for the SBOM document itself (e.g., urn:uuid:...)
2. Version number — incremental counter for this SBOM (e.g., version: 1)
3. Timestamp — when the SBOM was generated
4. Subject version — the software version being described (e.g., product version 1.2.0)

Example progression:

Software v1.0.0 → SBOM serial#001, version 1, timestamp 2025-01-15
Software v1.0.1 → SBOM serial#002, version 1, timestamp 2025-02-10
Software v1.1.0 → SBOM serial#003, version 1, timestamp 2025-03-20

SBOM retention

Retain SBOMs for:

• Active software versions — entire support lifecycle
• Legacy versions — as long as deployed in customer environments (typically 2-5 years post-EOL)
• Compliance — per regulatory requirements (e.g., medical devices may require 10+ years)

See Reference - Retention Policies for detailed guidance.

VEX lifecycle

When VEX is published

Create or update VEX when:

VEX status progression

VEX documents typically progress through these states:

1. under_investigation → Initial response (within hours/days)
2. not_affected OR affected → Analysis complete (within days/weeks)
   ├─ If not_affected → Document justification, no further updates
   └─ If affected → Develop fix
3. fixed → Patch released (timeline varies)

VEX versioning strategy

Each VEX update creates a new version:

Example progression for CVE-2024-1234 affecting Product v1.0.0:

VEX serial#101, version 1, 2025-01-20
  Status: under_investigation

VEX serial#101, version 2, 2025-01-22
  Status: affected
  Response: will_fix

VEX serial#101, version 3, 2025-02-10
  Status: fixed (in version 1.0.1)
  Affected: 1.0.0
  Fixed: 1.0.1

Coordinating SBOM and VEX

Referencing between artifacts

VEX documents reference SBOMs through:

• Product identifiers — matching name and version fields
• Component PURLs — precise component identification
• Serial numbers — explicit SBOM document reference (optional but recommended)

Example reference in VEX:

{
  "metadata": {
    "component": {
      "name": "example-app",
      "version": "1.0.0",
      "purl": "pkg:swid/Example%20Inc/example.com/example-app@1.0.0"
    }
  },
  "vulnerabilities": [
    {
      "id": "CVE-2024-1234",
      "affects": [
        { "ref": "pkg:npm/axios@0.21.1" }  // From SBOM
      ]
    }
  ]
}

Practical coordination scenarios

Scenario 1: New release with no new vulnerabilities

Action:

• Generate new SBOM for new release
• No VEX update required (existing VEX still applies to old version)

Example:

Product v1.0.0 → SBOM#001 + VEX#101 (CVE-2024-1234: affected)
Product v1.1.0 → SBOM#002 (new SBOM)
                 VEX#101 unchanged (still describes v1.0.0)

Scenario 2: New release that fixes vulnerability

Action:

• Generate new SBOM for new release
• Update VEX to show "fixed" status for new version

Example:

Product v1.0.0 → SBOM#001 + VEX#101 v1 (CVE-2024-1234: affected)
Product v1.0.1 → SBOM#002 (new SBOM)
                 VEX#101 v2 (CVE-2024-1234: fixed in v1.0.1)

Scenario 3: New vulnerability discovered for existing version

Action:

• SBOM unchanged (software didn't change)
• Publish new VEX for new vulnerability

Example:

Product v1.0.0 → SBOM#001 (unchanged)
                 VEX#101 (CVE-2024-1234: affected)
                 VEX#102 (CVE-2024-5678: under_investigation) ← NEW

Scenario 4: Multiple versions in support

Action:

• Maintain separate SBOMs for each version
• VEX documents can reference multiple versions

Example:

Product v1.0.0 → SBOM#001
Product v1.1.0 → SBOM#002
Product v2.0.0 → SBOM#003

VEX#101 (CVE-2024-1234):
  - v1.0.0: affected
  - v1.1.0: affected
  - v2.0.0: not_affected (justification: vulnerable_code_not_present)

Trigger events matrix

This matrix summarizes when to take action:

See Trigger Events and Updates for detailed decision trees.

Common mistakes

Mistake 1: Regenerating SBOM for every VEX update

Problem: Wastes resources, creates version confusion.

Solution: Only generate new SBOM when software changes.

Mistake 2: Not updating VEX after patch release

Problem: Customers don't know vulnerability is fixed.

Solution: Always update VEX status to "fixed" when releasing patch.

Mistake 3: Single VEX document for all versions

Problem: Unclear which versions are affected vs fixed.

Solution: Use version-specific status in VEX or separate VEX per version.

Mistake 4: Outdated VEX references

Problem: VEX references old SBOM after software update.

Solution: Review VEX documents when releasing new versions, update component references.

Automation considerations

For efficient lifecycle management:

• SBOM generation — automate in CI/CD pipeline, triggered by build/release
• VEX publication — automate initial "under_investigation" VEX when CVE published
• VEX updates — semi-automated: tools suggest updates, humans approve status/justification
• Synchronization — automated checks ensure VEX references valid SBOM components

See Automation Strategies for implementation patterns.

Example: Complete lifecycle

Month 1: Company releases Product v1.0.0

• Generate SBOM#001 for v1.0.0
• No vulnerabilities known yet

Month 2: CVE-2024-1234 published affecting component in v1.0.0

• SBOM#001 unchanged
• Publish VEX#101 v1: "under_investigation"

Month 2: Analysis complete, vulnerability confirmed

• SBOM#001 unchanged
• Publish VEX#101 v2: "affected", "will_fix"

Month 3: Release v1.0.1 with fix

• Generate SBOM#002 for v1.0.1
• Publish VEX#101 v3: "fixed" (v1.0.1), "affected" (v1.0.0)

Month 4: CVE-2024-5678 published, analysis shows not affected

• SBOM#001 unchanged (v1.0.0)
• SBOM#002 unchanged (v1.0.1)
• Publish VEX#102 v1: "not_affected", justification: "vulnerable_code_not_present"

Month 6: EOL v1.0.0, only v1.0.1 supported

• Archive SBOM#001 (retain for compliance)
• VEX#101 v3 remains (historical record)
• Future VEX documents only reference v1.0.1+

Next steps

• Understand detailed Trigger Events and Updates
• Review VEX publication workflow for producers
• See Monitor for Updates for consumers
• Explore Automation Strategies for scaling