How to Scan an Acquisition Target's Code Without Taking a Copy

You can assess an acquisition target's code without ever holding it: the target runs a software composition scan on its own machine, inside its own network, and shares only the outputs. Those outputs are a component inventory (an SBOM), a license summary and a vulnerability list, passed through a clean team or an outside adviser under the deal's confidentiality terms. The source code stays with the people who own it until the deal closes.

That covers most of what an acquirer needs to price open source risk, though not architecture or code quality. This guide walks through what the acquirer can learn without the code, how to set up the exchange so it survives scrutiny from both sides' counsel, how to compare several targets on equal terms, and which findings belong in the price versus the post-close plan. It ends with how Safeguard does the target-side scan today, with the maturity label for every capability.

Nothing here is legal advice. Information exchange between merger parties is a legal question, and your antitrust and M&A counsel decide what can be shared, with whom and when.

Key takeaways

• Ask for results, not repositories. An SBOM, a license summary and a vulnerability list answer the open source questions in technical diligence without moving source code across the company line.
• Run the scan where the code lives. The target runs the scanner on its own hardware. The acquirer receives files the target has seen first.
• Route results through a clean team or outside adviser. The FTC's Bureau of Competition recommends clean teams and third party consultants when sensitive data has to be exchanged before closing, and warns that the duty to stay independent lasts until the deal closes.
• Fix the method before you compare targets. Same scanner version, same vulnerability database date, same scope rules, same output format. Otherwise you are comparing tools, not companies.
• Separate price findings from plan findings. Known exploited vulnerabilities in shipped products and copyleft obligations in distributed or hosted code move price and terms. Ordinary dependency drift becomes a post-close plan.
• Safeguard labels for this job: the Safeguard CLI and its built-in local runner (GA), SBOM generation (GA), license compliance (GA), vulnerability management with CISA KEV and EPSS (GA), bulk export (GA), Zero AI mode (GA), on-prem and air-gapped deployment (GA), third party risk management (GA), reachability analysis (GA), autonomous remediation (GA, ships switched off with every category set to Manual), and fork and patch (GA). The desktop app and mobile app are generally available.

Why targets refuse to hand over source code

Ask a target's CTO for a copy of the repositories before signing and you will usually get a polite no. That refusal is reasonable, and an acquirer who understands why gets a better result than one who pushes.

The source is often the asset being bought

For a software company, the code is much of what the buyer is paying for. Handing it to a bidder who might walk away, or who competes, gives away the asset before the price is agreed. A non-disclosure agreement helps, but a codebase cannot be un-read.

Many deals do not close

If the target hands full source to three bidders and one signs, two other companies now hold copies of its code. Destruction clauses help, but the target still has to trust that every copy on every laptop and backup was deleted.

Pre-close information exchange has legal limits

When buyer and target compete, or might compete, information flowing between them before closing is an antitrust question, not just a confidentiality one. In a March 2018 post on the FTC's Competition Matters blog, three staff members of the FTC Bureau of Competition set out the risks plainly. Sharing competitively sensitive information such as future pricing, strategic plans and costs can harm competition, the risk lasts until the deal closes, and it matters even if the deal never happens. The same post notes that information sharing can contribute to a violation of the Hart-Scott-Rodino (HSR) Act if it lets the buyer effectively control the seller before closing, and that coordinating business activity during the HSR waiting period can support a claim under Section 1 of the Sherman Act.

The FTC has acted on this. In January 2025 it announced what it called a record civil penalty for gun jumping, a 5.6 million dollar settlement with three oil companies. The FTC alleged the buyer side took operational and decision-making control over significant parts of the target's day to day business before the deal closed, for 94 days, including coordinating customer contracts and prices. That case was about control of operations, not a code review, but it shows the agencies watch what happens between signing and closing.

Source code is not on the FTC post's list of examples, which centres on pricing, costs and strategy. But code can carry strategy: an unreleased product, a pricing engine, a roadmap expressed as feature flags, integrations that reveal which customers matter. Whether any of that is competitively sensitive in your deal is for counsel to decide. A results-only exchange gives counsel far less to worry about.

The FTC's process for when data has to be shared

