Launching a Self-Hosted Edition of Your SaaS: Open Source Checklist

When you ship your SaaS as containers, an installer or a Helm chart that customers run themselves, you start distributing software, and open source licenses that never applied to a hosted service can now apply. Before launch, review the licenses of what actually ships (not just your repository), include the attribution and notice files those licenses require, give customers an SBOM for every release, and hold the release artifact to a stricter vulnerability bar than your SaaS deploys, because you can no longer patch it on your own schedule.

This checklist is for product security leads, platform leads and product counsel at a US SaaS company preparing a self-hosted, on-prem or private-cloud edition for bank, government or health customers. Nothing here is legal advice; the license questions belong with your counsel.

Key takeaways

• Running software for users over a network is not distribution under the GPL family. Handing a customer a copy is. GPLv3 says "mere interaction with a user through a computer network" is not conveying; giving a customer an image is.
• Copyleft licenses change behaviour at that moment: GPL (source for object code), LGPL (relinking and notice duties), MPL 2.0 (file-level source availability) and AGPL (which reached modified versions you ran as SaaS, and now reaches every copy you distribute).
• Permissive licenses still carry duties on distribution. Apache 2.0 section 4 requires a copy of the license and the content of any NOTICE file.
• A container image carries far more than your dependency tree: base image packages, runtimes, vendored binaries and tools added in the Dockerfile. Review the image you ship, not the repository.
• Give customers an SBOM per release. CISA's 2026 Minimum Elements (29 July 2026) replaced the NTIA 2021 list and added Component License and SBOM Generation Context among other new elements.
• The release gate for a distributed artifact should be stricter than a SaaS deploy gate.
• Customers on old versions need a written support window and an SBOM kept for every supported release.
• Safeguard capabilities covered, with maturity labels: license compliance (GA); SBOM generation and analysis (GA); SCA and vulnerability management (GA); policies and gates (GA); the Compliance and GRC suite, which holds the License Obligations internal framework (GA); Portal, meaning the SBOM publish and share product (GA); CSAF and VEX upload (GA); the CLI and local runner (GA); autonomous remediation (GA, ships switched off with every category set to Manual); Gold Open Source (GA); fork and patch (GA).

What changes the day you hand customers a copy

For years your product was a service. The open source inside your servers stayed on your infrastructure, and your license review probably asked one question: is there anything under the AGPL in the code we run?

A self-hosted edition flips that. The customer receives the software itself: images pulled from your registry, an installer, a virtual appliance, a Helm chart, or a tarball for an air-gapped site. Every component inside travels to a third party, which is the act most open source licenses attach their conditions to.

Three other things change at the same moment:

1. The customer inherits your components. Their security team will scan your images on day one, and every CVE in your base image becomes a finding in their queue with your product name on it.
2. Patches stop rolling out on your schedule. A fix ships when each customer schedules a change window, which for a bank or hospital can be weeks or quarters away.
3. Versions multiply. On-prem there are as many production versions as you have customers who have not upgraded.

Why does distribution change license obligations?

Most open source licenses grant permission to use and modify freely, and attach their conditions to passing a copy to someone else. SaaS rarely passes a copy. A self-hosted edition always does.

The GPL: "convey" is the trigger

GPLv3 section 0 defines "convey" as any propagation that lets other parties make or receive copies, and adds that interaction over a network with no transfer of a copy is not conveying. The FSF's GPL FAQ confirms that a company running a modified GPL program on its website does not have to release the source. It is equally clear about the other side: copies used inside one organization are not distribution, but "when the organization transfers copies to other organizations or individuals, that is distribution". Handing a customer an image is that transfer.

Once you convey object code, GPLv3 section 6 requires the Corresponding Source in one of several ways. The two a software vendor usually weighs:

• 6(b), a written offer, for a physical product or medium such as an appliance or a shipped drive. The offer must be valid for at least three years and for as long as you offer spare parts or customer support for that product model.
• 6(d), network access. If customers download the object code from a designated place, offer equivalent access to the source from the same place at no further charge. The source can sit on another server if you keep clear directions next to the object code, and you remain responsible for keeping it available as long as needed.

