Price an acquisition target's dependency debt into the deal

To price a target's open source risk, stop counting findings and start counting upgrade work. Sort every finding into a small set of cost classes (exploited and reachable, reachable, end of life, license conflict, accept), size each class in engineer weeks using the target's own delivery history, then hand corp dev a low, base and high range with every assumption written next to it. Findings that must be fixed before signing or closing become deal terms; the rest become a funded integration plan.

That is the whole method. The rest of this post is how to do it by Friday, with whatever scanner you already have, and what changes when you run it with Safeguard.

Key takeaways

• A vulnerability count is not a cost. One upgrade often closes dozens of findings, and one runtime migration can cost more than all of them. Estimate in upgrade units and migrations.
• Five cost classes cover almost every finding: known exploited and reachable, reachable, end of life, license conflict, and accept with monitoring. Each has its own owner, timing and deal lever.
• Effort per class should come from the target's own upgrade history, not an industry average.
• Some license findings change the deal itself, not just the plan. Counsel decides what a license finding means; this post is not legal advice.
• Present a range, not a point, so corp dev can use it in the price, a holdback, a pre-close covenant or the integration budget.
• Safeguard covers the evidence side: the local runner (GA) scans on the target's machine and uploads only the SBOM and findings, SBOM generation and SCA (GA) build the inventory, reachability analysis (GA) separates reachable from unreachable findings, license compliance (GA) flags conflicts and unknowns, and bulk export (GA) gets the data into the spreadsheet corp dev will actually read.
• Safeguard reports findings. It does not estimate effort, judge the team or the architecture, or give legal opinions. The cost model is yours.

The situation

Corp dev has a signed letter of intent, a data room, and a model with a line called "technology remediation" that somebody pencilled in. They want your number by Friday, because the price conversation with the seller is next week.

You run engineering or platform at the acquirer, a US fintech, and you will inherit this code. If the number is too low, your teams spend the integration year on unplanned upgrade work and the roadmap slips. If it is too high, or comes with no reasoning, corp dev uses the pencilled figure anyway.

A bad week: the target will not hand over source code, so you get a hand exported dependency spreadsheet. A scan of one sample repository produces 4,000 findings. Corp dev asks "so how much is that?" and nobody can say. Two weeks after close, someone notices the main hosted product embeds a network copyleft library that was never on the list.

A good week: the target scans on its own machines and shares the SBOM and findings. You sort them into five classes, size each class with the target's delivery data, and write a two page memo with a low, base and high number, the assumptions, and a short list of items to fix before closing or cover with a deal term.

The rules and standards behind it

None of these documents tells you what a target's dependency debt is worth. They tell you what good evidence looks like, what a buyer may and may not do before closing, and which signals deserve priority. That is the frame for a defensible estimate. Nothing here is legal, regulatory or audit advice; your deal counsel decides how these apply to your transaction.

What a complete SBOM should contain

CISA, NSA, FBI and international partners published the 2026 Minimum Elements for a Software Bill of Materials on 29 July 2026. It replaces the 2021 NTIA minimum elements. Three parts matter for diligence.

• Coverage. An SBOM should list all components, including transitive dependencies, with no minimum depth. A target SBOM that stops at direct dependencies will make your estimate too low.
• Component License is new. Identifiers should let the recipient find the full license, preferably as SPDX identifiers, and an unknown license should be marked unknown. Unknowns are a finding in their own right.
• SBOM Generation Context is new too: "before build" for an SBOM from source, "after build" for one from binary analysis. Ask which you are looking at; the two can differ for the same service.

The published PDF says the minimum elements do not create new requirements. They are a baseline you can ask a target to meet.

Mergers and acquisitions as a supply chain risk event

NIST SP 800-161 Revision 1 (published May 2022, with updates as of 1 November 2024) is the federal guide to cybersecurity supply chain risk management. In its guidance under SA-1, Policy and Procedures, it says supply chains evolve through mergers and acquisitions and that enterprise policy should help the organization understand those changes. In Appendix G, under the Monitor step, it lists "change of ownership, merger, or acquisition" as an example of a supply chain risk event that should trigger reassessment.