The FTC post describes safeguards on both sides of the exchange. For the party disclosing information: share only what diligence requires, mask customer identities and aggregate data where possible, review everything that goes into the data room for indirect disclosures, stop downloading and emailing of confidential data, and enforce destruction at the end of the process. For the receiving party: make sure employees understand the confidentiality and clean team agreements, keep sensitive data off shared drives, and give business people only blinded, aggregated reports that counsel has reviewed.

Read that list again with a code scan in mind. "Share only what diligence requires" is the case for an SBOM and findings instead of a repository. "Aggregate where possible" is the case for a summary table instead of raw findings. "Review data room additions for indirect disclosure" is the case for the target reading its own results before they leave.

What an acquirer can learn without the code

A component scan reads manifests, lockfiles, container layers and license files, then matches what it finds against vulnerability and license data. The output answers a specific set of diligence questions well.

Inventory: what the product is made of

An SBOM lists every open source and third party component the scanner found, with versions and, where the format carries it, the dependency relationships between them. From that alone an acquirer can see:

• which languages, frameworks and runtimes the product depends on, and whether any are past end of life;
• how deep the dependency tree goes, and how many components arrive transitively rather than by direct choice;
• whether the product depends on internal packages the target publishes privately, which affects how hard it will be to rebuild in the acquirer's pipeline;
• whether several products from the same target share components, which matters for integration planning.

CISA, the NSA, the FBI and international partners published the 2026 Minimum Elements for a Software Bill of Materials on 29 July 2026. CISA says the document updates and replaces the NTIA's 2021 minimum elements. It adds fields that are useful in diligence: Component Hash Algorithm, Component License, SBOM Tool Name, SBOM Generation Context and SBOM Author Signature, and it renames the old supplier field to Component Producer. Two of those matter directly here. SBOM Generation Context records the lifecycle phase and data available when the SBOM was produced, which tells you whether you are looking at a source scan or a build output. SBOM Author Signature lets the target sign what it hands over, so the acquirer can show later that the file was not altered in the data room.

Licenses: what the product owes

Every component carries a license, and every license carries obligations. The SPDX License List, which the SPDX project describes as an integral part of the SPDX specification, gives each license a standard short identifier, full name, text and permanent URL. The version on spdx.org when we checked was 3.29.0, dated 16 September 2026. Using SPDX identifiers lets two parties talk about "GPL-2.0-only" and "AGPL-3.0-or-later" without arguing about what a free text license field meant.

A license summary built on SPDX identifiers tells the acquirer:

• which components carry permissive licenses with simple attribution duties;
• which carry weak copyleft licenses that matter when the code is modified and distributed;
• which carry strong copyleft licenses that matter for any product the acquirer will distribute in binary form;
• which carry network copyleft licenses such as AGPL-3.0, which matter for hosted products because the obligation reaches users who interact with the software over a network;
• which components have no identifiable license at all, which is often the most important line in the report.

Whether the target runs a license compliance program at all is also worth asking. OpenChain ISO/IEC 5230 defines the key requirements of a quality open source license compliance program. OpenChain's history says the specification was released as OpenChain 1.0 in October 2016 and became ISO/IEC 5230:2020 in December 2020. A target that conforms to it, by self-certification or with a partner, can usually answer license questions faster and with more evidence than one that does not.

Vulnerabilities: what the product exposes

Matching the inventory against vulnerability databases gives a list of known vulnerabilities by component and version. The useful work is in ranking that list.

CISA's Known Exploited Vulnerabilities catalog is, in CISA's words, "the authoritative source of vulnerabilities that have been exploited in the wild." A KEV-listed vulnerability in a product the target ships to customers is a different conversation from a medium severity issue in a test dependency.

For federal agencies, CISA's Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk, issued on 10 June 2026, now sets remediation urgency. It revoked BOD 22-01, the directive that created the KEV catalog, and BOD 19-02. BOD 26-04 sets timelines in its Table 1 from four variables: whether the asset is publicly exposed, whether the CVE is on the KEV catalog, whether an adversary can automate exploitation, and whether exploitation gives partial or total control. Even if neither party sells to the federal government, those four questions are a sound, defensible way to rank a target's findings.

FIRST's Exploit Prediction Scoring System adds a probability: EPSS estimates the chance that a published CVE will be exploited in the wild in the next 30 days, published daily for every CVE. KEV tells you what has been exploited; EPSS tells you what is likely to be next.

Maintenance health: who will fix it

