M&A diligence on a SaaS target in two weeks: the software risk playbook

With a signed letter of intent and a two week window, software diligence on a SaaS target comes down to three questions: what is actually in the code, which of it is exploitable or legally risky today, and what that means for price, terms and the first ninety days after close. You answer them by building your own inventory instead of trusting a questionnaire, checking it against known exploitation and license obligations, and writing findings in language the deal team can carry into the purchase agreement.

This guide is for the corporate development lead and the security lead who share that window. It works with whatever tools you already have. Safeguard comes in near the end, in a separate section, for teams that want the same workflow on one platform.

Key takeaways

• Treat the target's own security questionnaire and self-reported SBOM as claims to test, not as evidence. Build an independent inventory from code, lockfiles and container images, then compare.
• Agree on the access model first. Antitrust guidance says the parties stay independent until close, so the target should run scans on its own machines and share results, not source code, unless counsel approves more.
• Rank vulnerabilities by known exploitation (the CISA KEV catalog) and exploit probability (FIRST EPSS) before CVSS alone. A short list of exploitable issues in production paths moves a deal; a long list of medium findings does not.
• For a SaaS target, network copyleft (AGPL family) matters more than classic GPL, because offering the software over a network can trigger source obligations.
• Write the output as a decision memo: findings that change price, findings that need a specific indemnity or closing condition, and findings for the integration plan.
• Safeguard capabilities used in this playbook, all GA: the local runner and CLI, SBOM generation and analysis, existing SBOM upload and enrichment, SBOM version comparison in Portal, SCA with deep transitive dependency scanning, vulnerability management with EPSS and KEV, reachability analysis and prioritisation, license compliance, policies and gates, TPRM SBOM requests, continuous scanning, and autonomous remediation (GA, ships switched off).

The situation

The LOI is signed on a Friday. Exclusivity runs for a short period and the investment committee meets in fourteen days. The target is a SaaS company with a few hundred repositories across one or two source control organisations, a handful of production services in containers, and an engineering team that is also trying to keep the product running while the deal team asks for documents.

Two people own the answer. Corporate development owns price, structure, representations, indemnities and the integration thesis. The acquirer's security lead owns the technical judgement: can we safely absorb this codebase, and at what cost.

A bad week looks like this. The data room holds a policy binder, last year's penetration test summary and an SBOM from one repository. Nobody on the acquirer side has seen a lockfile. On day twelve someone notices a network copyleft library in the billing service, with no time left to size it. The deal closes with a generic cyber representation, and the real cost shows up in the first integration sprint.

A good week looks different. By day three the acquirer has an independent component inventory for the services that make money. By day seven it has a ranked list of the vulnerabilities that are known exploited or likely to be, with where they sit. By day ten it has a license exposure map for the code that is distributed or offered over a network. By day thirteen it has a two page memo that names specific findings, their likely remediation effort, and the contract language each one needs.

The rules and standards behind it

Software diligence is not one regulation. It is several obligations that become yours at close, plus standards that tell you what good evidence looks like. This section summarises them; it is not legal advice, and deal counsel should decide how each applies to your transaction.

Inherited security becomes your security

The clearest US example is the Federal Trade Commission's action against Marriott and Starwood, announced on 9 October 2024. The FTC alleged three breaches between 2014 and 2020 affecting more than 344 million customers worldwide. One intrusion into Starwood's network began around July 2014 and was not detected until September 2018, years after Marriott acquired Starwood in 2016. The FTC's release says that after the acquisition Marriott "was responsible for the data security practices of both brands." The order requires a comprehensive information security program with independent assessments every two years, and a separate multistate settlement required a payment of 52 million dollars.

The lesson for diligence is plain. The acquirer inherits the target's undetected problems, and regulators judge the combined company on what it did after close. A diligence process that never looks below the questionnaire leaves those problems for the post-close team to find the hard way.

Public acquirers disclose material incidents fast

If the acquirer is a US public company, the SEC's cybersecurity disclosure rules adopted on 26 July 2023 apply to the combined business. Form 8-K Item 1.05 requires disclosure of a material cybersecurity incident, generally within four business days after the company determines it is material. Regulation S-K Item 106 requires annual disclosure in the Form 10-K about cybersecurity risk management, strategy and governance. Once the target is part of the registrant, an exploited vulnerability in the target's product is the acquirer's incident to assess for materiality. That is a strong reason to know, before signing the definitive agreement, which known exploited vulnerabilities sit in the target's production paths.