GPLv2, which still covers many operating system packages, has the same shape in section 3: ship the complete source, or a written offer valid for at least three years.

Two details trip up vendors new to this. First, Corresponding Source means the source for the binary you shipped; the FAQ says supplying the original upstream source is not enough for an extended version. If you patched a GPL tool in your image, you owe the patched source. Second, aggregation is not combination. GPLv3 section 5 says including a covered work in an aggregate does not make the GPL apply to the other parts. The FAQ says modules in the same executable or linked in a shared address space are almost surely one program, while pipes, sockets and command line arguments normally connect separate programs, and calls the final line a legal question.

A container image is typically an aggregate: your application, a shell, a C library and dozens of utilities, each a separate program. Aggregation keeps the GPL from reaching your application, but you are still conveying the GPL programs themselves, so you still owe their source.

The LGPL: relinking and notices

LGPLv3 is written as additional permissions on top of GPLv3. Section 4 lets you convey a "Combined Work" (your application plus the library) under terms of your choice, if those terms do not restrict modification of the library portions, and if you also give prominent notice that the library is used, include copies of the GPL and LGPL texts, show the library's copyright notice among any run-time copyright notices, and either provide materials that let the user relink with a modified library or use a shared library mechanism that works with an interface-compatible modified version. In SaaS these duties are invisible. In an image, the notice duties apply to every LGPL library you ship, and static linking makes the relinking question real.

The AGPL: already in play for SaaS, and wider on-prem

AGPLv3 section 13 says that if you modify the program, your modified version must prominently offer all users interacting with it remotely an opportunity to receive its Corresponding Source. Two things change on-prem. Section 13 reaches modified versions only, so a SaaS company running an unmodified AGPL component may have had no source duty; once you distribute it, the AGPL's conveying terms, which mirror the GPL's section 6, apply whether or not you changed it. And if you ship a modified AGPL component, it is now your customer's deployment that offers network access, so your source offer has to travel with the product.

MPL 2.0 and Apache 2.0

MPL 2.0 draws its boundary at the file. Section 3.2 says that if you distribute covered software in executable form, you must make the source available and tell recipients how to get it by reasonable means in a timely manner. Section 3.3 lets you ship a larger work under your own terms if the MPL files keep their conditions. If you modified an MPL file, the modified file's source goes to customers; your own files do not.

Apache License 2.0 section 4 lets you redistribute in source or object form if you give recipients a copy of the license, mark modified files, keep copyright and attribution notices, and, where the work includes a NOTICE file, reproduce its attribution notices in a NOTICE file you ship, in your documentation, or in a display your product generates where third-party notices normally appear. MIT and BSD ask, in different words, that the copyright and permission text travel with copies. Hundreds of packages in an image each carry that small duty, which is why notices are generated, not hand written.

The comparison table

"Usually" is doing honest work there. Some licenses outside the Open Source Initiative's Open Source Definition attach conditions to hosted use, and upstream commercial contracts can say anything. A license that fails the definition needs a closer read, not a default allow.

What does a container image or installer contain that the repo scan never showed?

Your SaaS dependency scan reads lockfiles and manifests. That describes your code's dependency graph, not the artifact you ship. These layers usually sit outside it:

• Base image operating system packages. A C library, a shell, coreutils, a package manager, TLS and compression libraries, often a few hundred packages, many GPL or LGPL licensed. Debian-family packages record their licensing under /usr/share/doc/<package>/copyright.
• Language runtimes, with their own licenses and their own CVE streams.
• Tools added in the Dockerfile. curl, git, jq, a database client, often added for debugging during SaaS days and never removed.
• Vendored or downloaded binaries. Anything fetched in a build step or committed as a binary. Manifest-based scans never see these.
• Bundled services. A self-hosted edition often ships its own database, cache, search engine or proxy, which in SaaS were managed services. Each brings a license (some source-available) and a patch cadence.
• Front-end bundles, which now ship inside the image along with whatever license comments the bundler kept.
• Chart and installer extras: subcharts, init containers, sidecars and helper scripts.