An inventory with versions and release dates shows how far behind upstream the target runs. Components several major versions behind, components whose projects have stopped releasing, and pinned forks of public libraries all predict how much work the acquirer inherits. You can see the pattern without seeing a line of the target's own code.

What a results file cannot tell you

Be clear with the deal team about what this method leaves out.

• First party code quality. A component scan reads dependencies. It does not judge the target's own code, its tests, its architecture or its technical debt.
• Secure development practice. Whether the target reviews code, gates releases and patches on time shows up only partly in a snapshot. Ask for process evidence separately.
• Completeness. Results cover what the target chose to scan. If a repository, an image or a product line was left out, the report will not say so.
• Runtime exposure. Whether a vulnerable component is reachable from the internet in production depends on deployment, which a source scan does not see.

Many acquirers fill those gaps with structured interviews or a supervised review of a few critical modules. Which, and when, is a deal decision.

How a clean team arrangement works for technical diligence

A clean team is a small group, walled off from the people who make competitive decisions, who see sensitive information and pass on only what the deal needs. The FTC's 2018 post is specific about who belongs on one: clean team members should not have pricing, planning or strategy responsibilities, outside counsel should vet the members and anyone added later, and the clean team should follow its own handling protocols.

For a software diligence workstream, a common shape looks like this. Treat it as a starting point for counsel, not a template.

A few practical points make this work for code scans in particular.

Decide the scope in writing first. List the products, repositories and images in scope, and what "scanned" means: a source directory scan, a container image scan, or both. The target signs off on scope before anyone runs anything. Our post on how to find every repository a target company really has covers the inventory side of this.

Put the scanner version and settings in the protocol, so the clean team can reproduce and defend the result.

Prefer outside advisers when the parties compete closely. The FTC post names third party consultants alongside clean teams; an adviser can read raw findings and hand the deal team only blinded, aggregated results.

Stay out of the target's operations. Fix requirements belong in the negotiated agreement, not in instructions from the acquirer's engineers to the target's.

What the target should run, on whose machine, and what leaves the building

The principle is simple: the scanner goes to the code, not the code to the scanner.

On whose machine

Run on hardware the target controls. That might be a developer laptop with a fresh clone, a build server, or a virtual machine inside the target's network. The target's own staff run the commands. The acquirer's people do not need remote access, accounts on the target's systems or a seat next to the operator.

If the target forbids outside software on build infrastructure, a clean virtual machine built for the scan and destroyed afterwards is a good compromise.

What the target should scan

• Source directories for each in-scope product, on the branch or tag that matches what customers run. A scan of the main branch tells you about next month's release; a scan of the release tag tells you about today's.
• Container images the target ships or deploys, because images carry operating system packages and runtimes that a source scan does not see.
• Existing SBOMs the target already produces for its own customers, which can be checked against the fresh scan.

What leaves the building

Only the results files, and only after the target has read them. A typical package is:

1. an SBOM per product in SPDX or CycloneDX;
2. a license summary keyed to SPDX identifiers;
3. a vulnerability list with severity, KEV status and EPSS where available;
4. a short method note: tool and version, database date, scope, branch or tag, date of scan.

Review the SBOM before release: component lists can carry private internal package names, internal registry hosts and unreleased product names. Masking those, as the FTC post suggests for customer identities, is reasonable if counsel agrees.

The method in five steps, with any tool

You can run this with any software composition tool that works offline or on premises.

1. The target installs the tool on a machine it controls and records the version.
2. The target updates the vulnerability database and records the date.
3. The target scans each in-scope directory and image, writing results to a local folder.
4. The target reviews the folder, masks what counsel agreed to mask, and places the files in the data room.
5. The clean team or adviser analyses the files, writes an aggregated report, and counsel reviews it before the deal team sees it.

How to compare findings across several targets on the same terms

Acquirers looking at two or three candidates want a like-for-like view. Scans from different tools, different dates and different scopes are not comparable, and a target that scanned less will look cleaner.

Fix the method, then send the same instructions to everyone

Give every target the same written scan protocol:

• the same tool and the same pinned version;
• the same vulnerability database refresh date, or a refresh on the day of the scan with the date recorded;
• the same scope rules (release tags, include or exclude development dependencies, which images);
• the same output formats;
• the same masking rules.

Normalise before you score

Raw counts mislead, because bigger products show more findings. Normalise with ratios and a short list of signals that matter for price.

Write a worked example, not a league table