For an acquirer, buying a company is buying its supply chain, with every unpatched version, end of life runtime and license obligation in it.

What the buyer may not do before closing

If the transaction is reportable under the Hart-Scott-Rodino Act, the parties must file and wait before closing. In January 2025 the Federal Trade Commission announced a $5.6 million civil penalty against buyers that took operational control of parts of a target's business during the waiting period, which the FTC called the largest gun-jumping penalty in US history. The FTC's release puts it simply: "It is generally illegal to finalize an acquisition during this investigatory period."

The practical consequence: before closing, you do not run the target's engineering team. Anything fixed before closing is the target's own work, agreed as a covenant or condition, with counsel setting what information moves and who sees it (often through a clean team). Your estimate should say which items belong in that pre-close bucket.

Which findings deserve priority

• The CISA Known Exploited Vulnerabilities catalog is, in CISA's words, the authoritative source of vulnerabilities exploited in the wild, and CISA tells organizations to use it as an input to prioritization.
• FIRST's Exploit Prediction Scoring System estimates the probability that a published CVE will be exploited in the next 30 days, updated daily. Record the date you pulled it.

Severity alone overstates cost, because many high severity findings sit in code the application never calls. Reachability, KEV and EPSS together turn a raw list into a short list worth paying for.

End of life is a cost, not a finding

Runtimes and frameworks have published support windows. Python's version status page lists Python 3.10 as end of life on 1 October 2026, and Python 3.9 on 31 October 2025. The Node.js project's release page says production applications should only use Active LTS or Maintenance LTS releases. A service on an end of life runtime may show few findings today and still carry the largest single line in your estimate, because the fix is a migration, not a version bump.

License identifiers and license programs

The SPDX License List (version 3.29.0, dated 16 September 2026 when fetched) gives every common open source license a stable identifier, which is what lets you sort license findings by machine instead of reading NOTICE files. OpenChain ISO/IEC 5230 defines the key requirements of a quality open source license compliance program. If the target says it follows ISO/IEC 5230, ask for the evidence; a target with a working program usually carries less license surprise.

For network copyleft, read the license itself. Section 13 of the GNU Affero General Public License version 3 requires that a modified version offer users who interact with it over a network an opportunity to receive its Corresponding Source. That one clause is why AGPL components in hosted products get their own row in the memo.

What "our standard" means

Corp dev's question is "what will it cost to bring their code up to our standard?" Write your standard down before you estimate against it. The NIST Secure Software Development Framework, SP 800-218 is a common yardstick. Whatever you use, the gap between the target's practice and yours (SBOM per release, dependency gates in CI, a patch window by severity, a license policy) is a cost line in its own right, separate from the backlog.

What you can see during diligence without taking a copy of the code

Most targets will not hand source code to a prospective buyer before signing, and many will not after signing either until closing. That is reasonable. You can still see a lot.

The post on scanning an acquisition target's code without taking a copy covers the clean team and runner mechanics; SBOMs for M&A due diligence covers what an SBOM can show in a deal. The short version: the target scans on its own hardware and shares the output, and you never hold the source.

Ask for three things in one request, so you do not lose a week going back:

1. The SBOM and findings for every production service and every shipped product, not a sample, or an explicit list of what was left out and why.
2. A one line note per service: hosted or distributed, internet facing or internal, runtime and version, and whether it handles regulated data such as card or bank account data.
3. Twelve months of delivery data: deploys per service per month, the last three major dependency or runtime upgrades and how long each took, and the share of services with automated tests in CI.

Most diligence requests forget the third item, and it is the one your effort estimate depends on.

Step by step: from a scan to a number corp dev can use

This works with any scanner that produces an SBOM and matched findings. Plan two to three working days for a target with a few dozen repositories, once the target has run its scans.