The parties stay independent until close

In March 2018 the FTC's Bureau of Competition published guidance on avoiding antitrust problems during pre-merger negotiations and due diligence. Its central point is that "right up until consummation, the merger parties are still independent businesses." The guidance suggests sharing only the minimum information needed for a specific diligence question, using clean teams and third-party consultants for sensitive material, limiting downloads from the data room, and giving business staff only aggregated reports reviewed by counsel.

Source code is usually commercially sensitive, and in a deal between competitors it can be competitively sensitive too. That shapes the technical plan: the default should be that the target runs analysis inside its own environment and shares structured results (component lists, vulnerability matches, license classifications), and that only a defined clean team sees anything more detailed. Counsel decides where the line sits for your deal.

What a credible SBOM contains

On 29 July 2026 CISA, the NSA, the FBI and international partners released the 2026 Minimum Elements for a Software Bill of Materials. It updates and replaces the minimum elements the NTIA published in 2021. CISA says the minimum elements apply to all software, and that some software types, including software as a service in cloud environments, may need additional elements. That gives diligence a neutral yardstick for the target's SBOM.

SPDX and CycloneDX are the two open SBOM formats, and the SPDX License List supplies the short identifiers (for example AGPL-3.0-only) you will use when you talk about licenses.

Exploitation signals beat raw severity

Two public data sources should drive your ranking. CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities with evidence of exploitation in the wild. FIRST's Exploit Prediction Scoring System publishes, every day and for every published CVE, a probability between 0 and 1 that it will be exploited in the next 30 days. A finding that is on KEV, or has a high EPSS score, and sits in an internet-facing production service is a deal conversation. A medium CVSS finding in a test fixture is not.

Supply chain risk as an acquisition discipline

NIST SP 800-161 Revision 1 (May 2022, updated November 2024) frames supply chain risk as reduced visibility into how acquired technology is built and deployed, and NIST SP 800-218 (SSDF 1.1, February 2022) offers a common vocabulary for asking how the target builds software. Neither was written for M&A, but both give you defensible questions.

Network copyleft and SaaS

Section 13 of the GNU Affero General Public License version 3, as published on the SPDX license page, says that if you modify the program, your modified version must offer users who interact with it remotely over a network an opportunity to receive the corresponding source. Classic GPL obligations are usually triggered by distribution, which a pure SaaS company may never do. AGPL obligations can be triggered by network use, which is exactly what a SaaS company does. That is why license review for a SaaS target starts with the AGPL family and with anything the target ships to customers (SDKs, agents, mobile apps, on-prem editions).

How teams do it today and where it breaks

Most software diligence still runs on documents: a request list, a security questionnaire, uploaded policies, a penetration test summary, maybe an SBOM, and a two hour session with the CTO. Outside counsel reviews open source licensing from whatever the target discloses.

This breaks in predictable places.

The SBOM is partial. Produced under deadline from one repository, it misses other services, container base images, vendored libraries and unresolved transitive dependencies. It looks complete because it is long.

The questionnaire states policy, not state. A 30 day remediation promise says nothing about which criticals are open today, or whether any are on the KEV catalog.

License review reads declared licenses only. It misses packages whose LICENSE file disagrees with their metadata, and it misses network copyleft exposure when nobody asks how the software is delivered.

Nobody converts findings into terms. Corporate development cannot price a spreadsheet of thousands of findings, so they get ignored or become a representation too broad to enforce.

The access question is argued on day eight, losing days that should have gone to analysis.

Step by step: a two week plan that works with any toolset

The plan below assumes fourteen calendar days from LOI to investment committee, a clean team of two to four people on the acquirer side, and one or two engineers on the target side who can run commands. Adjust the days to your timeline, but keep the order.

Days 0 and 1: agree scope and the access model

