SBOM Observer Docs

How-to guides

Software Procurement & Risk Assessment

Evaluate software risk during procurement, acquisitions, and vendor assessments using SBOM analysis.

Overview

When evaluating software for purchase or when acquiring companies, you need rapid assessment of:

Security vulnerabilities in the software you're acquiring
License compliance risks that could affect your operations
Component quality and vendor support status
Regulatory compliance with your standards
Integration complexity with your existing systems

SBOMs enable this assessment without requiring deep technical analysis or source code access.

Why Software Procurement Matters

Poor procurement decisions can result in:

Security breaches from vulnerable software you didn't know about
License violations that create legal liability
Compliance failures with your regulatory requirements
Integration headaches with incompatible components
Hidden costs from unexpected vendor lock-in or support issues
Operational disruptions from poor quality software

The SBOM-Driven Procurement Process

Phase 1: Request & Collect SBOMs

During vendor evaluation:

Request SBOM as part of your procurement requirements
Include SBOM generation in your vendor questionnaire
Make SBOM availability a requirement for enterprise customers

For acquisitions:

Request SBOMs for all applications and systems
Include in due diligence process
Assess software portfolio before closing deal

Phase 2: Analyze Software Composition

Upload SBOMs to SBOM Observer and analyze:

Component Inventory:

Total number of components
Distribution of libraries and frameworks
Version diversity (modern vs. outdated)

Technology Stack:

Programming languages used
Popular frameworks and libraries
Vendor lock-in dependencies

Supply Chain Risk:

Components with single maintainers
Inactive or abandoned projects
Commercial vs. open-source distribution

Phase 3: Security Assessment

Vulnerability Analysis:

Known CVEs in components
Severity distribution (critical, high, medium, low)
Patch availability and age
Components with active security support

Risk Scoring:

Critical vulnerabilities require immediate patching
Medium vulnerabilities need remediation plan
Low vulnerabilities acceptable with monitoring

Vulnerability Report Example:
- 3 Critical CVEs (require immediate fix)
- 12 High severity (fix within 30 days)
- 24 Medium severity (fix within 90 days)
- 45 Low severity (monitor and plan)

Phase 4: License & Compliance Check

License Analysis:

Identify all licenses in use
Check for problematic combinations
Verify compatibility with your business model

Compliance Verification:

Check against your security policies
Verify regulatory compliance (NIS2, CRA, etc.)
Assess vendor compliance standards

Policy Violation Report:
- 5 GPL components (requires review)
- 2 end-of-life components (must upgrade)
- 8 components without vendor support (high risk)
- DORA requirement violations: 3 components

Phase 5: Generate Risk Report

Create a structured risk assessment:

Executive Summary:

Overall risk level (green/yellow/red)
Key findings and recommendations
Integration and cost implications

Detailed Analysis:

Component inventory details
Vulnerability assessment
License compliance status
Regulatory compliance gaps
Remediation costs and timeline

Recommendations:

Proceed with caution/approval/rejection
Required fixes before deployment
Post-acquisition roadmap

Real-World Procurement Scenarios

Scenario 1: SaaS Vendor Evaluation

You're evaluating three SaaS platforms for customer data management.

Process:

Request SBOMs from all three vendors
Upload to SBOM Observer
Compare against your security policies
Check for license conflicts with your stack
Verify regulatory compliance (especially data handling)

Result:

Vendor A: 45 critical vulnerabilities, unknown licenses → High Risk
Vendor B: 3 high vulnerabilities, all compliant → Acceptable
Vendor C: 0 critical, but GPL license → Rejected (incompatible business model)

Decision: Proceed with Vendor B, negotiate security roadmap for high vulnerabilities.

Scenario 2: Merger & Acquisition Due Diligence

You're acquiring a competitor with 50+ applications.

Process:

Request SBOMs for all applications
Upload entire portfolio to SBOM Observer
Scan against your compliance requirements
Identify integration challenges
Assess modernization needs

Findings:

234 total components across portfolio
156 vulnerable components (requires patching)
23 end-of-life components (require modernization)
Estimated remediation cost: $2M over 18 months
Integration timeline: 12 months for core systems

Impact on Deal: Adjust acquisition price based on modernization costs, create integration roadmap.

Scenario 3: Open-Source Library Adoption

You're considering adopting a new open-source library for critical functionality.

Process:

Get SBOM from project (check project repository or generate it)
Upload to SBOM Observer
Check library's dependencies
Verify license compatibility
Assess vulnerability and maintenance status

Analysis:

Library: 12 dependencies
2 GPL dependencies (evaluate licensing impact)
5 outdated dependencies (library maintenance concern)
Active development and community support

Decision: Adopt with caveat - library maintainer must update dependencies.

Scenario 4: Cloud Platform Migration

You're migrating from Platform A to Platform B and need to understand both stacks.

Process:

Get SBOMs for both platforms
Compare components and versions
Identify potential breaking changes
Plan dependency migration
Test compatibility before cutover

Result:

45% shared components across platforms
23 components need version upgrades
8 components have no direct equivalent → custom development needed
Migration effort: 3 months

Procurement Checklist

✅ Before Procurement:

Define security requirements and policies
Create procurement questionnaire including SBOM request
Establish what makes software unacceptable
Get executive alignment on risk tolerance

✅ During Evaluation:

Request SBOM from all vendors
Upload to SBOM Observer
Run against your policy requirements
Document risk assessment
Get approval from security team

✅ Before Deployment:

Update SBOM to current version
Re-run compliance checks
Plan remediation for any violations
Get sign-off from operations and security

✅ During Integration:

Monitor for new vulnerabilities
Track vendor patches and updates
Update your inventory with new components
Communicate risks to stakeholders

Best Practices

✅ Do:

Make SBOM a procurement requirement
Assess risk early in evaluation process
Compare alternatives systematically
Document assessment for audits
Plan remediation before deployment
Build vendor relationships on security
Request vulnerability notifications

❌ Don't:

Deploy software without security assessment
Ignore license compliance requirements
Assume vendor promises without verification
Skip policy checking due to time pressure
Forget post-deployment monitoring
Negotiate away security requirements
Deploy critical software with known critical CVEs

Risk Scoring Framework

Critical Risk (Red Flag)

Multiple critical vulnerabilities without patches
Incompatible licenses for your business model
Regulatory compliance violations
No vendor support or inactive project
Recommendation: Reject or require remediation

High Risk (Yellow Flag)

Several high-severity vulnerabilities with patches available
Minor license concerns with available solutions
Limited vendor support or maturity questions
Recommendation: Proceed with caution, plan remediation

Acceptable Risk (Green Light)

Low or no critical/high vulnerabilities
Compatible licenses
Active vendor support or maintenance
Meets compliance requirements
Recommendation: Proceed with standard onboarding

Next Steps