1. Write your standard on one page: no KEV listed finding on a reachable production path, no end of life runtime, an SBOM per release, dependency gates in CI, a license allowlist. Each line is a gap you will price.
2. Collect the evidence pack and check coverage: transitive dependencies, licenses present or marked unknown, generation context stated. Missing coverage becomes a contingency line, not a zero.
3. Collapse findings into upgrade units. One component moved from one version to another in one service is one unit, however many findings it closes. This usually shrinks the list by an order of magnitude.
4. Classify each unit into the five cost classes below, using KEV, EPSS (with the date pulled), reachability and exposure.
5. List end of life runtimes and frameworks as one migration per service.
6. List license findings by category and delivery model (hosted, distributed, internal). Send strong copyleft, network copyleft and unknowns in shipped or hosted products to counsel.
7. Size each class in engineer weeks from the target's delivery data, with a low and high per unit.
8. Add the standard gap (pipeline and process work, priced per pipeline type) and a contingency for repositories, vendored code and apps you could not see.
9. Map each class to a deal lever and timing, then write the memo.

A same-day intake checklist

Copy this into your diligence tracker.

How to classify findings into cost classes

Cost classes are not severity bands. A class groups work that has the same owner, the same timing and the same kind of deal lever. Five is enough.

Five rules make the classes hold up under questions.

Unknown reachability goes up, not down. If the analyzer cannot decide (reflection, dynamic dispatch, native code), price the finding as reachable.

KEV beats EPSS. On KEV, exploitation is observed, not predicted. EPSS sorts class 2 and supports accepting class 5, but never moves a KEV finding down.

Exposure moves a unit one class at most. A reachable high finding in an internet facing payment service stays class 2 even with low EPSS; the same finding, unreachable, in an internal batch tool can be class 5.

End of life absorbs what is inside it. Library upgrades inside a service that must leave an end of life runtime usually happen during the migration. Price them once, in class 3.

Licenses are classified by delivery. Strong copyleft in an internal script is rarely a deal issue; the same library linked into a shipped SDK may be.

How to estimate effort per class with the target's numbers

Everything below is an illustrative worked example with round invented numbers. Redo it with the target's data and your own team's experience.

The illustrative target

A payments software company with 40 repositories, 18 production services (12 hosted, 2 distributed SDKs, 4 internal tools), and an engineering team of about 60. The scan returns 3,600 vulnerability findings and 2,900 distinct components.

After collapsing findings into upgrade units and classifying them:

Notice the shape. Almost all of the 3,600 findings sit in class 5, the cheapest class per unit. The money is in classes 3 and 4, which barely register in the finding count.

Per unit effort, from the target's history

Ask the target for its last three major upgrades. Suppose (illustrative) they report:

• A framework major version upgrade in one service took 5 weeks for two engineers, about 10 engineer weeks.
• A runtime upgrade in one service took 3 weeks for one engineer, about 3 engineer weeks, but that service had good test coverage.
• Routine patch and minor upgrades are batched weekly and take about half a day each including review and deploy.

From that, and from your own team's experience, set low and high per unit effort:

For class 1 and class 2, assume a mix: in this example, say three quarters of upgrade units are patch or minor, one quarter are major.

The arithmetic

Class 1: 8 units. 6 patch or minor (0.1 to 0.4 each) and 2 major (1 to 4 each). Low 0.6 + 2 = 2.6 engineer weeks. High 2.4 + 8 = 10.4 engineer weeks. This is the target's work before closing, so it appears in the memo as a covenant, not as your cost. Price the residual risk only if the covenant is not agreed.

Class 2: 60 units. 45 patch or minor and 15 major. Low 4.5 + 15 = 19.5. High 18 + 60 = 78 engineer weeks.

Class 3: 3 Python runtime migrations, 2 Node.js migrations, 1 framework migration. Low 5 x 3 + 6 = 21. High 5 x 10 + 14 = 64 engineer weeks. Then remove the class 2 units that sit inside these six services, since the migration absorbs them. Suppose 12 of the 60 class 2 units are inside these services: take 12 units' worth (about 4 low, 16 high) back out of class 2.