1. Name the clean team. List who on the acquirer side may see detailed technical results. Have counsel approve the list and the handling rules, following the FTC guidance on minimum necessary information and aggregated reporting for business staff.
2. Agree the access model in writing. The default that works for most deals: the target runs analysis on its own machines against its own repositories and images, and shares structured outputs (SBOMs, vulnerability and license result files). The acquirer does not receive source code or repository credentials unless counsel approves it.
3. Scope by revenue. Ask the target to list its production services and which ones carry revenue, customer data or regulated data. Diligence depth follows that list, not the repository count.
4. Send the request list (template below) with a deadline of day three.

Request list template

Copy this into your data room request tracker. Each item asks for something that can be checked, not described.

Days 2 to 4: build the independent inventory

5. Generate SBOMs at the deployed commit for every in-scope service, and separately for each production container image. If the target has a scanner, it can use it; if not, any SPDX or CycloneDX generator will do. What matters is that the SBOM is tied to the code that runs.
6. Validate every SBOM against its specification and against the CISA 2026 minimum elements. Record which fail and why.
7. Compare with whatever the target supplied earlier. Components present in the new SBOM but missing from the earlier one are the clearest evidence of how reliable the target's own reporting is. Put the count and two or three examples in the memo.

Days 4 to 7: rank vulnerabilities by exploitation

8. Match components to vulnerabilities using a scanner that resolves transitive dependencies. Shallow resolution is the most common reason a "clean" report is wrong.
9. Enrich with KEV and EPSS. Flag every match that is on the KEV catalog, and every match above an EPSS threshold you set in advance (agree it before you see the data so nobody argues about it later).
10. Place each flagged finding. Is the service internet-facing? Does it handle customer or regulated data? Is the vulnerable code path actually called? If you cannot determine reachability, say "unknown" rather than guessing.
11. Ask the target to confirm or refute the top findings with evidence: a fix commit, a configuration that disables the path, a compensating control. Findings they cannot refute go in the memo.

Days 5 to 10: map license exposure

12. Classify every license in the in-scope SBOMs into permissive, weak copyleft, strong copyleft, network copyleft, commercial and unknown.
13. Check declared against detected. Where package metadata and the actual license text disagree, treat it as a finding to explain.
14. Overlay delivery. For each strong or network copyleft component, note whether it sits in software that is distributed (SDK, agent, app, on-prem build) or offered over a network (the SaaS service). That combination is what counsel needs to judge exposure.
15. List commercial components that need consent or new terms on change of control.

Days 8 to 11: check maintainer concentration and practice

16. Find the critical few dependencies. Which open source packages sit in every revenue service? Check their maintenance signals, for example the OpenSSF Scorecard checks Maintained (is the project at least 90 days old and maintained) and Contributors (does it have contributors from at least two organisations).
17. Test the remediation claim. Compare the target's stated SLA with the age of its open KEV and high EPSS findings. That one comparison usually tells you more about engineering discipline than the whole questionnaire.

Days 11 to 13: write the memo

18. Sort findings into three buckets using the decision table below.
19. Estimate remediation effort for each price or terms finding in engineer weeks, with the assumptions stated.
20. Draft contract asks with counsel: specific representations, specific indemnities, closing conditions, escrow or holdback where it fits.

Day 14: investment committee

21. Present two pages, not a spreadsheet. The appendix can hold the data.

Decision table: what each finding does to the deal

What access should you ask for before close?

Ask for results, not repositories. Under the FTC guidance the parties stay independent until consummation, and results files (components, versions, vulnerabilities, licenses) answer nearly every two week diligence question without moving source code across the line.

How do you test a self-reported SBOM?

Run four checks.

1. Specification validity. Does the document parse as valid SPDX or CycloneDX?
2. Minimum elements. Does it meet the CISA 2026 minimum elements, which replaced the NTIA 2021 baseline?
3. Coverage. Does it include transitive dependencies and container layers, or only direct dependencies of one repository?
4. Difference from an independent SBOM. Generate a fresh SBOM at the deployed commit and compare. List what was added, what was missing, and which versions differ.

The fourth check matters most: a target whose SBOM missed half its components has other disclosures that need closer reading too.

How do you read license exposure for a SaaS target?

Start from delivery, not from the license list. Map each copyleft component to one of three delivery modes: the hosted service, software shipped to customers (SDKs, CLIs, agents, apps), or a self-hosted edition.