Two targets with similar KEV counts can carry very different risk. A clearly labelled worked example helps the deal team see that. For instance (illustrative only): Target A has one KEV-listed vulnerability in an internet-facing service and a clean license picture. Target B has no KEV findings but uses an AGPL-3.0 component inside a hosted product it has modified. Target A's issue is probably a one-week fix. Target B's issue may need legal analysis, a component replacement or a source release, and it could affect how the acquirer can combine products later. The counts say A is worse. The analysis may say otherwise.

Which findings change the price or the terms, and which become a post-close plan

Diligence findings land in one of three places: the price, the contract, or the integration plan. Sorting them early keeps the deal team from arguing about medium severity CVEs while missing a licensing problem.

Findings that usually move price or terms

• KEV-listed vulnerabilities in products customers run, especially internet-facing ones, because they may already have been exploited and may trigger customer notification duties.
• Copyleft obligations that conflict with how the product ships, such as strong copyleft code linked into a distributed proprietary binary, or network copyleft code in a hosted product the target has modified.
• Unknown or conflicting licenses in core components, because nobody can tell you what is owed until someone investigates.
• End of life runtimes or frameworks that will force a major migration soon after close.
• A large gap between the target's own SBOMs and your scan, which suggests customer-facing documents have been inaccurate.

Typical responses include a price adjustment, a specific indemnity, an escrow or holdback, a closing condition, or a remediation covenant. Each is a legal drafting question. Be careful with covenants that tell the target how to run its engineering before close; counsel will want to check them against the gun-jumping concerns described above.

Findings that usually become a post-close plan

• medium and low severity vulnerabilities with fixed versions available;
• dependencies a few minor versions behind upstream;
• permissive license attribution gaps, such as a missing NOTICE file;
• duplicate components across products that can be consolidated later.

These go into a 30, 60 and 90 day plan owned by the integration team. Our acquisition day one security checklist covers the first days, and the inherited vulnerabilities exception plan covers how to carry known issues without pretending they are fixed.

How Safeguard does this job

Everything above works with any capable tool. This section shows how Safeguard handles the target-side scan today, using only what Safeguard's docs and offering describe. Commands appear exactly as the docs show them.

The pieces and their labels

What the local runner is

Safeguard's docs describe the local runner as part of the CLI, not a separate product. You open the interactive terminal, sign in, and the machine starts polling the platform for work assigned to it. In the docs' words, it runs each scan job locally and uploads "only the resulting SBOM and findings, never your source code."

The docs list three situations it is built for. Two fit an acquisition well: the repository is private and the owner will not give a cloud service OAuth access, and the network is restricted so only outbound HTTPS is allowed.

How it talks to the platform matters to a target's security team. According to the runner docs, the runner sends a heartbeat and polls for jobs. All traffic is outbound HTTPS that the runner opens, and nothing connects to it. It executes a claimed job with its own local scan server, uploads the result files (the SBOM and findings), reports the job status, and the source code stays on the machine. Safeguard's offering describes the same flow: the CLI pulls the repository locally, scans on the customer's machine and pushes only encrypted results back. It runs on macOS, Windows and Linux.

Step by step: the target-side scan

These steps are written for the target's scan operator. The acquirer's clean team should review them with the target before the scan date.

1. Install the CLI on a machine the target controls.

The docs give a one-line installer for each platform:

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

# Windows
irm https://cli.safeguard.sh/install.ps1 | iex

The installation docs encourage reading the installer before running it, and show how:

curl -fsSL https://cli.safeguard.sh/install -o install.sh && less install.sh
bash install.sh

The installer checks the download against the release's published checksums.txt. On macOS and Linux a missing checksums file makes the install fail closed. On Windows the docs say it warns and continues, so a target installing on Windows in a strict environment should verify the archive against the published checksums itself.

2. Pin the version, so every target runs the same build.

For a multi-target comparison, pin the release. The installation docs show the variable:

curl -fsSL https://cli.safeguard.sh/install | SAFEGUARD_VERSION=<version> bash

Confirm what landed:

safeguard --version

Record that version in the method note.

3. Complete first-run setup and refresh the databases.

The CLI downloads its scanner toolchain the first time it runs, and the first run also downloads the vulnerability database. Open the interactive terminal once:

safeguard

Then refresh the vulnerability databases on the scan date and record the date:

safeguard update