Class 4: 2 replacements at 2 to 12 each, plus 35 identifications at 0.05 to 0.2 each. Low 4 + 1.75 = about 5.75. High 24 + 7 = 31 engineer weeks. Counsel's time is extra and is not in this number.

Class 5: 240 routine units at 0.1 to 0.4. Low 24, high 96. Most of this is absorbed by the normal upgrade cadence your teams already run. Count only the share above your normal cadence, for example a quarter of it: low 6, high 24.

Standard gap: dependency gates and SBOM per release for 3 pipeline types (two hosted stacks and one SDK build), 2 to 5 engineer weeks each. Low 6, high 15.

Contingency for unseen coverage: the target excluded 4 repositories and both mobile apps. Add 15 percent of the visible total for the low case and 35 percent for the high case.

Putting it together

The base case is not the midpoint. Pick it by judgment: if the target's tests are thin and its past upgrades ran long, set the base closer to the high end. In this example, with the target's own 10 week framework upgrade as evidence that big changes are slow, a base of about 140 engineer weeks is defensible.

Multiply by your loaded cost per engineer week to get a currency figure. Use your finance team's number, not a guess. Then add any counsel and third party costs for class 4.

Two more numbers belong next to the total, because corp dev will ask:

• Calendar time. 140 engineer weeks with 6 dedicated engineers is roughly 23 to 24 calendar weeks, before interruptions. The target's roadmap will not continue at full speed meanwhile.
• Cost of delay. If class 3 slips past the integration year, more of the stack falls out of support. Put each support end date next to its line.

Which license issues change the deal, not just the plan

Most license findings are housekeeping: missing attribution, a stale NOTICE file, a permissive license the SBOM missed. They go in the integration plan. A few change the deal. Send these to counsel the same day, with component, version, service and delivery model attached. Counsel decides what each means; engineering supplies the facts.

1. Network copyleft in a hosted product. AGPL section 13 is the usual case: a modified AGPL component in a service users reach over a network must offer those users its corresponding source. Whether the target modified it, and how it is combined with proprietary code, are facts counsel needs.
2. Strong copyleft in a distributed product. A GPL component linked into an SDK, mobile app or on-premises product raises distribution obligations. The fix may be a replacement, a relicense or a different architecture, each with a cost.
3. Unknown licenses in shipped code. CISA's 2026 minimum elements ask SBOM authors to mark unknown licenses as unknown. A large unknown bucket means you cannot rule out the first two cases, which argues for a holdback or a condition to finish identification.
4. Commercial components. Whether a commercial license survives a change of control is a contract question, but the SBOM is how you find the components.
5. No license program. Without a policy, the risk is every future release, not one component. That supports a broader representation and a standard gap line.

These usually surface in the deal as an open source representation, a special indemnity for named components, a holdback until replacements ship, or a closing condition. Which lever fits is counsel's and corp dev's call; your job is to make the finding precise enough to choose.

How to present a range and its assumptions to corp dev

Corp dev does not need your spreadsheet. They need a page they can use in a model and defend in front of a deal committee. Keep it to two pages.

A memo template

Subject: Open source and dependency remediation estimate, target name, date

Bottom line. Remediation to our standard is estimated at low X, base Y, high Z engineer weeks (currency figure at our loaded rate), over N months of calendar time with M engineers. Separately, K items should be fixed by the target before closing, and L license items need counsel's review before signing.

What we looked at. Number of services scanned out of total, SBOM generation context, scan date, KEV and EPSS pull date. What was excluded and why.

How we estimated. Findings collapsed into upgrade units and migrations, sorted into five classes, sized per unit with the target's own upgrade history (cite the three examples), plus a standard gap line and a contingency for unseen coverage.

The range. The table from the worked example, with one line per class.

Assumptions that move the number most.

• Per unit effort for runtime and framework migrations (the biggest swing).
• The share of class 5 work above our normal upgrade cadence.
• Contingency for repositories and apps we could not see.
• Whether class 1 is fixed by the target before closing.