• Hosted service only: classic GPL obligations are usually not triggered without distribution, but AGPL section 13 obligations can be, if the component is modified and users interact with it over a network.
• Shipped to customers: strong copyleft in a distributed component can create source disclosure obligations for the combined work. Weak copyleft (for example LGPL or MPL) usually has narrower, file or library level obligations.
• Self-hosted edition: treat it as distributed software.

Counsel judges the specific cases. Your job is to find them early and describe each one precisely: component, version, license expression, location, whether it was modified, and delivery mode.

Illustrative scenario: two weeks on a fictional billing platform

This is a composite example built for this guide, not a customer and not a real transaction. The companies are invented, and every number is an example input you should replace with your own.

The parties. "Halden Group" (fictional) is a US public company that sells finance software. It has signed an LOI to buy "Larkspur Ledger" (fictional), a SaaS billing platform. Example inputs: Larkspur has about 180 repositories in one source control organisation, 12 production services, 9 container images in production, a JavaScript SDK and a mobile app shipped to customers.

Day 1. Halden's counsel approves a clean team of three: the deputy CISO, one product security engineer, and one corporate development analyst who receives only aggregated reports. The diligence protocol says Larkspur engineers run all scans on Larkspur machines and share result files. No source code leaves Larkspur.

Day 3. The earlier data room SBOM covered the main API repository only. Fresh SBOMs now cover all 12 services and 9 images at the deployed tags. Example input: the fresh inventory has roughly three times as many unique components. Two fresh SBOMs fail validation and are regenerated.

Day 6. Example inputs: 6 findings are on the KEV catalog. Four sit in an internal batch job. Two sit in the public invoicing API, in a transitive dependency of the PDF library, and one has been open longer than the questionnaire's 30 day promise.

Day 8. Larkspur confirms one of the two is not reachable because the affected feature is disabled in production configuration, and shows the configuration. The other is reachable and has no compensating control. It goes into the memo as a closing item.

Day 9. License classification finds a network copyleft component in a reporting service that Larkspur patched locally two years ago. Modified, network copyleft and used by customers over the network: it goes to counsel as a terms item. A strong copyleft component in the SDK's build tooling turns out not to ship in the SDK, so it moves to the integration plan.

Day 11. One core parsing library used by every revenue service has a single active maintainer and failed the Maintained check. It goes on the post-close watch list with a budget line for replacement.

Day 13. The memo has one closing item (the reachable KEV finding in the invoicing API, fix before close or a specific indemnity), one terms item (the modified network copyleft component, a specific license representation and a plan to replace it), a reliability paragraph about the SBOM gap, and seven integration items.

How Safeguard does this

The steps below map the two week plan onto Safeguard. Every capability named here is GA. Commands are as docs.safeguard.sh shows them at the time of writing; the snippets were not run for this post, and safeguard --help is the authority if the docs and your build disagree.

1. Let the target scan on its own machine with the local runner (GA)

The access model in the FTC guidance (results, not repositories) maps directly onto the local runner. The runner is part of the Safeguard CLI, not a separate product. According to the docs, it runs each scan job locally and uploads only the resulting SBOM and findings, never the source code, and all traffic is outbound HTTPS that the runner opens; nothing connects to it.

The target's engineer installs the CLI with the one-line installer from the docs:

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

Then opens the terminal with safeguard, types /login to approve the session in the browser, and runs /scan . in each repository. A scan from the interactive terminal while signed in uploads the SBOM and findings to the platform; the source stays on the target's machine.

How you arrange accounts is a deal decision. Safeguard supports organisations, members, and roles and permissions (all GA), so one pattern is a separate organisation for the deal limited to the clean team. Agree it with counsel first.

2. Or keep results entirely offline with the CLI (GA)

If counsel prefers that nothing is uploaded to a platform the acquirer controls before close, the CLI can scan and write results to local files that the target reviews and then shares through the data room:

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

# A container image
safeguard scan --image myregistry.azurecr.io/myapp:v1 \
  --registry-username "$REGISTRY_USER" \
  --registry-password "$REGISTRY_PASSWORD"

