25.4 Managing Commercial Software with Open Source Components¶

The commercial software you purchase is rarely 100% proprietary. Studies consistently show that commercial applications contain significant open source components—often 70-90% of the codebase [see Synopsys Black Duck OSSRA 2025 and Sonatype State of the Software Supply Chain 2024]. When Log4Shell emerged in December 2021, organizations discovered Log4j not just in applications they built, but embedded in commercial products from hundreds of vendors. Your vendor risk management must account for the open source supply chain hidden inside commercial products.

This creates a challenging dynamic: you're responsible for the security of your environment, but you don't control the code in commercial products. Vulnerability scanning may detect issues in vendor software that you cannot directly remediate. Effective management requires understanding what's inside vendor products, coordinating with vendors on vulnerability response, and planning for scenarios where vendor support is inadequate.

This section addresses the specific challenges of managing supply chain risk in commercial software that contains open source components.

Understanding Vendor Open Source Usage¶

Before you can manage risk in vendor open source, you need visibility into what exists.

Vendor open source discovery approaches:

Binary analysis tools:

When vendors won't provide SBOMs, binary analysis can extract component information:

Binary analysis has limitations—it may not detect all components, versions may be approximate, and it cannot see inside encrypted or heavily obfuscated binaries.

Creating inventory of vendor open source:

# Commercial Software Open Source Inventory

### Product: [Vendor Product Name]
- Vendor: [Vendor name]
- Version deployed: [Version]
- Last SBOM received: [Date]
- SBOM format: [CycloneDX/SPDX/Proprietary/None]

### Known Open Source Components:
| Component | Version | License | Notes |
|-----------|---------|---------|-------|
| Log4j | 2.17.1 | Apache-2.0 | Updated after Log4Shell |
| OpenSSL | 3.0.x | Apache-2.0 | LTS until 2026 |
| ... | ... | ... | ... |

### Discovery Method:
- [ ] Vendor-provided SBOM
- [ ] Binary analysis
- [ ] Vendor documentation
- [ ] Vulnerability disclosures
- [ ] Unknown/incomplete

### Risk Assessment:
- Critical components present: [Yes/No]
- Known vulnerabilities: [Count by severity]
- Last vulnerability review: [Date]

Requesting and Interpreting Vendor SBOMs¶

SBOMs from vendors enable proactive vulnerability management rather than waiting for vendor notifications.

SBOM request guidance:

When to request: - During procurement evaluation - At contract renewal - After major version upgrades - Following significant security incidents - Periodically (quarterly or annually) for critical systems

What to specify in requests:

Subject: SBOM Request for [Product Name]

We request a Software Bill of Materials (SBOM) for [Product Name] 
version [X.Y.Z] currently deployed in our environment.

Requirements:
1. FORMAT: `CycloneDX` 1.7+ or `SPDX` 2.3+ in JSON format
2. CONTENT: All third-party and open source components, including:
   - Direct dependencies
   - Transitive dependencies
   - Component versions
   - License information
   - Package identifiers (`PURL` where possible)
3. SCOPE: All components in the deployed product, including 
   embedded libraries, containers, and supporting services
4. ONGOING: Updated SBOMs with each release and security update

This information supports our vulnerability management and 
compliance requirements. Please provide within [30 days] or 
indicate any challenges with this request.

SBOM interpretation for commercial software:

Vendor SBOMs often differ from internally-generated SBOMs:

Processing vendor SBOMs:

1. Ingest into vulnerability management: Import into Dependency-Track, GUAC, or similar platform
2. Correlate with vulnerability databases: Match components to CVE data
3. Track over time: Compare SBOMs across versions to see changes
4. Cross-reference with your SBOMs: Understand overlap with internal dependencies
5. Alert on critical components: Flag when known-risky components appear

Vulnerability Management for Vendor Software¶

When vulnerabilities affect commercial software, you depend on vendor response—but can take steps to manage risk in the meantime.

Vendor vulnerability coordination:

Monitoring for vulnerabilities:

When you discover a vulnerability before the vendor notifies you:

1. Verify the vulnerability applies: Check if the affected component/version is in your vendor's product
2. Assess exploitability: Is the vulnerable code reachable in the vendor's implementation?
3. Contact the vendor: Report what you've found and ask about their response
4. Document the timeline: Track when you notified vendor and their response
5. Implement compensating controls: If vendor response is delayed
6. Consider alternatives: If vendor is unresponsive to critical issues

Compensating controls while awaiting vendor patches:

Escalation for unresponsive vendors:

