Regulated teams should look for software composition analysis that produces an exportable inventory of what you ship, runs where your data rules allow, keeps an audit trail, and prioritizes findings with evidence you can defend. A tool that only lists CVEs is not enough when an examiner asks how you decided what to fix.
Why do regulated buyers need more than a CVE list?
Regulators ask process questions. Under DORA Article 8, financial entities must identify and document their ICT assets and keep inventories updated after major changes. Article 28 asks for a register of third-party arrangements. In the US, NIST's Secure Software Development Framework, SP 800-218, is a core set of secure development practices that buyers use to question suppliers, and the 2021 NTIA minimum SBOM elements set a baseline for what a bill of materials contains.
None of these documents tell you to buy SCA. They give you questions your SCA output should help you answer: what components are in this release, who supplied them, and what did you do about the known problems.
What are the buyer criteria?
Use this as a scoring table. The right column is a test you can run in a trial.
| Criterion | Why it matters | Trial test |
|---|---|---|
| Inventory depth | Transitive dependencies hide most risk | Compare output on one repo you know well, by hand |
| SBOM export | Auditors and customers ask for SPDX or CycloneDX | Export one, validate it with a separate validator |
| Where code is analyzed | Source residency rules | Ask which data leaves your network |
| Deployment options | SaaS may be barred | Confirm on-prem or air-gapped support in writing |
| Advisory sources | Single feeds miss things | Ask which databases it reads and how fast it updates |
| Prioritization | Raw counts bury real issues | Ask what evidence backs a "not reachable" label |
| Audit trail | Examiners ask who accepted a risk | Check that exceptions record who, when and why |
| License findings | Legal exposure | Ask how it resolves conflicting license signals |
How should you probe the hard ones?
Where code is analyzed. Some tools upload source, others upload only results. Safeguard's CLI scans on your machine and sends the SBOM and findings, not the source, and the runner mode follows the same pattern. Whatever tool you test, trace what leaves the network with your own packet capture or firewall logs.
Prioritization. Reachability analysis tells you whether your code calls the vulnerable function. It is helpful and it has limits: dynamic dispatch, reflection and native code can defeat static analysis, and a good tool marks those as unknown instead of safe. Ask for that behavior by name.
SBOM quality. An SBOM from a scanner reflects what the scanner could see. It will not list a library vendored into a file as a copy-paste, or firmware outside the package manager. State this limit in your own evidence pack so nobody reads the SBOM as complete beyond its method.
What are the honest limits of any SCA tool?
It finds known issues in components it can identify. It does not find a flaw in your own logic, a misconfiguration, or a zero-day nobody has published. It also depends on advisory data quality, which varies by ecosystem. SCA is one control in a program, next to code review, testing and runtime monitoring.
What to do
- List the three regulator or customer questions SCA output must answer for you.
- Write your data residency rule in one sentence and test every vendor against it.
- Run two vendors on the same repo and diff the component lists.
- Export an SBOM and validate it independently before you trust the format.
- Ask for the prioritization logic in writing, including how unknowns are treated.
- Check that exceptions and approvals are logged with names and dates.
- Add the tool's limits to your risk register.
See an example inventory and finding view in the demo.
Quick check
Do regulations require SCA?
Not by name in the texts we reviewed. DORA, for example, requires asset inventories and third-party registers, and SCA output can support those.
Is a clean scan proof of safe software?
No. It means no known issue was found in the components the tool could identify.
Sources
- NIST SP 800-218, Secure Software Development Framework
- NTIA: The Minimum Elements for a Software Bill of Materials
- CISA: 2025 Minimum Elements for an SBOM (draft for comment)
- Regulation (EU) 2022/2554 (DORA), Articles 8 and 28
- Safeguard CLI
- Safeguard docs: SCA
Last reviewed: 18 October 2026.
