Trigger Events and Updates

Knowing precisely when to generate SBOMs, publish VEX documents, or update existing artifacts prevents both waste (unnecessary work) and gaps (missed compliance obligations). This page provides decision trees and automation triggers for each scenario.

Decision framework

Use this decision tree to determine required actions:

EVENT OCCURS
    ↓
Is this a software change?
    ├─ YES → Did components change?
    │         ├─ YES → Generate new SBOM
    │         └─ NO → Re-evaluate (may be config-only)
    │
    └─ NO → Is this a vulnerability event?
              ├─ YES → Publish or update VEX
              └─ NO → Is this metadata correction?
                        ├─ YES → Update existing artifact
                        └─ NO → No action required

SBOM generation triggers

Mandatory SBOM generation

Generate a new SBOM when:

Optional SBOM updates

Consider generating new SBOM when:

NOT SBOM generation triggers

Do NOT generate new SBOM when:

VEX publication triggers

Initial VEX publication

Publish a new VEX document when:

VEX updates

Update existing VEX when:

VEX versioning triggers

Create a new VEX version (increment version number) when:

• Analysis status changes (under_investigation → affected)
• New information becomes available (exploit details, EPSS score)
• Mitigation guidance changes
• Affected version list changes

Do NOT create new VEX version for:

• Typo corrections (minor editorial fixes)
• Formatting changes
• Non-substantive metadata updates

Automation decision tree

Use this decision tree to determine automation strategy:

Can this trigger be automated?

EVENT OCCURS
    ↓
Is detection automated?
    ├─ YES → Proceed to automation
    └─ NO → Manual detection required
              ↓
         Can detection be automated?
              ├─ YES → Implement detection automation
              └─ NO → Document manual checklist
                      ↓
Is response deterministic?
    ├─ YES → Fully automate action
    │         Examples: CI/CD SBOM generation, initial VEX draft
    │
    └─ NO → Requires human judgment
              ↓
         Semi-automate:
         - System detects event
         - System drafts response
         - Human reviews and approves
              Examples: VEX status determination, vulnerability impact analysis

Trigger event matrix

Comprehensive matrix of events and required actions:

Implementation patterns

Pattern 1: CI/CD integration (full automation)

Trigger: Git commit to release branch

Actions:

1. Build pipeline starts
2. Dependencies resolved
3. SBOM generation tool runs
4. SBOM validated against schema
5. SBOM signed
6. SBOM published to repository
7. VEX reviewed for applicability (if dependencies changed)

Tools: GitHub Actions, GitLab CI, Jenkins + Syft/CycloneDX plugins

Pattern 2: Vulnerability monitoring (semi-automation)

Trigger: CVE published in NVD/vendor advisory

Actions:

1. Monitoring system detects CVE
2. System queries SBOM repository for affected products
3. System generates draft VEX with under_investigation status
4. Alert sent to security team
5. Human analyzes impact
6. Human updates VEX status with justification
7. VEX published

Tools: Dependency-Track, vulnerability scanners + custom scripts

Pattern 3: Manual coordination (low-volume)

Trigger: Scheduled review (weekly/monthly)

Actions:

1. Review all changes since last SBOM
2. Determine if new SBOM needed
3. Review all new vulnerabilities
4. Determine VEX updates needed
5. Batch generate/update artifacts
6. Publish together

Suitable for: Legacy systems, low-frequency releases, resource-constrained teams

Handling edge cases

Edge case 1: Multiple releases in single day

Challenge: Don't generate SBOM for every commit during active development.

Solution:

• Generate SBOM only for tagged releases
• Use semantic versioning to distinguish releases from builds
• Pre-release versions (1.0.0-alpha.1) get SBOMs, commits don't

Edge case 2: Vulnerability affecting multiple versions

Challenge: Avoid redundant VEX documents.

Solution:

• Single VEX can reference multiple product versions
• Use version ranges where appropriate
• Clearly indicate which versions affected vs fixed

Edge case 3: Dependency change with same version number

Challenge: Dependency resolved to different patch version due to new release (e.g., ^1.2.0 resolves to 1.2.5 instead of 1.2.3).

Solution:

• Always generate new SBOM when lock file changes
• Hash-based artifact identification catches this
• Document in SBOM metadata that lock file changed

Edge case 4: False positive vulnerability report

Challenge: Automated systems flag vulnerability that doesn't actually affect your product.

Solution:

• Publish VEX with not_affected status
• Include justification explaining why
• Prevents customers from being alarmed by security scanners

Checklist for trigger implementation

Use this checklist when setting up automation:

Detection:

• Can detect event automatically (webhook, polling, filesystem watch)
• Can distinguish between trigger types (release vs commit, major vs minor)
• Can access necessary context (commit messages, dependency diffs, CVE details)

Decision:

• Clear criteria for action (when to generate SBOM, when to update VEX)
• Documented exceptions (edge cases handled appropriately)
• Human approval points identified (where automation defers to judgment)

Action:

• Automated generation/update process
• Validation before publication
• Rollback mechanism if generation fails
• Notifications to relevant teams

Monitoring:

• Logging of all trigger events
• Alerts for failed automations
• Metrics on trigger frequency and response time
• Audit trail for manual overrides

Next steps

• Implement triggers based on your maturity level in Automation Strategies
• Review specific workflows: Generate SBOMs or Publish VEX
• Understand broader context in SBOM and VEX Lifecycle