The findings that worry acquirers are not the count of vulnerabilities. They are signs of weak process: secrets in the repository, unmaintained dependencies, no code review trail, unpinned builds and components nobody can explain. Fix these before a scan and the rest looks manageable.
Secrets in history
A credential committed once stays in git history after deletion. Buyers scan the whole history. Rotate anything found, then remove it, and note the date. Rotation matters more than cleanup because the secret may already be copied.
Unmaintained dependencies
A package with no release for years and no maintainer response is a long term cost. List such packages yourself and say what the plan is: replace, fork or accept.
No review trail
OpenSSF Scorecard checks things like whether code is reviewed before merging, whether branch protection is on, and whether workflow tokens are read only. Buyers use similar signals. A repository where every change lands directly on the main branch suggests no control over what ships.
Unpinned builds
If dependencies float to whatever is newest, two builds a week apart can differ. Scorecard includes a check for pinned dependencies. Lock files and pinned build actions fix this cheaply.
Known exploited vulnerabilities
CISA's Known Exploited Vulnerabilities catalog lists flaws seen exploited in the wild, and CISA advises weighing them when deciding what to patch first. An open entry from that list in shipped code gets attention fast. Patch those before anything else.
Unknown components
Vendored code with no origin, binaries checked into the repository and packages nobody recognises all invite questions. Document the origin of each or remove it.
A one day pre-sale sweep
- Run a secrets scan over full history.
- Generate an SBOM and review the oldest components.
- Check branch protection on every repository.
- Cross check findings against the KEV catalog.
- Write down every known gap with an owner.
Safeguard offers dependency scanning with reachability analysis, so buyers and sellers can see which findings sit on code paths that run. A free scan is at https://gold.safeguard.sh/scan.
Triage like a buyer
When a buyer's scan lands, they sort findings quickly. Secrets and known exploited vulnerabilities come first. Next are copyleft hits in shipped code and unsupported runtimes. Ordinary medium severity library issues come last, unless many share one root cause.
Prepare a short reply per top item before the scan arrives. For a secret, state when it was rotated and what it protected. For an exploited vulnerability, state whether the vulnerable code path is used and when the fix ships. For a dependency, state whether it is shipped or test only.
This turns a scan from an accusation into a conversation. It also shows that your team triages the same way the buyer does.
Quick check
Is deleting a leaked secret enough?
No. Rotate it, because history and clones may still contain it.
Sources
Last reviewed: 19 October 2026.
