Vendor transparency workflows

Regulations like DORA, NIS2, and EO14028 require visibility into third-party software. You need to know what's in vendor products, monitor for vulnerabilities, and prove you're managing the risks.

This guide shows how to track vendor components using SBOM Observer.

Why This Matters

Most organizations run software they didn't build. Commercial products, open-source libraries, managed services - all introduce vulnerabilities you don't control.

Without SBOMs from suppliers, you can't:

• Know what components are in vendor software
• Detect when vulnerabilities affect your deployments
• Meet regulatory requirements for supply chain security
• Respond quickly when critical issues are disclosed

SBOM Observer automates vendor tracking by continuously monitoring their components and alerting you to new risks.

Collecting Vendor SBOMs

observer upload vendor-product-v1.2.3.cdx.json

Each upload creates a versioned record for compliance and forensics.

Continuous Monitoring

Once uploaded, SBOM Observer continuously scans vendor components against vulnerability databases. New CVEs are detected automatically as they're disclosed.

See the supported ecosystems page for complete coverage details.

Viewing vulnerabilities

Navigate to Vulnerabilities to see all issues across vendor components. Filter by:

• Severity (Critical, High, Medium, Low)
• EPSS score (exploit probability)
• Vendor or product

Analyzing Impact

When a new CVE is disclosed, you need to know immediately if and where you're affected.

Dependency visualization

SBOM Observer shows the complete dependency chain for each vulnerability - which vendors, products, and environments are impacted.

VEX statements

Import VEX (Vulnerability Exploitability eXchange) data from suppliers to mark vulnerabilities as not affected, mitigated, or resolved. This prevents wasted time investigating issues that don't apply to your deployments.

Managing Risk and Remediation

Thousands of new CVEs are published every year. You can't fix everything. Focus on what matters.

Defining policies

Create policies that enforce your organization's risk tolerance. For example, block critical vulnerabilities in production with high exploit probability:

See the policy writing guide for more examples and best practices.

Dashboard monitoring

Track recent security issues and visualize trends across vendors over time. The dashboard highlights what needs attention.

Addressing violations

The Policy Violations view shows:

• Which vendors have the most issues
• What environments are affected
• Trending problems across your vendor components

Prioritize critical violations first. The policy engine automatically flags high-priority issues based on your compliance requirements.

Compliance Documentation

Regulations require proof that you're managing vendor risks.

SBOM Observer provides ready-to-export records for audits and GRC reporting:

• SBOM archive – version history of vendor software
• Vulnerability tracking – timestamps for discovery and remediation
• Policy compliance – automated enforcement results
• Audit trail – who made changes, when, and why

Export this data for auditors or integrate it into your GRC platform.

Next Steps

• Write policies to enforce vendor security standards
• Analyze impact when new CVEs appear
• Share SBOMs with downstream customers
• Enforce policies in CI/CD to block vulnerable vendors before production