A bring-down is a second look at the statements you made during diligence, done close to signing or closing, to confirm they are still true. For supply chain security that means a fresh SBOM, a fresh vulnerability scan, and an updated list of anything that changed since the data room opened.
Why answers go stale
Diligence often runs for weeks. In that time your team ships releases, adds packages, and new advisories land for components you already use. An answer that was accurate on day one, such as "no known critical findings in production dependencies", can be wrong by day thirty without anyone doing anything careless.
Deal documents commonly ask the seller to confirm that statements remain accurate at a later date. The exact wording is a legal matter, so ask your counsel. The engineering job is simpler: be able to show what was true on each date.
What to refresh
| Item | Why it moves | How to refresh |
|---|---|---|
| SBOM for each shipped product | New releases change the component list | Regenerate from the tagged release, store with date |
| Vulnerability findings | New advisories appear daily | Rescan the stored SBOM, not just the repo |
| Exceptions and accepted risks | Reviews expire | Re-approve or close each one |
| Access lists | People join and leave | Export current owners and admins |
| Incident log | Something may have happened | Add anything new, even if small |
Steps
- Write down the date of the original evidence and the date of the bring-down request.
- Regenerate the SBOM from the current production release and keep the old one for comparison.
- Diff the two. Every added or removed component should have a reason you can state in one sentence.
- Rescan both against current advisory data. A component that was clean in the first SBOM may carry a new finding.
- Compare against your known issues list and update status, owner and next date.
- Send the buyer a short change note, not a new data room. "Since 3 October: two releases, 14 package updates, one new advisory on a dev dependency, fixed in release 5.2.1" is the right size.
Handling bad news
Findings that appear between signing and close are normal. The mistake is silence. Tell the other side early, show the severity, say whether the vulnerable code is reachable in your product, and give a fix date you control. Buyers tend to react worse to a surprise than to a finding with a plan.
If a component is present but not exploitable in your product, record that in a VEX statement with a stated reason, so the claim can be checked later rather than taken on trust.
What not to do
Do not edit old evidence to match new facts. Keep the original, add a dated update beside it. Do not reuse an old SBOM because "nothing big changed", since you cannot know that without diffing. And do not promise a clean scan at close. Promise a current one, with known items listed.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a stored inventory is checked again when new advisory data arrives. That is the mechanism behind a cheap bring-down.
Safeguard can generate SBOMs, scan dependencies, apply reachability analysis and keep dated compliance evidence, which covers the refresh steps above. You can try a free scan on a repository first.
Quick check
Is a bring-down a legal requirement?
That depends on the deal documents. Ask counsel. As an engineering practice it is good hygiene whether or not a contract asks for it.
How fresh should the SBOM be at close?
Generated from the release that is in production at the time you give it, with the date on it.
Do I need to tell the buyer about every new low severity finding?
Keep them in the dated update. Summarise by severity so the buyer can see nothing is hidden.
Last reviewed: 19 October 2026.