Deal levers, by class. Class 1: covenant to fix before close, proven by rescan. Class 2: integration budget. Class 3: price or integration budget. Class 4: counsel to advise before signing. Class 5: none.

What would change the number. A rescan after the target's fixes, the excluded repositories, or counsel's view on license items.

Not covered. Architecture, code quality, team capacity and retention, business logic defects, cloud configuration, and anything that is not a dependency.

How to talk about the range

Name the biggest assumption first ("most of the spread is six migrations"). Separate cost from risk: class 1 should never become your cost, and class 4 may be a legal exposure bigger than its engineering cost. Then offer the update path: "if the target fixes class 1 and shares the four missing repositories before signing, the range narrows." That gives corp dev something to ask the seller for.

What goes into the first 100 days of integration

The plan should have the same shape as the estimate. The post on inherited vulnerabilities after an acquisition covers exceptions for what you cannot fix straight away.

Days 1 to 30: baseline.

1. Bring every target repository into your scanning and SBOM process and rescan. Anything new since diligence goes into a variance log for corp dev.
2. Confirm class 1 is closed by rescan, not by ticket status.
3. Turn on dependency gates in CI in warning mode first, so engineers see what will be enforced before it blocks them.
4. Name an owner for each class 3 migration and each class 4 component.

Days 31 to 60: reachable work and license decisions. 5. Burn down class 2, starting with internet facing services that handle regulated data. 6. Act on counsel's decisions for class 4: start replacements, publish attributions, or complete identification of unknowns. 7. Start the first end of life migration, ideally the one with the earliest support end date.

Days 61 to 100: enforce and report. 8. Move gates from warning to blocking for known exploited, reachable findings in production services. 9. Bring every target release under your SBOM per release practice. 10. Report estimate versus actual per class to corp dev. If class 3 runs at the high case, say so at day 100, not month nine.

How Safeguard does this

Everything above works with any scanner. This is the same flow in Safeguard, built from Safeguard's docs and offering. Every capability named here is generally available (GA). The cost model and the deal levers remain yours.

1. The target installs the CLI and starts the local runner (GA) on its own machine. Safeguard's runner docs describe the runner as part of the safeguard CLI, not a separate product. Install with the documented one line installer:

   # macOS and Linux
   curl -fsSL https://cli.safeguard.sh/install | bash
   

   Then run safeguard, type /login, approve the session in the browser, and the runner starts polling for work. Per the docs, all traffic is outbound HTTPS that the runner opens, and it uploads only the resulting SBOM and findings, never the source code.

2. The target scans each repository. Two documented options exist, and the choice matters for who sees what.

   • From the interactive terminal while signed in, /scan . scans the current directory and the runner uploads the SBOM and findings to the platform, so they appear alongside other projects.
   • From the command line, the CLI usage docs show safeguard scan --dir ., which builds an SBOM, matches it against vulnerability databases, and writes results as JSON files under ./output. Results include vuln.json, license.json and collection.json. The target can then choose what to share.

   # A local directory, results written under ./output
   safeguard scan --dir .
   

   Two flags from the same page are worth agreeing with the target in advance: --org-namespace marks the target's own private package namespaces, and --resolve-transitive resolves transitive dependencies through a public dependency service, so decide together whether that lookup is acceptable under your clean team rules. The docs also say safeguard scan exits 0 when the scan ran, whatever it found, and 2 when results were written but the vulnerability scan did not actually run. Ask for exit codes with the results so a failed scan is never read as a clean one. We did not run these commands for this post; check safeguard scan --help in the build you have.

3. SBOM generation and SCA (GA) build the inventory. The offering lists SPDX and CycloneDX output and full transitive inventory across the major package ecosystems and container layers. If the target already has SBOMs from its own tooling, the docs show safeguard scan --sbom sbom.json to scan an existing SPDX or CycloneDX file, and safeguard validate sbom.json to check it against its specification before you rely on it. The Generate SBOM docs list an option to include dev dependencies; agree whether to include them, since dev only findings rarely cost the same as production ones.