The rule: inventory and review the artifact you ship, built the way you ship it. Generate the SBOM from the built image in CI, after the build step, and run license and vulnerability policy against it. CISA's 2026 Minimum Elements captures this as SBOM Generation Context, with examples "before build", "build" and "after build"; an SBOM from source is "before build", binary analysis is "after build". For a self-hosted release, the after-build SBOM matches what the customer runs.

A useful first exercise: build your self-hosted image, list its operating system packages and license fields, and compare that list to your repository's dependency inventory. The gap is your pre-launch license review backlog.

Shrink the image before you review it

Every package you remove is a license you do not have to honour and a CVE you do not have to explain. Use a minimal or distroless base where your runtime allows it, use multi-stage builds so compilers and package managers stay in the build stage, remove debugging tools, and where your architecture allows it, connect to the customer's own database or cache instead of bundling one.

What attribution and notice files must ship, and where do they go?

The Apache Software Foundation's guide to assembling LICENSE and NOTICE files states the principle well: they must exactly represent the contents of the distribution they sit in, and only components actually included have any bearing on them. That works for any vendor. The notices in your image should describe that image.

A complete notice package for a self-hosted release has four parts:

1. A third-party notices file (often THIRD-PARTY-NOTICES.txt or NOTICE) listing every component, version, license identifier and copyright notice.
2. The reproduced content of upstream NOTICE files for Apache-licensed components that have them.
3. A licenses directory with the full text of each license that requires it.
4. Source access for copyleft components: the source alongside the release, or a written offer and a place to get it.

Two cautions. Keep the base image's own copyright files; stripping /usr/share/doc to save space also strips licensing information for packages you still ship. And notices are per release, so the release pipeline must generate them.

What should the customer receive with each release?

Bank, government and health customers increasingly ask for a release package, not just a download link:

The SBOM, against CISA's 2026 Minimum Elements

CISA, NSA, FBI and international partners published the 2026 Minimum Elements for a Software Bill of Materials on 29 July 2026. CISA's page says it updates and replaces the NTIA's 2021 minimum elements, so build to the 2026 document.

Its new data field elements are SBOM Author Signature, SBOM Data Format Name, SBOM Data Format Version, SBOM Generation Context, SBOM Tool Name, SBOM Tool Version, SBOM Version, Component Hash Value, Component Hash Algorithm and Component License. Three matter most for a self-hosted launch:

• Component License. License identifiers for each component, preferably SPDX identifiers, with unknown license information stated as unknown and proprietary conditions noted. Your SBOM now carries license data your customer's counsel can read, so it had better agree with your notices file.
• SBOM Generation Context. Say "after build" for the shipped image, and mean it.
• Distribution and Delivery. The document says an SBOM can accompany installation, or be reachable at a version-specific URL, an API or a public repository.

NIST SP 800-218 (SSDF) asks the same from the producer's side. PS.3.1 asks you to securely archive the files and supporting data, including provenance data, for each software release. PS.3.2 asks you to collect, safeguard, maintain and share provenance data for all components of each release, with an SBOM as the example. Federal buyers will map your release package to those tasks.

VEX, so their scanner and your engineers agree

Some findings in your image will be in code your product never uses. A VEX statement says so in a form the customer's tools can read. CISA's Minimum Requirements for VEX (April 2023) set the minimum elements, and CycloneDX and CSAF can both carry VEX data. A "not affected" statement needs a justification you could defend to the customer's security engineer, and it is per product version.

Which vulnerability bar should block a release artifact?