Per the docs, safeguard scan builds an SBOM, matches it against vulnerability databases and writes JSON files (including vuln.json and license.json) under ./output. It exits 2 when results were written but the vulnerability scan did not run, so check for that explicitly rather than reading it as a clean pass.

3. Validate the target's SBOMs before you rely on them (GA)

For the first check on any SBOM the target supplies, the CLI validates documents against their specifications. The docs show:

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

It checks CycloneDX (JSON and XML), SPDX (JSON, YAML, tag-value and RDF) and VEX documents. --strict treats warnings as errors. Validation against the format specification is not the same as validation against the CISA 2026 minimum elements, so keep the minimum elements check as a separate step in your workpapers.

4. Upload the self-reported SBOM for enrichment (GA)

The existing SBOM integration takes SBOMs created by other tools. In the web app you go to Integrations, click Connect on the Upload SBOM card, enter project details, and drop the file. The docs list CycloneDX 1.3 to 1.6 and SPDX 2.2 and 2.3, plus conversion from some other tools' JSON output, with a 100MB file limit.

After upload, Safeguard validates the SBOM, enriches it with vulnerability matches, EPSS, KEV, license and supplier data, and scores attestation, risk, reachability and dependency health. The docs also show quality metrics (completeness score, component coverage, PURL accuracy, version specificity) that fit the reliability paragraph of the memo. The CLI does not upload SBOMs; use the UI.

5. Compare the self-reported and independent inventories (GA)

Portal's SBOM Repository (here Portal means the SBOM publish and share product, not the free tier) groups SBOMs by product and version. Its Version Comparison lets you select two versions of the same product and see added components, removed components, version changes, new vulnerabilities and resolved vulnerabilities.

Store the target's earlier SBOM and the fresh one as two clearly labelled versions of one product (for example "self-reported" and "independent at deployed tag"); the comparison is the evidence for step 7 of the plan.

6. Rank vulnerabilities with SCA, EPSS, KEV and reachability (GA)

SCA with deep transitive dependency scanning (GA) builds the inventory; vulnerability management (GA) matches it. The Vulnerabilities view groups findings as Critical, High, Medium, Low and Exploitable (known active exploitation in the wild), and for each one shows the CVE, CVSS, EPSS score, whether it is exploited, the affected component and version, and the fixed version.

Reachability analysis and prioritisation (GA) classifies each vulnerability as reachable, conditionally reachable, unreachable or unknown, and combines reachability with EPSS, KEV, runtime context and business context into one ranked list. Unknown is treated conservatively as potentially reachable, which is the right default for diligence. Runtime context depends on what the target has deployed; in a two week window with no runtime collector, expect static and configuration reachability to carry the weight.

This view produces the short list the target must confirm or refute.

7. Map license exposure (GA)

Each project's Suppliers and Licenses tab shows license distribution by category (permissive, weak copyleft, strong copyleft, commercial, public domain) and a compliance status per component, with SPDX identifier, license text, obligations and compatibility analysis. Supplier types are listed as open source project, commercial vendor, internal or unknown.

The license compliance page adds the network copyleft category (for example AGPL-3.0 and SSPL-1.0, flagged as high risk for SaaS) and a license-discrepancy finding when signals disagree, for example package metadata saying MIT while the LICENSE file is AGPL. That finding is exactly the declared versus detected check in step 13. The same page shows a license policy in YAML. This is the docs example, not run for this post; adapt the lists to your counsel's position:

apiVersion: safeguard.sh/v1
kind: LicensePolicy
metadata:
  name: default
spec:
  allow:
    - MIT
    - BSD-2-Clause
    - BSD-3-Clause
    - Apache-2.0
    - ISC
    - MPL-2.0
  deny:
    - GPL-3.0-or-later
    - AGPL-3.0-or-later
    - SSPL-1.0
  require_review:
    - GPL-2.0-only
    - LGPL-3.0-or-later
    - "Custom/*"
  context_overrides:
    - apply_to: { env: sdk }
      deny:
        - LGPL-3.0-or-later # LGPL tricky in SDK distribution
    - apply_to: { env: server }
      allow:
        - LGPL-3.0-or-later # fine for a service binary