4. Vulnerability management with KEV and EPSS (GA) and reachability analysis (GA) do the sorting. The reachability docs describe four classes, Reachable, Conditionally reachable, Unreachable and Unknown, with Unknown marked conservatively as potentially reachable, which matches the class rules above. The Vulnerabilities tab has Priority and Reachability columns and filters such as reachable:true and kev:true, so class 1 is close to a single filter. Two limits from the same page matter in diligence: dynamic reachability depends on a runtime collector in production workloads, which you will not have before closing, and analysis quality varies by language. The page also notes there is no CLI command for querying findings by priority yet, and its /v1 API examples are not available today, so use the app.

5. License compliance (GA) produces the class 4 list. The Suppliers and Licenses docs show a per project tab with license categories (permissive, weak copyleft, strong copyleft, commercial, public domain), a compliance status (Compliant, Review Needed, Violation, Unknown), and common issues such as GPL in proprietary code and AGPL network use. Policies (allowlist, blocklist, review list) live under Settings, License Policies. Export, License Report gives a summary, detailed, attribution or compliance report to hand counsel, with your note on each service's delivery model.

6. Bulk export (GA) gets the data into corp dev's spreadsheet. Export in formats including CSV, Excel, PDF and JSON, with filtering and column selection, then build the cost model next to the filtered views. The model and the range are your work.

7. Ask questions in plain English while you sort. In-app agentic search (GA) lets you ask Griffin, the assistant, about the prioritized findings, for example which reachable findings sit in production. The Safeguard MCP server (GA) lets Claude query the same data, with you choosing which tools it may use.

8. After closing, the same project becomes the 100 day plan. Policies, gates and guardrails (GA) enforce your standard in CI with gate actions Block, Warn and Notify, and approvals through exceptions; start with Warn, move to Block by day 100. Autonomous remediation (GA) can open upgrade pull requests for class 2 and class 5 work; it ships switched off, with every category set to Manual.

What Safeguard does not do

What Safeguard does not estimate

• Effort and cost. Safeguard reports findings, reachability, licenses and inventory. It does not estimate engineer weeks, migration difficulty or a currency figure. The cost classes, per unit effort and range in this post are your model.
• Team quality, capacity and retention. Nothing in a scan tells you whether the target's engineers will stay after closing, or how fast they work.
• Architecture and code quality as a deal question. A scan does not tell you whether a service needs a rewrite, whether the data model will survive integration, or how coupled a component is to the rest of the code.
• Business logic defects. Authorization mistakes, broken payment flows and similar defects in the target's own code are not dependency findings.

Other limits

• Legal opinions. License findings are not legal advice. Safeguard flags categories and conflicts; counsel decides what they mean for the deal.
• What the runner cannot see. The scan sees what the target points it at. Repositories the target leaves out, vendored code copied without package metadata, and products the target does not scan are not in the results. Your contingency line exists for this.
• Pre-close runtime evidence. Dynamic reachability needs a runtime collector in production. Before closing you will usually have static reachability only, and Unknown findings stay conservative.
• Pre-close control. Safeguard does not change what the buyer may do before closing. Who runs the scan, who sees the output and what gets fixed before closing are set by counsel and the purchase agreement.
• Certification of the target. A scan is evidence, not an attestation that the target meets any standard.

Common mistakes

• Pricing the finding count. "4,000 vulnerabilities" times a per finding cost is meaningless. Collapse to upgrade units and migrations first.
• Estimating on a sample. Two repositories out of forty is not a basis. Price the unseen part as contingency and say so.
• Ignoring end of life because the finding count is low. It can still be the most expensive line in the memo.
• Treating unknown as safe. Unknown reachability and unknown licenses both go up a class.
• Folding legal exposure into engineering cost. Keep license lines separate and send them to counsel.
• Directing pre-close fixes yourself. Before closing, fixes are the target's work under the purchase agreement; directing its team can raise the control issues in the FTC's gun-jumping case.
• Giving a single number. A point estimate hides the assumptions corp dev needs to negotiate.
• Forgetting the standard gap. A zero backlog is not your standard. Gates, SBOM per release and a license policy are separate work.