The docs note that safeguard update refreshes the vulnerability databases, not the binary. safeguard doctor checks the environment, sign-in, tools and policy without changing anything, which is a useful line in the method note.

4. Scan each in-scope directory and image, writing results locally.

The CLI usage docs show safeguard scan building an SBOM for one target, matching it against vulnerability databases and writing the results as JSON under an output folder (default ./output):

# A local directory (your own or proprietary code)
safeguard scan --dir .

# A container image
safeguard scan --image nginx:latest

Use the --output flag to keep each product's results in its own folder. The docs say results include vuln.json, license.json and collection.json, among others, in a folder per scan. The docs also note that safeguard scan runs syft and grype, and that it exits 0 when the scan ran whatever it found, 1 when the command itself failed, and 2 when results were written but the vulnerability scan did not actually run. Check for exit code 2 so a scan that silently skipped vulnerability matching is never reported as clean.

Two flags deserve a protocol decision. --org-namespace names the namespaces that identify the target's own private packages (the docs' example is @mycompany), which helps separate first party packages from open source ones. --resolve-transitive resolves transitive dependencies through deps.dev, a public service; if the target does not want package names queried outside its network during diligence, leave it off and say so in the method note.

5. Review the results on the target's side before anything leaves.

The output folder sits on the target's machine. The target's reviewer opens it, checks scope, masks what counsel agreed to mask, and only then places files in the data room. Nothing in the steps so far required the acquirer to touch the target's systems.

6. Optionally, upload results to a platform workspace through the runner.

If the parties want the results in the Safeguard platform, the docs describe the route: scan from the interactive terminal while signed in, and the runner uploads the SBOM and findings, never the source.

safeguard

Then, inside the terminal, type /login, approve the session in the browser, and type /scan . in the repository.

Sign-in uses an OAuth 2.0 device-code flow. On a machine with no browser, safeguard login --no-browser prints a URL and a code to enter elsewhere. The token is stored on the machine that signed in.

Whose account the runner signs into is a protocol decision for counsel. The target can upload into its own workspace and export from there, or the parties can agree that an outside adviser's workspace receives the results. The docs do not describe a special diligence sharing mode, so treat this as ordinary account access governed by the clean team agreement.

The runner long-polls by default. On a network that forbids held connections, the runner docs show safeguard runner start with --poll-wait 0 to poll at a fixed interval instead.

7. Analyse on the acquirer's side.

The clean team or adviser can work with the files directly. If the target hands over an SBOM rather than scan results, the CLI scans an existing SBOM in SPDX or CycloneDX and detects the format automatically:

safeguard scan --sbom sbom.json

It can also check that the SBOM conforms to its specification before anyone relies on it:

safeguard validate sbom.json
safeguard validate ./sboms --recursive
safeguard validate sbom.json --strict -o report.json

The docs say validate checks CycloneDX (JSON and XML), SPDX (JSON, YAML, tag-value and RDF) and VEX (CSAF and OpenVEX) documents against their specifications. A malformed SBOM is itself a diligence finding.

8. Export for the deal team.

Safeguard's bulk export (GA) covers formats including CSV, Excel, PDF, HTML, JSON and Markdown, with filtering, sorting and column selection across tables. The clean team can build the aggregated, counsel-reviewed summary from those exports rather than hand-copying findings.

License analysis in the platform

Safeguard's license compliance docs describe detection from several signals: package metadata, SPDX identifiers, full-text matching of LICENSE, COPYING and NOTICE files, source file headers, and license strings in container layers. When signals disagree, for example a manifest says MIT while the LICENSE file is AGPL, the platform raises a license-discrepancy finding. In diligence, those discrepancies are worth reading one by one.

Each license is classified by obligation category, from permissive through weak, strong and network copyleft, plus commercial, public domain and unknown. Policies are declared in YAML with allow, deny and require-review lists and can be scoped by context, so a stricter policy can apply to software the acquirer will distribute than to a hosted backend. For vendor SBOMs, the docs describe the same classification feeding third party risk assessments, including whether a component triggers a deny-listed license and whether the license set changed between versions.

One limit to plan around: the docs describe NOTICE and attribution file generation in the platform and state there is no CLI command for generating these yet. If the clean team wants a formal license report, build it from the platform view or exports, not from a CLI command.

When the target will not allow AI near its code

