Managing Software Inventory

Overview

Most organizations have software from multiple sources:

• Applications you develop - Built with your own code and open-source components
• Commercial software - Licensed products and SaaS platforms
• Open-source projects - Community software integrated into your stack
• Vendor software - Components purchased from third parties
• Legacy systems - Older applications from acquisitions or internal development

Without a unified view, you lack critical understanding of your total risk across vulnerabilities, licenses, and compliance.

The Traditional Approach's Limitations

Most teams focus on scanning their own code with SCA (Software Composition Analysis) tools, missing critical visibility:

• Vendor software - No source code to scan, requires SBOMs
• Commercial products - SCA tools can't analyze licensed software
• Acquired companies - Different tech stacks, CI/CD systems, and tooling
• Distributed organizations - Multiple teams, divisions, and tool choices

SBOMs solve this by providing an "ingredients list" directly from the vendor, without needing source code or tool integration.

Building Your Software Inventory with SBOM Observer

1. Collect SBOMs from All Sources

From applications you build:

# Generate a CycloneDX SBOM during your build (see /getting-started/observer-cli)
observer fs -o sbom.json .

From vendors and commercial software:

• Request SBOM as part of procurement or support contracts
• Check vendor documentation for SBOM availability
• Upload vendor-provided SBOMs to SBOM Observer

From open-source projects:

• Some projects include SBOM in releases
• Generate using syft, cyclonedx-python, or similar tools
• Upload to SBOM Observer for tracking

2. Establish Unified Visibility

SBOM Observer gives you a single pane of glass showing:

• Total component inventory - All libraries, tools, and packages across your organization
• Versions in use - Which versions are deployed in production
• Vulnerabilities - Security issues affecting each component
• License information - All licenses in your stack
• Policy violations - Components violating your standards
• Vendor information - Which components come from which vendors

3. Organize by Division, Technology Stack, or Environment

You don't need to standardize your entire organization on one CI/CD system or tech stack. SBOMs work across:

• Different programming languages - Java, Python, Go, Node.js, etc.
• Different deployment models - Container, serverless, virtual machines
• Different industries - Finance, healthcare, e-commerce, etc.
• Geographically distributed teams - No centralized tooling required

4. Quick Risk Assessment Without Migration

Compare risk across your organization immediately:

Organization Risk Overview:
- 1,234 total components tracked
- 45 critical vulnerabilities requiring immediate attention
- 89 components with license issues
- 234 end-of-life components in use
- 12 vendor software packages with security concerns

All this without requiring teams to migrate to new tools or processes.

5. VEX Documents for Precision

Use VEX (Vulnerability Exploitability eXchange) documents to indicate which vulnerabilities actually impact your software:

Example VEX Statement:
- CVE-2024-1234 in OpenSSL 3.0.1
- Status: NOT AFFECTED (we use version 3.0.5 which fixed it)
- Status: AFFECTED (we use the vulnerable version, patch planned for Q1)

This prevents "false positive" vulnerabilities from cluttering your view.

Real-World Scenarios

Scenario 1: Merger & Acquisition Risk Assessment

You're acquiring a company. You need immediate understanding of their software stack.

Traditional approach: Months of manual audits, infrastructure migration planning With SBOM Observer:

1. Request SBOMs from all applications
2. Upload to SBOM Observer
3. Run against your security policies
4. Generate risk report in hours

Result: Understand acquisition risk before closing the deal.

Scenario 2: Distributed Divisions

Your organization has finance, healthcare, and e-commerce divisions with completely different tech stacks.

Traditional approach: Maintain separate tools, policies, and processes for each division With SBOM Observer:

1. Each division generates SBOMs their own way
2. All upload to centralized SBOM Observer
3. Organization-wide policies apply uniformly
4. Compare vulnerability exposure across divisions

Result: Unified governance without forcing standardization.

Scenario 3: Vendor Risk Monitoring

You use 50+ SaaS and commercial products. You need to track vulnerabilities in products you don't control.

Traditional approach: Manual tracking, missed alerts With SBOM Observer:

1. Request SBOMs from vendors
2. Upload and monitor for new vulnerabilities
3. Automatic alerts when vendor software is affected
4. Share vulnerability status with vendors

Result: Proactive vendor security management.

Scenario 4: Legacy System Inventory

You have old systems from acquisitions, custom-built applications, and third-party software running in production.

Traditional approach: Scattered spreadsheets, outdated documentation With SBOM Observer:

1. Generate or obtain SBOMs for all systems
2. Create unified inventory
3. Identify high-risk components
4. Plan modernization priorities

Result: Data-driven decisions on which systems to upgrade or retire.

Best Practices

✅ Do:

• Establish SBOM generation as part of your build process
• Request SBOMs from all software vendors
• Monitor inventory changes over time
• Use policies to maintain consistency
• Share inventory data with security and compliance teams
• Update vendors on vulnerability findings
• Use VEX documents to clarify vulnerability impact

❌ Don't:

• Assume you understand your complete software stack
• Skip tracking vendor software or commercial products
• Let inventory become stale between updates
• Treat inventory as a one-time audit exercise
• Ignore components from acquisitions or mergers
• Forget to include all tech stacks and divisions

Implementation Guide

Phase 1: Initial Inventory (Week 1)

• Identify all software sources in your organization
• Request SBOMs from vendors
• Generate SBOMs for your applications

Phase 2: Unified View (Weeks 2-3)

• Upload all SBOMs to SBOM Observer
• Establish organizational structure (divisions, teams)
• Create baseline inventory report

Phase 3: Ongoing Management (Week 4+)

• Integrate SBOM generation into CI/CD
• Set up regular vulnerability checks
• Monitor inventory changes monthly

Next Steps

1. Set up the Observer CLI
2. Generate SBOMs
3. Upload to SBOM Observer
4. Share and analyze

Related Topics

• Internal SBOMs - For code you build
• External SBOMs - For vendor software
• VEX Documents - For vulnerability precision