FAQ

How do I estimate the cost to fix an acquisition target's open source risk?

Collapse findings into upgrade units and migrations, sort them into five cost classes (known exploited and reachable, reachable, end of life, license conflict, accept), size each class in engineer weeks using the target's own upgrade history, add a standard gap line and a contingency for what you could not see, and present a low, base and high range with the assumptions.

Can we scan a target's code without getting a copy of it?

Yes. The target runs the scan on its own machines and shares the SBOM and findings. With Safeguard's local runner the scan runs on the target's machine and only the SBOM and findings are uploaded, never the source code. Counsel sets who on your side may see the results.

Should known exploited vulnerabilities be fixed before closing?

Usually that is the cleanest outcome: the target fixes them under a covenant in the purchase agreement and proves it with a rescan. Whether to make it a covenant, a condition or a price adjustment is a decision for corp dev and counsel.

How do end of life runtimes affect the price?

They are often the largest single line, because each one is a migration per service, not a version bump. Use the published end of life dates (for example Python 3.10 reached end of life on 1 October 2026) and the target's own history with past migrations to size them.

Which open source licenses are deal issues?

Usually network copyleft such as AGPL in a hosted product, strong copyleft such as GPL in a distributed product, unknown licenses in shipped code, and commercial components whose licenses may not survive a change of control. Counsel decides; engineering supplies the component, version, service and delivery model.

Does reachability analysis reduce the estimate?

It moves findings between classes. Unreachable findings drop to the accept class, which is cheap. Unknown findings stay high. Do not apply a blanket reduction figure; use the reachability class of each finding in your data.

What should the first 100 days after closing include?

Rescan and baseline, confirm known exploited findings are closed, turn on dependency gates in warning mode, burn down reachable findings, act on counsel's license decisions, start the earliest end of life migration, then move gates to blocking and report estimate versus actual to corp dev.

Does the HSR waiting period limit technical diligence?

It limits control, not diligence as such. During the waiting period the buyer may not take operational control of the target. Counsel will set rules for what information moves and who sees it, often through a clean team. Plan your requests inside those rules.

From findings to fixes

The estimate turns into engineering work on day one, and most of that work is upgrading open source components to fixed versions. The remediation options below are what your teams can use to close the reachable and accept classes faster once the code is yours.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

This first demo shows the local runner: you set up the runner on your own machine, approve it with its device code, then scan from the terminal. In a deal, the target's engineer is the one who runs it, on the target's hardware, so you receive the SBOM and findings without ever holding the code.

Click through it at your own pace, or open it full screen.

The second demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. Once the target's findings are in a project, this is a quick way for your diligence team to ask questions of the data while building the cost classes, with the tool list kept narrow.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• CISA: 2026 Minimum Elements for a Software Bill of Materials (resource page)
• CISA: 2026 Minimum Elements for a Software Bill of Materials (PDF)
• NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices
• NIST SP 800-161 Rev. 1 Update 1 (PDF)
• NIST SP 800-218, Secure Software Development Framework Version 1.1
• FTC: Oil companies to pay record FTC gun-jumping fine
• CISA Known Exploited Vulnerabilities Catalog
• FIRST: Exploit Prediction Scoring System (EPSS)
• SPDX License List
• SPDX: GNU Affero General Public License v3.0 only
• OpenChain ISO/IEC 5230, License Compliance
• Python Developer's Guide: Status of Python versions
• Node.js: Previous releases and end of life
• Safeguard docs: Local Runner
• Safeguard docs: CLI Usage
• Safeguard docs: Generate SBOM
• Safeguard docs: Suppliers and Licenses
• Safeguard docs: Vulnerability Prioritization (Reachability Analysis)

Related reading: scan an acquisition target's code without taking a copy, SBOMs for M&A due diligence, get open source risk ready for pre-IPO diligence and an exception plan for inherited vulnerabilities after an acquisition.

To try the runner on your own code first, download Safeguard and read the docs.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.