Some targets have a policy against language model inference over source code. Safeguard's offering describes four AI modes per tenant; in Zero AI mode (GA) the platform runs deterministically with no language model anywhere in the loop, and the scanners still work. Where a target wants the whole platform on its own infrastructure, the offering lists full on-prem and fully air-gapped deployment (GA), including the AI models running inside the customer's environment with signed offline snapshot delivery. For a one-off diligence scan, though, the CLI on a single machine is usually enough.

What the acquirer receives, and what it does not

What carries over after close

Diligence results are a snapshot. After close, the acquirer owns the code and the snapshot starts to age on day one.

Onboard the acquired estate properly

Once the acquirer has legitimate access, connect the acquired repositories the normal way. Safeguard's SBOM generation docs list source control integrations for GitHub, GitLab, Bitbucket and generic Git, plus container registries and file uploads. The docs describe daily continuous scanning of all connected projects, with extra triggers on push, on a schedule or on release. Run a fresh scan of everything rather than importing diligence results as truth; repositories the target forgot to include will show up here. Our post on asset discovery for merger and acquisition due diligence covers finding the rest.

With repository access, reachability analysis (GA) becomes useful. It ranks the vulnerable code paths the application actually calls, which turns a long inherited list into a short first week. Safeguard markets reachability as cutting findings by roughly 60 to 80%; treat that as Safeguard's stated figure, not a promise for your estate.

Turn price findings into tracked work

Every finding that moved the price or the terms should become a tracked item with an owner and a date, because the agreement may require it and because the people who negotiated it will ask. Findings that moved into the post-close plan get the same treatment on a slower clock.

Carry inherited exceptions honestly

The target may have accepted some risks deliberately: a pinned component for compatibility, a known vulnerability in an unreachable path. Do not silently inherit those decisions. Re-review each one under the acquirer's policy, give it an expiry date, and record who accepted it. The inherited vulnerabilities exception plan goes into this in detail.

Apply the acquirer's policies and gates

Bring the acquired products under the acquirer's policies and gates (GA) over a planned transition; a blocking gate switched on across an acquired codebase on day one stops releases without fixing anything.

What Safeguard does not do

Be clear about the limits before you plan a diligence process around any tool.

1. Safeguard gives no legal advice on information sharing. It does not decide what is competitively sensitive, who may sit on a clean team, or whether a disclosure is allowed. Counsel decides that.
2. Results reflect only what the target chose to scan. If a repository, branch or image is left out, the output will not reveal the gap. Scope control is a process job, not a scanner feature.
3. A dependency summary cannot reveal first party code quality or architecture risk. Safeguard's scan reads components, manifests, licenses and images. It does not rate the target's own design, test coverage or maintainability from a results file.
4. Safeguard does not value findings in deal terms. It does not turn a vulnerability count into a price adjustment, an indemnity amount or an escrow size.
5. There is no CLI command for license reports or attribution files yet. The docs describe NOTICE and attribution generation in the platform only.
6. There is no special diligence sharing mode in the docs. Who sees uploaded results depends on ordinary account and workspace access, which the clean team agreement must govern.
7. Reachability needs repository access, so a results-only exchange cannot rank which vulnerable paths the target's application calls.
8. Autonomous remediation is not a diligence tool. It opens fix pull requests in repositories it has access to, and it ships switched off with every category set to Manual. Before close, the acquirer should not be changing the target's code at all.

Common mistakes

Asking for the source first. It gives counsel more to worry about and usually slows the deal more than a results-only exchange would.

Comparing targets scanned with different tools. Different scanners use different databases and matching rules. Hand every target the same pinned version and protocol.

Treating a clean report as a clean company. A short findings list may mean a well-maintained product or a narrow scope. Check scope against the repository inventory before you celebrate.

Ignoring exit codes and empty results. A scan that wrote an SBOM but never matched vulnerabilities can look perfect. Safeguard's CLI exits 2 in that case for exactly this reason; other tools may not tell you.

Counting instead of ranking. A hundred medium findings in development dependencies matter less than one KEV-listed vulnerability in a shipped service. Rank by KEV status, exploit likelihood and exposure first.

Missing network copyleft in hosted products. Teams trained on distribution-triggered licenses often skip AGPL-3.0 because "we do not ship binaries." For a hosted product, that is the license to check first.