The context overrides matter for a SaaS target: the same license can be fine in a server binary and a problem in a distributed SDK. Findings show the transitive path.

8. Express the acquirer's risk appetite as policies (GA)

Policies and gates (GA) turn your decision table into rules that generate findings. The docs list conditions such as vulnerability severity, CVSS score, EPSS score, license, component age and maintenance (for example "no abandoned packages"). Each policy's action is Block (the gate fails), Warn (the gate passes with a warning naming the policy) or Notify (the gate passes and a notification is sent). Approval for a legitimate exception runs through the exception workflow, with a business justification, an expiry date and an audit trail.

Before close, policies sort findings into your buckets. After close, they become the integration standard, and the exception workflow records which pre-close findings the deal team accepted.

9. Request SBOMs formally through TPRM (GA)

For a tracked request instead of a data room upload, TPRM (GA) SBOM Requests let you treat the target like a supplier: send a request with a template and a deadline, track it from Sent to Validated or Rejected, and let automatic reminders chase it. Received SBOMs are validated for format and completeness and scanned for vulnerabilities, and a rejection workflow asks for a revision.

10. Keep watching after close (GA)

For the post-close watch list, continuous scanning (GA) rescans all projects daily and re-evaluates them when new CVEs are published, with optional triggers on push, on a schedule or on release. Bulk export (GA) to CSV, Excel or PDF gives the integration team the data the deal team saw.

When remediation starts, autonomous remediation (GA) can open fix pull requests. It ships switched off, with every category set to Manual, so the acquiring team decides what runs on its own. The section below on fixing without waiting for upstream covers how that works.

Requirement versus Safeguard versus what you still own

What Safeguard does not do

• It does not give legal opinions. License classification, obligations and policy evaluation tell you where to look. Whether a specific use triggers a specific obligation, and what to do about it, is counsel's call.
• It does not decide price or contract terms. Safeguard produces evidence; corporate development and counsel turn it into terms.
• It does not see what the target does not scan. With the local runner or CLI, coverage is whatever repositories and images the target runs it against. Your scope list and the deployed commit list are the control, and you should ask the target to confirm completeness in writing.
• It does not replace a penetration test or architecture review. This workflow covers components, vulnerabilities in those components and licenses. Business logic flaws, access control design, cloud configuration outside the scanned images, and data handling practices need their own work.
• It does not make pre-close access decisions for you. Organisations, roles and permissions are configuration. Who may see what before close is an antitrust and confidentiality question for counsel.
• Runtime context needs runtime data. Reachability that uses runtime context depends on what is deployed and collected. In a two week window you should expect to rely on static and configuration reachability, and mark the rest as unknown.

What to measure

Use this checklist to judge whether your diligence process is working. These are things to track, not claimed outcomes.

• Day by which the access model was agreed in writing (target: day 1)
• Share of revenue-carrying services with a fresh SBOM at the deployed commit
• Share of production container images with a fresh SBOM
• Difference between the self-reported and independent inventories, as unique components added, removed and version-changed
• Number of KEV-listed findings in internet-facing production services, and how many the target refuted with evidence
• Number of findings above your agreed EPSS threshold, by reachability state
• Number of network copyleft and strong copyleft components, by delivery mode
• Age of the oldest open KEV finding, compared with the target's stated SLA
• Number of core dependencies failing maintenance checks
• Count of findings in each memo bucket (price or closing, terms, integration)

Common mistakes

• Asking for repository access on day eight. Agree the access model on day one, with counsel, or you will spend week two negotiating it.
• Scanning the default branch instead of the deployed commit. Diligence is about what runs in production today. Tie every SBOM to a tag or commit.
• Ranking by CVSS alone. Rank by KEV, then EPSS and reachability, then CVSS. Otherwise the memo fills with findings nobody can act on.
• Treating GPL and AGPL the same for a SaaS target. Delivery mode changes the analysis. Map each copyleft component to how it reaches users.
• Handing the deal team a spreadsheet. Translate findings into price, terms and integration items, with effort estimates and contract asks.
• Stopping at close. The watch list needs an owner and continuous monitoring from day one after close, because the acquirer is now responsible for the target's security practices.

FAQ

How long does software due diligence on a SaaS company take?

