Read an open source audit report in this order: scope first, then license findings sorted by how the product is shipped, then vulnerabilities sorted by exposure, then unknowns and upkeep. Most reports are long, and the useful part is usually a short list buried in a large table.
Step 1: check the scope
Before you read a single finding, find out what was scanned. Which repositories, which branches, which build outputs? A clean report on half the code is not a clean report. If the scope page is thin, ask for the list of inputs.
Step 2: sort license findings by distribution
A license finding means little without context. Ask three questions of each one:
- Is the component shipped to customers, or only run on your own servers?
- Is it linked into your code, or run as a separate program?
- Did you modify it?
A copyleft license in a build tool that never ships is a different situation from the same license in a downloadable app. See copyleft risk in acquisitions for the cases that tend to matter.
Step 3: sort vulnerabilities by exposure
A long vulnerability list is normal. Pull out the items that are reachable from your code, internet facing, or on a known exploited list. The rest can go into a scheduled backlog. Counting findings is less useful than ranking them.
Step 4: handle the unknowns
Reports often include a section for components with no detected license, or a license that does not match a known identifier. Treat each as unknown, not as safe. The usual causes are a missing LICENSE file, a custom text, or a metadata field left blank. See blank license fields.
Step 5: look at upkeep
A component can be clean today and still be a problem if nobody maintains it. Look for old releases, archived repositories and versions past end of life.
A quick triage table
| Finding type | Ask first | Likely next step |
|---|---|---|
| Copyleft license | Shipped? Linked? Modified? | Replace, isolate, or comply |
| No license detected | Where did it come from? | Find the source and record it |
| Known vulnerability | Reachable? Fix available? | Upgrade or accept with a note |
| Abandoned project | Is there a maintained alternative? | Plan a swap |
| Copied code | Is the origin known? | Document or rewrite |
Write down your decisions
For each item, record the decision, the owner and the date. A reviewer later should be able to see that a finding was seen and handled, not just that it existed. Reports without that trail tend to be re-asked in every later deal.
Safeguard offers SBOM and dependency scanning plus compliance and evidence automation, which can help you keep an inventory and supporting records current. A free scan shows the inventory side.
Quick check
Should I fix every finding before signing?
Usually not. Fix the ones that change the deal or the risk, and agree a dated plan for the rest.
What if the report and the seller disagree?
Ask for the file path and the evidence behind the finding. Many disputes are resolved by reading the actual license text in the source.
Last reviewed: 19 October 2026.