The SaaS deploy gate asks whether a build is safe enough to replace what is running, knowing you can deploy again tomorrow. Many teams block criticals and accept the rest. The release gate asks whether an artifact is safe enough to sit in a customer's data centre for a year, scanned by their tools and unpatched until their next change window. A missed finding costs more and a delay costs less, which argues for a stricter bar. A finding caught at the release gate costs one rebuild; the same finding after release costs a patch release, an advisory and a conversation with every customer on that version.

A worked example to adapt, not a standard:

Federal customers have their own clock. CISA's BOD 26-04, issued 10 June 2026, superseded BOD 22-01 and sets risk-based remediation timelines for agencies from four factors: asset exposure, KEV status, whether exploitation can be automated, and technical impact. It binds agencies, not vendors, but once your image runs inside an agency your components are its assets, and shipping with a KEV entry hands it a deadline on day one.

How do you handle customers who run old versions for years?

Some customers upgrade every quarter. Regulated customers whose change control treats every upgrade as a project may install once and stay for three years. Plan for both.

Write the support window down. Publish how many versions you support, what "supported" includes, and each version's end-of-support date, in the contract and the documentation. If you ship appliances or physical media, GPLv3 6(b) ties a written source offer to at least three years and to as long as you offer support for that product model; for downloads, 6(d) asks you to keep the source available as long as needed. Align source retention with the support window either way.

Keep an SBOM for every supported release. NIST SSDF RV.1.2 gives as an example running automated analysis "for all supported releases", which needs an inventory for each one. Re-run vulnerability matching against those SBOMs on a schedule; new CVEs land in old components every week.

Decide in advance how fixes reach old versions. For each new finding, choose and record one of four responses: a patch release with the upgraded component; a backport to the old component version; mitigation plus a VEX statement when the code is not reachable or exploitable; or a required upgrade when the old line cannot take the fix. Our post on tracking dependency versions in customer-hosted installs you cannot see covers the field side of this problem.

The pre-launch checklist

1. Define the artifact: every image, chart, installer and appliance, and every bundled service.
2. Build it the way you ship it, in CI, from a tagged commit.
3. Generate an after-build SBOM in SPDX or CycloneDX.
4. Classify every license: permissive, weak, strong or network copyleft, commercial, public domain, unknown.
5. Resolve unknowns and discrepancies before launch.
6. Write a distribution license policy, separate from the SaaS one, signed off by counsel.
7. Remove or replace components that policy denies, and shrink the image.
8. Prepare source access for copyleft components, including your patches.
9. Generate notices and license texts into the image, installer and release downloads.
10. Set a release vulnerability gate stricter than the SaaS gate, with named exception approvers.
11. Write VEX statements for known findings that do not affect the product.
12. Publish the release package: digests, SBOM, notices, source access, VEX, release notes.
13. Publish the support window and align source retention with it.
14. Archive everything per release, as SSDF PS.3.1 and PS.3.2 describe.
15. Schedule re-scans of every supported release's SBOM.

How Safeguard does this job

All of the above can be done with open source tools and discipline. Safeguard puts the license review, SBOM, gate and publishing steps in one place, driven from the CI step that builds your self-hosted image. Here is the flow as Safeguard's docs describe it.

Step by step

1. Scan the release image in CI (SCA and vulnerability management, GA; CLI, GA). The container images guide adds one step after the image is built. It scans the image on the runner and records it under the image's repository, one version per environment and tag:

   safeguard ci scan --image "ghcr.io/acme/api:$TAG" --environment prod --wait --fail-on critical
   

   The docs say only the results leave the runner and no repository integration is needed. The image is read from the local Docker daemon, or pulled from a registry with SAFEGUARD_REGISTRY_USERNAME and SAFEGUARD_REGISTRY_PASSWORD set as CI secrets. Environment names can be any letters, digits and dashes, so a separate environment for the self-hosted build keeps its versions and failures apart from SaaS builds. The docs' GitHub Actions example installs the CLI with curl -fsSL https://cli.safeguard.sh/install | bash and runs the same command.

