How do you explain software composition analysis to your CFO?

Software composition analysis, or SCA, is a list of every open source ingredient inside your software, checked against known problems. To a CFO: it is the label on the food your company sells. It tells you what is inside, which parts are recalled and who must fix them before customers or auditors ask.

This is a script for a budget conversation. It uses plain language, three money framed questions and an honest section on what SCA does not do, because a CFO who hears only upside will trust you less.

What is it, in one minute?

Your engineers build products on top of open source libraries, often hundreds per product, and those libraries depend on others. CISA describes a software bill of materials as "a list of ingredients that make up software components." SCA builds that list from your code and matches each ingredient against public vulnerability data. Safeguard's SCA docs describe resolving the complete dependency graph from manifests and lockfiles, including nested transitive dependencies, and matching versions against advisories enriched with EPSS and CISA KEV data.

The food analogy holds up. You cannot recall what you cannot list.

What are the three questions a CFO cares about?

1. What does it cost us if we do not know? We will not give you a number, because we do not have a sourced one for your company. Frame it as exposure categories instead: customer security questionnaires you cannot answer, deals stalled on an SBOM request, emergency engineering time when a major library flaw hits, and audit evidence you have to assemble by hand.

2. What do we get for the spend? A current inventory, a ranked list of what to fix first, and a record of fixes. If the tool offers reachability analysis, it can lower the pile of alerts by flagging vulnerable code that your product never calls. Ask any vendor for evidence from your own code, not an aggregate claim.

3. What does it cost to run? The license is one part. The larger part is engineer time to triage and fix. A tool that produces ten thousand unranked alerts costs more than the invoice says. Ask how findings are prioritized and how many a typical team must handle per week.

What are the honest limits?

• SCA covers open source components. It does not review your own code logic, your cloud setup or your people.
• A known vulnerability list is only as complete as public data. NIST has said its NVD enrichment backlog is growing, so scores can lag.
• Reachability analysis reduces noise but is not perfect. Safeguard's docs say reflection and dynamic dispatch produce "unknown" results that are not suppressed.
• A scan finds problems. Money is spent on fixing them.
• It does not make you compliant with anything by itself. It produces evidence for controls.

How should you compare options?

Without naming products, use criteria:

• Does it cover the languages and package managers you use?
• Does it resolve transitive dependencies, not just direct ones?
• Can it rank by exploitation evidence and reachability?
• Does it run in CI and block on policy?
• Can it export an SBOM in a standard format for customers?
• How are license risks handled?
• What is the pricing basis, and what happens when you add repositories?

What to do

1. Count products and repositories in scope and list the languages.
2. List the last three customer or audit requests that needed a dependency list, and how long each took.
3. Ask engineering how many hours the last major library flaw cost.
4. Run a trial on one product and bring back the number of findings, the number that needed action and the hours to fix.
5. Present the trial result, the limits above and one clear policy: what blocks a release.
6. Review after a quarter against the same three numbers.

Quick check

Sources

• CISA: Software Bill of Materials
• Safeguard SCA docs
• Safeguard Reachability Analysis docs
• NIST NVD program page

Last reviewed: 18 October 2026.