Letting acquirer engineers direct target engineers before close. Fix requests belong in the negotiated agreement. Day to day direction of the target's work is the kind of control that has drawn gun-jumping enforcement.

Reusing diligence results after close. The snapshot was right on one day. Rescan the full estate once you have access.

FAQ

Can we do technical due diligence without access to the target's source code?

Yes, for open source and dependency risk. The target scans on its own machine and shares the SBOM, license results and vulnerability list. You will not learn about first party code quality or architecture this way, so pair it with interviews or a supervised review of a few critical modules if those matter to the deal.

What is a clean team in M&A due diligence?

A small group, walled off from people with pricing, planning or strategy roles, that reviews sensitive information and passes on only aggregated, counsel-reviewed results. The FTC's Bureau of Competition recommends clean teams and third party consultants when sensitive data must be exchanged before closing.

Is sharing an SBOM with an acquirer a gun-jumping risk?

That is a question for your antitrust counsel. Gun jumping concerns a buyer taking control of the target before the HSR waiting period ends, and information exchange can contribute to it. A component list is less sensitive than source code or pricing data, but counsel should still approve what is shared and who sees it.

What should an acquirer ask a target for in open source diligence?

An SBOM per in-scope product, a license summary keyed to SPDX identifiers, a vulnerability list with KEV status and EPSS, a method note naming the tool, version, database date and scope, and evidence of any license compliance program such as ISO/IEC 5230 conformance.

How do you compare open source risk across several acquisition targets?

Give every target the same pinned scanner version, database date, scope rules and output format. Then normalise: KEV findings as a list, critical and high findings per 100 components, copyleft findings by distribution model, and the share of components with no identified license.

Does Safeguard's local runner send source code to Safeguard?

No, according to Safeguard's docs. The runner runs scan jobs on the local machine and uploads only the resulting SBOM and findings. All traffic is outbound HTTPS that the runner opens, and nothing connects to it.

Can the target run the scan without connecting to the internet?

The CLI downloads its scanner toolchain and vulnerability database on first run, so a fully offline single machine needs those prepared in advance. For a fully disconnected environment, Safeguard's offering lists air-gapped deployment (GA) with signed offline snapshot delivery. Check the air-gapped deployment docs with Safeguard before planning around it.

What should happen to diligence scan results if the deal does not close?

Follow the destruction terms in the confidentiality and clean team agreements. The FTC post recommends enforcing document destruction at the end of the process. Agree in advance where results files are stored so they can all be found and deleted.

From diligence findings to fixes

Once the deal closes, the vulnerabilities you priced in diligence become fix work with deadlines attached, often in components the acquired team has not touched in years. The options below are how Safeguard helps close that work, whether a fixed version already exists or not.

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

The first demo shows the local runner set up on your own machine: install, approve it with its device code, then scan from the terminal. In an acquisition, the target's operator follows the same flow on a machine the target controls, and the source never leaves it.

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

The second demo is a real CLI session that fixes a lodash CVE: it reads the finding and advisory, asks before any command that changes something, runs the install and tests with approval, and pushes nothing, then shows /permissions, /model and /scan .. Before close only /scan . matters; after close, the same flow lets the acquired team work through inherited findings with a human approving each change.

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

To try the target-side scan yourself, download the CLI at safeguard.sh/download and read the runner and CLI guides in the Safeguard docs. For a broader look at where scanners send your data, see does an AppSec scanner send your code to the vendor.

Quick check

Sources

• FTC Bureau of Competition, Avoiding antitrust pitfalls during pre-merger negotiations and due diligence (20 March 2018)
• FTC, Oil Companies to Pay Record FTC Gun-Jumping Fine for Antitrust Law Violation (7 January 2025)
• FTC, Premerger Notification Program
• CISA, 2026 Minimum Elements for a Software Bill of Materials (SBOM)
• CISA, 2026 Minimum Elements for an SBOM (PDF)
• CISA, Software Bill of Materials
• CISA, Known Exploited Vulnerabilities Catalog
• CISA, BOD 26-04: Prioritizing Security Updates Based on Risk
• FIRST, Exploit Prediction Scoring System
• SPDX License List
• OpenChain, ISO/IEC 5230 License Compliance
• Safeguard docs, Local Runner
• Safeguard docs, CLI Usage
• Safeguard docs, CLI Installation
• Safeguard docs, License Compliance
• Safeguard docs, Generate SBOM

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