2. Get the after-build inventory (SBOM generation and analysis, GA). Each scan produces the SBOM for that version, exportable in SPDX or CycloneDX. For a local check, the docs show safeguard scan --dir ., which writes results under ./output, including a license.json with the licenses found.

3. Review licenses in the Suppliers & Licenses tab (license compliance, GA). Per component you see the SPDX identifier, license text, obligations, attribution requirements and compatibility analysis. The docs say detection reconciles package metadata, SPDX identifiers, full-text matching of LICENSE, COPYING and NOTICE files, source file headers and, in container layers, the /usr/share/doc/*/copyright files. When signals disagree, for example a manifest saying MIT and a LICENSE file saying AGPL, Safeguard raises a license-discrepancy finding. Licenses are classified as permissive, weak copyleft, strong copyleft, network copyleft, commercial, public domain or unknown, and SPDX compound expressions with OR, AND and WITH are evaluated as expressions.

4. Write a distribution policy that differs from your SaaS policy. The docs show license policies in YAML with allow, deny and require_review lists and context_overrides for labelled contexts; their own example denies an LGPL version for an SDK distribution while allowing it for a server binary. The docs say policies can be scoped to asset labels, so an open-core distribution can have a different policy from the SaaS backend. Label your self-hosted assets and give them the stricter policy counsel approved. Policies can also be created in the app under Settings, License Policies.

5. Check the License Obligations framework (Compliance and GRC suite, GA). This internal framework is on unless you switch it off in Compliance, Manage. Each scan checks that every component's license is identified, that the open source inventory is complete, that attribution data has both name and version, that the supplier or copyright holder is known, that versions are exact (since source disclosure attaches to the exact distributed version), and that a machine-readable license manifest uses SPDX expressions. The docs cite ISO/IEC 5230:2020, the OpenChain license compliance standard, for the inventory and identification requirements.

6. Gate the release (policies and gates, GA). --fail-on <severity> with --wait fails the step on a dependency vulnerability at or above the severity you choose. --fail-on-gate <gate> fails the job when a named policy gate is not Passed or Warning; it needs policy outcomes, which Safeguard turns on per workspace and which are off until then. Each policy's Action decides what a failure does: Block fails the gate, Warn passes it with a warning naming the policy, and Notify passes it and sends a notification. Policy conditions in the docs include severity, CVSS, EPSS and license. Exceptions go through a workflow with a business justification, an expiry date and an approver, recorded in the audit trail.

7. Triage the rest with exploitation data (vulnerability management, GA). The Vulnerabilities tab filters, including CISA KEV status and reachability, help decide which findings need a fix before launch and which need a VEX statement. They are triage filters, not gate conditions.

8. Generate the notices (license compliance, GA). In the Suppliers & Licenses tab, Export, Attribution Notice produces a TXT, HTML or Markdown file with component name and version, license type, copyright notices, license text where required and supplier information. The license compliance docs describe the generated set for redistributed artifacts as a NOTICE or THIRD-PARTY-NOTICES.txt file, a licenses/ directory and an SPDX document per release, and say there is no CLI command for generating these yet. Today this is an export your release process picks up, not a pipeline command.

9. Publish and share the SBOM (Portal, the SBOM publish and share product, GA). Publishing creates an immutable copy in Portal; sharing distributes that copy as-is. The sharing docs describe direct sharing by email with View, Download or Full permission, links with an expiry date, download limit and password, a branded customer portal under Settings, Customer Portal, access tracking and immediate revocation. The SBOM repository docs describe comparing two versions to see added and removed components and new or resolved vulnerabilities, a direct input to release notes.

10. Upload VEX (CSAF and VEX upload, GA). Under Integrations, filtered by Upload, the CSAF/VEX card accepts CSAF 2.0, CycloneDX VEX, OpenVEX and CSAF VEX profile files against a project name and version, so not-affected statements sit next to the findings they explain.

11. Fix what you can before release (autonomous remediation, GA, ships switched off with every category set to Manual). From a vulnerability, AI Remediate proposes the change and, once you review it, creates a pull request moving the dependency to a fixed version; bulk runs create one pull request per repository. Autonomous remediation ships switched off, with every category set to Manual.

12. Keep old releases visible. Each release version stays in the project with its SBOM. Scans run on the schedules you set, on a manual Rescan and in CI, so put supported versions on a schedule rather than assuming they update themselves.

Requirement, Safeguard, and what you still own

What stays with counsel and with the contract

Tools can find a GPL package in your image. They cannot decide your obligations. Before launch, counsel should answer:

• Is a given combination one program or an aggregate? The FSF calls that line a legal question. Dynamic linking, plugins and shared memory designs need a lawyer's read.
• Which source offer option will you use, and for how long? The choice shapes your release infrastructure and archive retention.
• What do warranties and indemnities say about open source? Enterprise customers often ask for a warranty that the product contains no copyleft code that would force disclosure of proprietary code. A license scan informs that answer; it does not make the promise.
• What do your support terms promise? Patch timelines for critical and KEV-listed vulnerabilities and end-of-support dates are contract terms your release process must be able to meet.
• Are there source-available or commercial components? Commercial SDKs licensed for SaaS use may not permit redistribution at all.

What Safeguard does not do

• It gives no legal advice. Safeguard identifies and classifies licenses and checks policies you write. It does not decide whether a combination is a derivative work, which source offer suits you, or what your contracts should say.
• License detection depends on the evidence available. Code copied into your repository without its license file or metadata, or a binary with no embedded license strings, may be missed or reported as unknown.
• It does not track which version each customer is running. Safeguard knows the versions you scanned and published, not what is installed in a customer's data centre or whether they applied your patch.
• It does not patch customer installations. You ship the fixed release; the customer owns scheduling and applying it.
• There is no CLI command for license reports or attribution yet. Notices come from an export in the app, so plan a step in your release process to pick them up.
• It does not write your source offer or host your source archives. Fulfilling GPL, LGPL and MPL source obligations is your release process.
• Policy outcomes for CI gates are off by default. --fail-on-gate needs them switched on for your workspace; the --fail-on severity gate works without them.
• KEV and reachability are triage filters, not gate conditions. Use them to decide what to fix or explain; enforce with severity and license policies.

Common mistakes

• Reviewing the repository instead of the image. The base image, runtimes and Dockerfile tools are where most GPL and LGPL packages in an image live.
• Reusing the SaaS license policy. A policy written for "nothing is distributed" waves through components that now carry source and notice duties.
• Assuming AGPL was the only license that mattered. On-prem, every copyleft license matters, and unmodified AGPL components now carry conveying duties.
• Stripping license files to shrink the image. Deleting /usr/share/doc removes copyright files for packages you still ship.
• Hand-written notice files. They go stale the first time a dependency changes.
• Offering upstream source instead of the source you shipped. If you patched a GPL component, the patched source is what you owe.
• Using the SaaS vulnerability bar for the release. "We will patch tomorrow" does not hold when tomorrow is the customer's next change window.
• No written support window. Without end-of-support dates, every old version stays your problem indefinitely.

FAQ

Does the GPL apply to SaaS?

Usually not to the hosted service. GPLv3 says network interaction with no transfer of a copy is not conveying, and the FSF's FAQ says a company running a modified GPL program on a website need not release the source. The AGPL's section 13 is the exception for modified versions.

Does shipping a Docker image count as distribution under the GPL?

Giving a copy of an image to another organization is a transfer of copies, which the FSF's FAQ treats as distribution. Every GPL program in the image, including base image packages, is conveyed, so its conditions apply.

Do we have to open source our application if our image contains GPL packages?

Not because they share an image. GPLv3 section 5 says an aggregate does not extend the GPL to its other parts. Linking or tightly combining your code with GPL code is a separate question for counsel.

Is AGPL a problem for a self-hosted edition if we never modified the component?

It can be. Section 13 reaches modified versions only, but once you distribute the component, its GPL-style conveying terms apply whether or not you changed it. Many vendors deny AGPL for distribution for that reason.

Where do we put third-party notices in a container image?

At a known path in the image, such as a licenses directory, alongside the base image's own copyright files, and on the release page. The OCI org.opencontainers.image.licenses annotation can carry an SPDX expression as a summary, not a replacement.

What SBOM should we give customers for an on-prem release?

One per release, generated from the built artifact, in SPDX or CycloneDX, meeting CISA's 2026 Minimum Elements, which add Component License and SBOM Generation Context among other new elements.

How long do we have to keep GPL source available?

For appliances or physical media, GPLv3 6(b) asks for a written offer valid for at least three years and as long as you offer support for that product model. For downloads, 6(d) asks you to keep source available as long as needed. GPLv2 section 3(b) says at least three years.

Should the release vulnerability gate be stricter than the SaaS gate?

In most cases, yes. A SaaS build can be replaced tomorrow; a released image may run unpatched until the customer's next change window.

How do we support customers who stay on old versions?

Publish a support window, keep each supported release's SBOM, re-scan on a schedule, and choose per finding between a patch release, a backport, a VEX statement or a required upgrade.

When the fix is not in the image yet

A self-hosted release turns every unfixed CVE in your image into something your customer's scanner reports and your support team has to answer. The options below are how you shrink that list before release day, and keep the fixed versions fixed in later releases.

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 is a real Safeguard CLI session. You install the CLI, run safeguard to open the interactive terminal and ask it to "fix the lodash CVE in this repo". It reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing; then it shows /permissions, /model and /scan . Before a self-hosted release, the same loop fixes dependency findings in your application layer so the rebuilt image meets the release gate.

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

The second demo sets up the local runner on your own machine, approves it with its device code, and then scans from the terminal. For a self-hosted edition, that is how a release engineer can check a candidate build locally before it reaches the CI gate.

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

Quick check

Start with the Safeguard CLI and the docs: download it from safeguard.sh/download and read the guides at docs.safeguard.sh/docs. For more on the license side, see the AGPL network clause and what it means for SaaS, open source license obligations for SaaS companies, the Apache 2.0 NOTICE file redistribution checklist and building an evidence bundle for a customer-hosted container or installer.

Sources

• GNU General Public License v3 (text)
• GNU General Public License v2 (text)
• GNU Affero General Public License v3 (text)
• GNU Lesser General Public License v3 (text)
• FSF, Frequently Asked Questions about the GNU Licenses
• Mozilla Public License 2.0
• Apache License, Version 2.0
• Apache Infrastructure, Assembling LICENSE and NOTICE files
• Open Source Initiative, The Open Source Definition
• SPDX License List
• SPDX Specification 3.0.1, Annex B: SPDX license expressions
• OCI Image Spec, Annotations
• OpenChain, ISO/IEC 5230 License Compliance
• NIST SP 800-218, Secure Software Development Framework v1.1
• NIST SP 800-218 (PDF)
• CISA, 2026 Minimum Elements for a Software Bill of Materials (SBOM)
• CISA, 2026 Minimum Elements for an SBOM (PDF)
• CISA, Minimum Requirements for Vulnerability Exploitability eXchange (VEX)
• CISA, BOD 26-04: Prioritizing Security Updates Based on Risk
• CycloneDX, Vulnerability Exploitability eXchange (VEX)
• Safeguard docs, License Compliance
• Safeguard docs, Suppliers & Licenses
• Safeguard docs, License Obligations
• Safeguard docs, Container images
• Safeguard docs, CI/CD Integration
• Safeguard docs, Generate SBOM
• Safeguard docs, Policies & Gates
• Safeguard docs, Policy outcomes and actions
• Safeguard docs, Vulnerabilities
• Safeguard docs, CSAF/VEX Upload
• Safeguard docs, AI Remediate
• Safeguard docs, Portal
• Safeguard docs, Portal Sharing
• Safeguard docs, Portal SBOM Repository
• Gold Open Source

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