The Challenge of Appliances and Embedded Software¶

Appliances and embedded systems present unique supply chain challenges: limited visibility, difficult patching, and long lifecycles.

Appliance and embedded system challenges:

Examples of affected categories:

• Network appliances (firewalls, load balancers, switches)
• Security appliances (SIEM, DLP, endpoint protection)
• Industrial control systems (SCADA, PLCs)
• Medical devices
• IoT devices
• Specialized hardware (storage arrays, backup appliances)

Managing appliance risk:

1. Require SBOMs in procurement: Make it a purchasing criterion
2. Inventory appliances explicitly: Don't let them disappear from asset management
3. Subscribe to vendor security updates: Actively track vendor advisories
4. Test updates in non-production: Firmware updates can cause issues
5. Maintain patching cadence: Don't let appliances fall behind
6. Network segment appropriately: Limit blast radius of compromised appliances
7. Plan for replacement: Have exit strategy for critical appliances

Compensating for limited visibility:

When you cannot obtain SBOMs for appliances:

• Monitor network behavior for anomalies
• Apply strict network segmentation
• Monitor vendor security advisories diligently
• Consider third-party vulnerability intelligence specific to product
• Include in penetration testing scope
• Document risk acceptance

End-of-Life and Unsupported Software Considerations¶

All software eventually reaches end of life. Unsupported commercial software with open source components becomes a growing security liability.

EOL planning and migration:

Warning signs of impending EOL:

• Vendor announces end of support date
• Release frequency decreasing
• Vendor acquired or changing business model
• Newer version requires major migration
• Vendor stops responding to security issues
• Similar products being consolidated

EOL planning process:

1. Track EOL dates: Maintain calendar of vendor EOL announcements
2. Assess impact: What depends on this product? What replaces it?
3. Plan migration: Create timeline for replacement before EOL
4. Budget appropriately: Migrations require resources
5. Communicate internally: Stakeholders need to plan
6. Execute before EOL: Don't run unsupported in production

When migration isn't immediately possible:

Sometimes you're stuck with unsupported software:

Risk acceptance documentation:

When unsupported software must remain:

## Risk Acceptance: [System Name]

### System Information
- Product: [Vendor Product]
- Version: [Version]
- EOL Date: [Date]
- Planned migration date: [Date or N/A]

### Risk Assessment
- CVSS score of highest known unpatched vulnerability: [Score]
- New vulnerabilities expected: [Yes/No - if known components at risk]
- Data sensitivity: [Classification]
- Business criticality: [Critical/High/Medium/Low]

### Compensating Controls
- [ ] Network segmentation: [Details]
- [ ] Access restrictions: [Details]
- [ ] Enhanced monitoring: [Details]
- [ ] Regular vulnerability assessment: [Frequency]
- [ ] Incident response plan: [Link]

### Residual Risk
[Description of remaining risk after compensating controls]

### Approval
- Risk owner: [Name, Title]
- Approval date: [Date]
- Review date: [Date - should be frequent for unsupported software]
- Approver signature: _______________

### Conditions
This acceptance is valid only while compensating controls remain 
in place. Any significant change requires re-evaluation.

Regular review of unsupported software:

Recommendations¶

We recommend the following approach to managing commercial software with open source components:

1. Request SBOMs from all software vendors: Make SBOM provision a standard part of vendor relationships. The more visibility you have, the better you can manage risk.

2. Don't wait for vendor notifications: Use vendor SBOMs to proactively detect vulnerabilities through your own correlation. You may discover issues before vendors notify you.

3. Establish vendor vulnerability coordination processes: Know how to contact vendors about security issues, what response to expect, and how to escalate when needed.

4. Apply compensating controls for delayed patches: When vendor remediation takes time, implement network, access, and monitoring controls to reduce risk.

5. Pay special attention to appliances: Appliances and embedded systems often have the least visibility and longest patch cycles. Segment them, monitor them, and track vendor updates diligently.

6. Plan for EOL before it arrives: Unsupported software is a growing security liability. Track EOL dates and migrate before support ends.

7. Document risk acceptance formally: When unsupported or unpatched software must remain, document the decision, compensating controls, and regular review requirements with appropriate approval.

8. Build SBOM capability into contracts: Future procurement should include SBOM requirements (Section 25.2). Managing open source in commercial software becomes easier when vendors commit to transparency.

The open source components inside commercial software are part of your supply chain, even though you didn't choose them directly. Managing this risk requires partnership with vendors, visibility into their software composition, and contingency plans for when vendor response is inadequate.