A focused review of the revenue-carrying services fits in two weeks if access is agreed on day one and the target can run scans quickly. Scope by business impact, not repository count.

Should the acquirer get access to the target's source code before close?

Usually not by default. FTC guidance says the parties stay independent until consummation and recommends minimum necessary sharing through clean teams. Make any exception specific and approved by counsel.

Is the target's SBOM enough for diligence?

Treat it as a claim to test: validate it, check it against the CISA 2026 minimum elements, and compare it with an independent SBOM at the deployed commit.

Which vulnerabilities should change the deal?

KEV-listed vulnerabilities in internet-facing production services without a compensating control come first, then reachable high EPSS findings in services with regulated data. The rest belongs in the integration plan.

Why does AGPL matter more than GPL for a SaaS target?

GPL obligations usually follow distribution, which a pure SaaS company may not do. AGPL section 13 reaches modified versions used over a network, which is how SaaS works.

What is a license discrepancy and why does it matter?

Package metadata and the license text disagree, for example metadata saying MIT while the LICENSE file is AGPL. Ask the target to explain it before relying on the declared license.

How do public company disclosure rules affect diligence?

For a US public acquirer, Form 8-K Item 1.05 requires disclosure of material cybersecurity incidents, generally within four business days of the materiality determination. After close, the target's incidents are yours to assess.

What should a software diligence memo include?

Scope and method, how reliable the target's disclosures were, price and closing items, terms items, integration items, a post-close watch list, and the limits of the review. Two pages, data in an appendix.

Related reading

• SBOMs for mergers and acquisitions due diligence
• Open source license risk in M&A due diligence
• Vendor risk during merger and acquisition due diligence
• Asset discovery for merger and acquisition due diligence
• GNU AGPL versus GPL: when AGPL applies
• A vendor SBOM ingest program blueprint for 2026

The matching use case page is M&A diligence.

Diligence finds the problems; somebody still has to fix them after close, and much of that work lands on open source dependencies the target never upgraded. The block below describes how Safeguard handles that remediation work for the acquired codebase once it 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

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. 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: setting it up on your own machine, approving it with its device code, then scanning from the terminal. In a deal, this is the step the target's engineer runs on the target's machine, so the acquirer receives results without receiving source code.

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

The second demo is a real CLI session: install, safeguard opens the interactive terminal, the user asks it to fix the lodash CVE in the repository, and it reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing; then it shows /permissions, /model and /scan . The demo is a single dependency fix, not a diligence run. It shows the post-close side of the same workflow: once the target's code is yours, a closing item like a reachable known exploited finding becomes a reviewed change on a branch.

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

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. For a deal team, the useful part is the permission step: you decide which tools an assistant may call before anyone asks it questions about the diligence data.

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

Quick check

Sources

• Safeguard use case: M&A diligence
• Safeguard docs: Local Runner
• Safeguard docs: CLI Usage
• Safeguard docs: Generate SBOM
• Safeguard docs: Existing SBOM
• Safeguard docs: Portal SBOM Repository
• Safeguard docs: Vulnerabilities
• Safeguard docs: Reachability analysis
• Safeguard docs: Deep dependency scanning
• Safeguard docs: Suppliers and Licenses
• Safeguard docs: License compliance
• Safeguard docs: Policies and Gates
• Safeguard docs: TPRM
• Safeguard docs: TPRM SBOM Requests
• FTC: action against Marriott and Starwood over multiple data breaches (9 October 2024)
• FTC Competition Matters: avoiding antitrust pitfalls during pre-merger negotiations and due diligence (20 March 2018)
• SEC press release 2023-139: cybersecurity risk management and incident disclosure rules
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• CISA: Software Bill of Materials
• CISA: Known Exploited Vulnerabilities Catalog
• FIRST: Exploit Prediction Scoring System
• NIST SP 800-161 Rev. 1: Cybersecurity Supply Chain Risk Management Practices
• NIST SP 800-218: Secure Software Development Framework v1.1
• SPDX License List
• SPDX: GNU Affero General Public License v3.0 only
• CycloneDX specification overview
• OpenSSF Scorecard

To try the workflow, download Safeguard at safeguard.sh/download and read the docs at docs.safeguard.sh.

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