When Upstream Has No Fix: Safeguard Fork and Patch (Early Access)

When a vulnerable open source dependency has no fixed release, you have five honest options: mitigate it, isolate it, record that it does not affect you with a VEX statement, replace it, or patch it yourself. Safeguard adds a sixth for the packages it covers: request a Gold version from Open Source Manager, and Safeguard first tries to get the fix accepted upstream, then forks and patches only when the issue is severe or upstream will not move. That fork and patch flow is early access today, with limited package coverage, so treat it as one option in a plan you still own rather than the plan itself.

This post walks through what the regulations and disclosure standards expect while no fix exists, the options you have without a vendor, how the Safeguard flow works step by step, how to consume a forked build safely, and where the approach is the wrong answer. For the general mechanics of patching a dependency yourself, see fork and patch vulnerable packages; this post is about the decision and the Safeguard flow around it.

Key takeaways

• No fix is a normal state, not a failure. The EU Cyber Resilience Act, NIST SP 800-218 and the OpenSSF disclosure guide all expect a period where a vulnerability is known and a permanent fix is not yet available. What they ask for in that window is documented risk response, temporary mitigation and communication.
• The CRA asks manufacturers to push fixes upstream. Article 13(6) says that when you develop a fix for a vulnerable component, you share the code or documentation with whoever maintains it. A private fork that never goes upstream fits that badly.
• Safeguard Open Source Manager (OSM) is GA. It holds package security data, a Gold Directory and, in its Inventory view, the Request Gold and Source Gold actions.
• Requesting a Gold version of a package is early access. The buttons appear only if your plan includes them, and each request reaches Safeguard's team as a task.
• The OSM operating model behind Gold (inventory, patch upstream first, fork when necessary) is early access, and so is fork and patch itself. Safeguard does not publish a coverage list or a turnaround time.
• Gold Open Source (GA) at gold.safeguard.sh is free and needs no login. Its "Gold Certified" badge means Gold knows of no vulnerabilities in the indexed upstream version. It does not mean Safeguard rebuilt the package.
• Gold Registry (GA) is where hardened Gold artifacts are distributed, per Safeguard's offering.
• SCA, vulnerability management, reachability analysis, CSAF and VEX upload, license compliance, attestation and signing, policies and gates, and the CLI are GA. Autonomous remediation is GA and ships switched off, with every category set to Manual.
• A fork is a dependency you now own. Pin it, verify its provenance against the fork's source, track its license notices, and write down the date you expect to return to upstream.

What standards expect while no fix exists

Every rule about vulnerability handling recognises the gap before a patch ships. Read side by side, they tell you what an auditor or customer will expect you to have done during it.

The EU Cyber Resilience Act: Article 13 and Annex I Part II

Regulation (EU) 2024/2847, the Cyber Resilience Act (CRA), applies to manufacturers placing products with digital elements on the EU market. The European Commission's CRA page says the law entered into force on 10 December 2024, that reporting obligations apply from 11 September 2026, and that the main obligations apply from 11 December 2027. So as of this post, the Article 14 reporting duty already applies, and the rest of the vulnerability handling regime is just over a year away.

Four parts of the text matter when a component has no fix:

• Article 13(5) requires due diligence when integrating third party components so they do not compromise the product, and it explicitly includes free and open source components that were not placed on the market commercially. "Upstream is open source and unpaid" is not an exemption for the manufacturer that ships it.
• Article 13(6) says a manufacturer that identifies a vulnerability in an integrated component, including an open source component, shall report it to the person or entity maintaining that component and address and remediate it under Annex I Part II. If the manufacturer develops a software or hardware modification to fix it, the manufacturer shall share the relevant code or documentation with the maintainer, where appropriate in machine readable form.
• Article 13(8) requires vulnerabilities in the product, including its components, to be handled effectively for the whole support period, which is at least five years unless the product's expected use is shorter. It also requires policies and procedures, including coordinated vulnerability disclosure policies, to process and remediate reported vulnerabilities.
• Article 14(1) and 14(2) require a manufacturer to notify any actively exploited vulnerability in its product to the coordinating CSIRT and ENISA through the single reporting platform, with an early warning within 24 hours of becoming aware, a vulnerability notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available.

Annex I Part II then lists the vulnerability handling requirements. The ones that apply directly to a "no fix yet" situation are:

The CRA text was read from the Council's final adopted version (PE-CONS 100/23), because EUR-Lex blocks scripted access. Article and Annex numbering match the regulation as published.

The CRA never tells you to wait for the maintainer. Point (2) asks you to remediate without delay, and Article 13(6) assumes you might write the fix yourself and share it. That is the regulatory shape of "fork and patch, then send it upstream". If the vulnerable component is one you can show is not exploitable in your product, the VEX route covered in how VEX works in Safeguard is usually the lighter answer.

NIST SP 800-218 (SSDF): RV.2.2 and PW.4

The Secure Software Development Framework, NIST SP 800-218 version 1.1, puts the "no fix yet" case into two places.

RV.2.2, "Plan and implement risk responses for vulnerabilities", has an example that reads almost like a definition of this post: if a permanent mitigation is not yet available, determine how the vulnerability can be temporarily mitigated until it is, and add that temporary remediation to the plan. Another example under the same task covers releasing advisories that tell acquirers how to find the vulnerable software, what configuration settings may need to change and how temporary workarounds could be implemented. A third covers making a risk based decision to remediate, accept or transfer the risk.

PW.4.4, about verifying third party components through their life cycle, includes an example to regularly check for publicly known vulnerabilities that vendors have not yet fixed, and another to determine a plan of action for each component that is no longer maintained. PW.4.1 includes examples to host sanctioned and vetted open source components in your own repositories, to retain older component versions until transitions are complete, and to build binaries from source after verifying the source's integrity and provenance when an acquired binary's provenance cannot be confirmed.

Those last three examples are the practical skeleton of a safe fork: a controlled repository, a version you keep until migration is done, and a build you can trace back to verified source.

ISO/IEC 29147 and ISO/IEC 30111

The two ISO standards split the problem in half. ISO/IEC 29147:2018 is titled "Vulnerability disclosure" and covers how a vendor receives reports and publishes advisories. ISO/IEC 30111:2019 is titled "Vulnerability handling processes" and covers the internal work of investigating, remediating and following up. NIST's SSDF maps its RV.1.3 task, having a vulnerability disclosure and remediation policy, to the whole of both standards, and maps RV.2.2 to ISO/IEC 30111 clauses 7.1.4 and 7.1.5.

The ISO texts are paid documents and iso.org refused scripted access for this post, so the clause references here come from NIST's mapping. If an auditor asks for ISO/IEC 30111 alignment specifically, read the clauses yourself.

The OpenSSF guide to coordinated vulnerability disclosure

The OpenSSF "Guide to implementing a coordinated vulnerability disclosure process for open source projects" is written for maintainers, so it describes what happens on the other side when you report a bug upstream and wait:

• Embargo periods vary. The guide notes that CERT/CC discloses 45 days after a report even if no fix is available, with exceptions, and that 90 days is the longest default embargo that various groups entertain. Policy timeframes are a starting point for negotiation, not a hard deadline.
• A maintainer is advised to make the fix easy to adopt, ideally a simple update that does not force a different API or remove functionality. When that is not possible, the guide says to look for mitigations users can apply without the change.
• If a vulnerability is already publicly known and widely exploited, the guide says there is no advantage to keeping fix development private.

A small project may take weeks to ship, may decide the fix needs a breaking change, or may not respond at all. Your plan needs to work in each case.

CISA coordinated vulnerability disclosure and VEX guidance

CISA's Coordinated Vulnerability Disclosure program coordinates reporting, analysis and disclosure across reporters, manufacturers, maintainers and users, aiming to get information and any available mitigations to everyone at once, and CISA acts as a CVE Numbering Authority of last resort for reports it receives. If a maintainer is unreachable and the component matters to critical infrastructure, a CVD coordinator is a legitimate escalation path.

CISA's VEX documents give you the vocabulary for the interim period. "Minimum Requirements for Vulnerability Exploitability eXchange (VEX)", published April 2023, defines four statuses: not affected, affected, fixed and under investigation. For "affected", a VEX statement must include an action statement that should describe how to remediate or mitigate. For "not affected", it must carry either a justification or an impact statement. The earlier "VEX Use Cases" paper (April 2022) describes VEX as a machine readable security advisory. "No fix exists" is not the same as "affected", and a VEX statement is how you say which is true for your product and what to do meanwhile.

Your options when there is no vendor fix

Before reaching for a fork, it helps to lay out every option and its real cost. Most teams end up combining two or three.

A few notes on how each goes wrong.

Mitigation is the SSDF's RV.2.2 answer and usually the fastest. Its weakness is that it is invisible to scanners. Your SCA results will still show the CVE, so you need a VEX statement or a documented exception to stop the finding from being re-raised every week.

Accepting with VEX is the right answer far more often than teams expect. CycloneDX gives you the analysis states not_affected, exploitable, in_triage, false_positive, resolved and resolved_with_pedigree, and justifications such as code_not_reachable, requires_configuration and protected_by_mitigating_control. OpenVEX uses the four CISA statuses and requires a justification for not_affected. Reachability evidence is what makes such a statement defensible.

Replacing is the most permanent fix and the most underrated. If upstream has been silent for a year, the vulnerability is a symptom; the real finding is an unmaintained dependency, which is exactly what SSDF PW.4.4 asks you to plan for.

Patching locally is the option most people mean by "fork". CycloneDX records this explicitly: a component's pedigree can carry patches typed as unofficial (not developed by the maintainers), backport, cherry-pick or monkey, and the analysis state resolved_with_pedigree exists for the case where a fix was applied through such a patch.

Requesting a Gold version hands the patching work to Safeguard for packages it covers. It is the newest option on this list, and the rest of this post explains how it works and where it stops.

How Safeguard handles a package with no upstream fix

Safeguard's flow combines GA capabilities that find and prioritise the problem with an early access capability that produces a fixed build.

The parts that are GA

• SCA and deep transitive dependency scanning (GA) resolve your dependency graph from manifests and lockfiles and match each package and version against advisories. Safeguard's SCA docs say each finding carries the vulnerable component and version, the advisory identifiers, severity with EPSS and KEV context, the full transitive path from your project root, the reachability verdict where available, and the safe upgrade target. When there is no safe upgrade target, that absence is itself the signal you are in the situation this post covers.
• Vulnerability management (GA) enriches findings with EPSS and CISA KEV, so a no-fix vulnerability that is being exploited rises above one that is not.
• Reachability analysis (GA) tells you whether your code calls the vulnerable function. Safeguard's docs say it cuts CVE noise by 60 to 80%; treat that as Safeguard's stated figure, not a promise for your codebase. Some language support in reachability is marked Preview in the docs. A reachable, exploited, no-fix vulnerability is a fork candidate; an unreachable one is usually a VEX candidate.
• Open Source Manager (GA) gives you per package detail: an attestation score (LCAL, 0 to 4), a risk score, known vulnerabilities with CVSS, EPSS, a fix available indicator and affected versions, an Attestation tab, a Dependencies tab, and a Versions tab with a recommended version indicator. OSM search covers npm, PyPI, Maven, Go, RubyGems, NuGet, Cargo and Packagist.
• Gold Open Source (GA) at gold.safeguard.sh is free and needs no login. Every CVE page has an "Am I affected?" check for the version you run, and every package page with known vulnerabilities shows a recommended safe version where one exists.
• CSAF and VEX upload (GA) lets you bring VEX statements into the platform. The CLI's safeguard validate command checks CycloneDX, SPDX and VEX (CSAF and OpenVEX) documents against their specifications.
• Policies and gates (GA) decide what is allowed to ship, which is how you stop a vulnerable version, or an unapproved fork, from coming back.

The parts that are early access

• Requesting a Gold version from OSM (early access). Safeguard's Gold docs describe Request Gold, Source Gold and Request Premium Gold actions in Open Source Manager › Inventory. Each request reaches Safeguard's team as a task to source a Gold version for that package. The actions appear only if your plan includes them.
• The OSM operating model (early access). Per Safeguard's offering, this is how hardened packages get made: OSM holds your open source inventory and identifies packages that could be replaced with hardened Safeguard equivalents; when a package carries vulnerabilities, Safeguard attempts to patch upstream first; if the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build. Resulting packages are held to no critical or high vulnerabilities and a completed license check. Projects and products scanned in the main platform can be pulled into OSM for open source analysis.
• Fork and patch (early access). The fork step itself. Safeguard's own OSM product page describes Safeguard fixed Gold components as rolling out in early access.

What "Gold" means in each place

The word Gold is used for three related things, and mixing them up causes real mistakes.

So a "Gold Certified" badge on a public upstream release tells you nothing about a fork. Only a Gold build delivered through your request is the patched artifact. Read the evidence for the exact artifact you install; how the Gold Registry works explains what that evidence covers.

Step by step: request a Gold version of a vulnerable package and track it

This walkthrough uses only screens and commands that Safeguard's docs show.

1. Find every place the package lives. Scan the repository, image or SBOM. From the command line, safeguard scan builds an SBOM for one target and writes results as JSON under ./output:

   safeguard login
   safeguard scan --dir .
   safeguard scan --image myregistry.azurecr.io/myapp:v1 \
     --registry-username "$REGISTRY_USER" \
     --registry-password "$REGISTRY_PASSWORD"
   safeguard scan --sbom sbom.json
   

   Results include vuln.json, license.json and collection.json. To see results in the platform beside your other projects, the CLI docs say to scan from the interactive terminal while signed in: run safeguard, type /login, then /scan .. The runner uploads the SBOM and findings, never your source. Note that safeguard scan exits 0 whatever it finds; gating on findings happens in platform policy gates.

2. Confirm that no fix exists, rather than assuming it. Look the CVE up on gold.safeguard.sh and use "Am I affected?" with the version you run. In OSM, the package's Vulnerabilities tab shows a fix available indicator and the Versions tab shows a recommended version. If a fixed version exists, you are not in a fork situation: let autonomous remediation (GA, ships off) open the upgrade pull request, or upgrade by hand.

3. Decide whether it matters for you. Check reachability, EPSS and KEV on the finding. If your code does not reach the vulnerable function and the vulnerability is not exploited, a VEX statement plus monitoring is often the proportionate answer, and you can stop here.

4. Report it upstream, or confirm someone has. CRA Article 13(6) and Annex I Part II point (6) both point you at the maintainer. Use the project's security policy (often a SECURITY.md file) and keep the thread. If the maintainer has already published an advisory and is working on a fix, note the expected timing; it changes whether a fork is worth it.

5. Open Open Source Manager › Inventory. This is where Safeguard's Gold docs place the request actions.

6. Request one package. Select Request Gold on the package's row. Safeguard confirms with Gold Request Submitted, and the row then shows Gold Requested. The docs note that this marker is kept in your browser, so a different browser or a cleared profile will not show it. Record the request in your own tracker too.

7. Or request every vulnerable package at once. Select Source Gold above the table, review the packages and the risks listed, then select Submit Request. The docs say Request Premium Gold works the same way for Premium Gold versions; the docs do not describe what Premium adds, so ask before choosing it. If none of these actions appear, your plan does not include them; the docs say to ask your Safeguard administrator.

8. Watch the package while you wait. In OSM, open the package details and select + Add to Watchlist, then set notification preferences. The OSM user guide lists options for a new vulnerability, critical only, a new version and maintenance status changes. "New Version" is the one that tells you upstream finally shipped.

9. Publish your interim position. If you ship software to others, write a VEX statement now. For "affected", include the action statement your users should follow (the mitigation from your plan). Validate it before you publish or upload it:

   safeguard validate vex.json --strict -o report.json
   

10. Receive and verify the build. When Safeguard's team delivers a Gold build for your request, treat it as a new dependency: pin it, verify its provenance against the fork's source, rescan, and run your tests. The next section shows how.

11. Close the loop. Update your VEX statement to fixed for the versions that carry the patched build, or, in CycloneDX terms, resolved_with_pedigree with the patch recorded in the component's pedigree. Set a review date to check whether upstream has shipped.

Safeguard's public docs do not show a request status page, an SLA or a delivery notification for Gold requests, so do not plan around one. Ask your Safeguard contact how delivery is communicated for your account.

How to consume a forked Gold build safely

A fork, from anyone, is a change of supplier for that component. The controls that keep it safe are the same ones the SSDF and SLSA describe for any third party component.

Pin exactly, at the root

Pin the forked version exactly and do it in the place your package manager actually honours.

For npm, overrides replace a package anywhere in your dependency tree with another version or another package entirely. The npm docs are clear that overrides are only considered in the root package.json; overrides inside installed dependencies are ignored. A minimal form looks like this, with placeholders for the name and version you were given:

{
  "overrides": {
    "vulnerable-package": "npm:@your-gold-scope/vulnerable-package@1.2.3-gold.1"
  }
}

The scope, name and version string here are illustrative. Use exactly the coordinates Safeguard gives you for your build; do not guess them.

For Go, a replace directive points a module path and version at another module or a local directory. The Go modules reference says replace directives apply only in the main module's go.mod and are ignored in dependencies, which is the same lesson as npm: the pin belongs in the top level project.

replace example.com/vulnerable/module v1.4.0 => example.com/your-fork/module v1.4.0-patched.1

Commit the lockfile after the change so CI resolves the same thing your laptop did.

Point resolution at the registry deliberately

Safeguard's Gold docs show the pattern for scoped npm packages from registry.safeguard.sh: map the scope in .npmrc so only that scope resolves there.

# .npmrc
@safeguard-sh:registry=https://registry.safeguard.sh/npm/

The same docs carry a warning worth repeating: @safeguard-sh is Safeguard's own npm scope, and a similarly named scope on the public registry belongs to someone else. Scope confusion is how a pinned fork gets silently replaced by a lookalike. Map scopes explicitly and review .npmrc changes like code.

Check provenance against the fork, not upstream

SLSA's "Verifying artifacts" guidance (SLSA 1.2) says verification should confirm the builder identity is one you trust at a given SLSA level, verify the signature on the provenance, and check that the provenance matches expected values. One of the expected values SLSA lists is the canonical source repository, specifically to stop someone building from an unofficial fork.

That is the subtle part of consuming a fork. Your verification policy for this component must now expect the fork's source repository and builder, not upstream's, and only for the forked versions. Change that expectation on purpose and record why. If your policy simply accepts any source for this package, you have disabled the check that would catch a malicious fork.

For npm packages, npm audit signatures verifies registry signatures on what you installed, and errors when a registry that supports signatures serves a package without one. Safeguard's attestation and signing capability (GA) covers SLSA, Sigstore and in-toto, and OSM's Attestation tab shows provenance verification status, signature verification and SLSA level per package.

Rescan and gate

Run the same scan you ran in step 1 against the patched build. The finding should clear, and nothing new should appear. Then add a policy gate (GA) so the vulnerable upstream version cannot be reintroduced by a transitive update or a revert. Safeguard's Gold scan also has a command line form you can run in hooks or any CI system; it fails on actively exploited vulnerabilities by default:

npx @safeguard-sh/gold-scan . --fail-on vuln

Safeguard's Gold Open Source docs note that the GitHub Action form of this check is not yet on the Marketplace, and show the command line form as available now.

Plan the return to upstream

Write down, at the moment you adopt the fork, what will end it. Usually that is "upstream releases a version that includes an equivalent fix". SSDF PW.4.1 suggests retaining older component versions until transitions are complete, and the same logic runs in reverse: keep the fork pinned until the upstream fixed version has passed your tests, then remove the override and the registry mapping in one reviewed change. The OSM watchlist's new version alert is the trigger.

Licensing and maintenance implications of running a fork

Patching an open source package does not change its license, but it does change your obligations, and it creates a maintenance tail that is easy to underestimate.

License obligations follow the code

Most open source licenses attach conditions to distributing modified versions.

• The Apache License 2.0, Section 4, requires that modified files carry prominent notices stating that you changed them, that you keep the copyright, patent, trademark and attribution notices, and that you pass on the attribution notices in any NOTICE file.
• The GNU GPL version 3, Section 5(a), requires a modified work to carry prominent notices stating that you modified it, with a relevant date, and Section 6 requires that object code be conveyed with the corresponding source in one of the ways the license lists.

When Safeguard produces a Gold build, the Gold bar includes a completed license check. When you ship a product containing that build, the distribution obligations are yours. Safeguard's license compliance (GA) parses SPDX expressions, classifies licenses from permissive to network copyleft, applies license policy and generates NOTICE and attribution files, which helps you meet those obligations; it does not decide them for you. If the fork is of a strong copyleft package that you distribute, involve whoever owns open source compliance before you ship.

Maintenance is the hidden cost

Every fork drifts: each upstream change widens the gap between what you run and what everyone else runs, and the OpenSSF guide notes how hard private forks are to keep current. Three habits keep the drift small:

• Keep the patch minimal. One vulnerability, one change. Resist folding in unrelated fixes, because each one makes the eventual return to upstream harder.
• Record the patch. CycloneDX pedigree with a patch of type unofficial, and a resolved_with_pedigree analysis state, gives downstream consumers and auditors a machine readable record of exactly what differs from upstream.
• Share the fix. CRA Article 13(6) expects it for manufacturers, and it is also the cheapest way to end the fork: once upstream merges an equivalent fix, you can go back.

Safeguard's operating model puts the upstream attempt first for the same reason. A fix that lands upstream helps everyone and ends everyone's fork. The maintainer's side of that relationship is covered in open source maintainers and Safeguard Gold.

Which packages and ecosystems early access covers, and how to ask

Safeguard does not publish a list of packages that fork and patch covers today, and this post will not guess one. What is documented:

• OSM search and package detail cover npm, PyPI, Maven, Go, RubyGems, NuGet, Cargo and Packagist. That is where you can see a package and, if your plan includes it, request Gold for it. Being searchable is not the same as being covered by fork and patch.
• Gold Open Source covers packages across 20 or more ecosystems as public intelligence. Again, that is lookup coverage, not patch coverage.
• The Request Gold, Source Gold and Request Premium Gold actions appear only if your plan includes them.

To ask, use the Request Gold action if you have it, or contact your Safeguard administrator or account team with the package name, ecosystem, version you run, the CVE or advisory, and whether the vulnerable code is reachable in your product. Ask three questions before you plan around the answer: is this package covered, what will you deliver (a patched version, or a recommendation to replace), and how will delivery be communicated. Safeguard has not published turnaround times or how fork and patch work is billed, so get those answers in writing for your account rather than assuming.

When fork and patch is the wrong answer

A fork is the heaviest tool on the table. It is the wrong one in more cases than it is the right one.

• The vulnerable code is not reachable. If reachability shows you do not call the vulnerable function, and the vulnerability is not on CISA KEV, a VEX statement with the code_not_reachable justification plus a watchlist entry is proportionate. A fork adds supply chain risk to remove a risk you do not have.
• The code is closed. Safeguard cannot patch a vendor's proprietary library, a hosted service, an appliance's firmware or an operating system runtime you do not build. The fix there has to come from the vendor or distribution; your options are mitigation, isolation and pressure through your supplier contract.
• The package is abandoned and a healthy alternative exists. Forking an unmaintained package means you, or someone you pay, maintain it indefinitely. Replacing it ends the problem.
• The fix needs a breaking change. If closing the vulnerability requires changing the package's API, a fork that preserves compatibility may not be possible, and a fork that breaks compatibility is a migration in disguise.
• Upstream is about to ship. If the maintainer has confirmed a fix and a release date inside your risk tolerance, mitigate and wait. A fork for a week is churn.
• You cannot verify what you receive. If your pipeline cannot pin by exact version, check provenance and gate on it, adopting any fork, including a Gold build, moves risk rather than removing it. Fix the pipeline first.
• Contract or certification requires vendor supported components. Some regulated deployments require components supported by their original supplier. Check before you substitute.

What Safeguard does not do

• It does not promise coverage. Fork and patch is early access with limited package coverage, and Safeguard does not publish which packages it covers. A request is a request, not a guarantee of a patched build.
• It does not promise turnaround or quote per fix costs. Safeguard's public material does not state an SLA for Gold requests, and the per fix billing model is not confirmed as live. Do not put a delivery date for a Gold build into a customer commitment until your account team has given you one in writing.
• It does not patch closed vendor code. Proprietary libraries, hosted services, vendor appliances and operating system runtimes you do not build are outside fork and patch. The fix has to come from that vendor or distribution.
• It does not replace your review. A Gold build is a change to your software. You still read the patch summary, run your tests, check provenance against the fork's source and decide whether to ship it.
• The Gold Certified badge is not a fork. On gold.safeguard.sh, Gold Certified means no known vulnerabilities in the indexed upstream version. Safeguard's docs state that Gold does not rebuild, sign or attest those public components.
• It does not track your request for you everywhere. The Gold Requested marker in OSM Inventory is kept in your browser, per the docs. Keep your own record.
• It does not file your regulatory reports. CRA Article 14 notifications to the CSIRT and ENISA, your coordinated vulnerability disclosure policy and your customer advisories are your obligations as the manufacturer. Safeguard gives you the inventory, findings and VEX tooling that feed them.
• It does not decide that you are not affected. Reachability evidence supports a "not affected" VEX statement; the justification and the accountability for it stay with you.

Common mistakes

• Treating "no fix available" as "nothing to do". The SSDF's RV.2.2 and the CRA's Annex I Part II both expect a risk response and a temporary mitigation during the gap.
• Reading a Gold Certified badge as a patched build. The badge describes the upstream release. Only a delivered Gold build for your request is a patched artifact.
• Pinning a fork in the wrong file. npm overrides and Go replace directives only work in the root project. A pin inside a nested package or workspace is silently ignored.
• Loosening provenance checks to make the fork pass. Change the expected source repository for the forked versions only, and record why. Do not turn the check off for the package.
• Forgetting the scope mapping. A scoped package without an explicit .npmrc scope mapping may resolve from the public registry, where a lookalike scope can live.
• Keeping the fix private. Not sharing the patch upstream makes the fork permanent and, for a manufacturer under the CRA, sits badly with Article 13(6).
• Leaving the VEX statement stale. "Affected, mitigate by X" has to become "fixed" or resolved_with_pedigree when the build lands, and has to be revisited when you return to upstream.
• No exit plan. A fork without a written end condition becomes a permanent dependency nobody owns.

FAQ

What should I do when a CVE has no patch available?

Confirm no fixed version exists, check reachability and exploitation, then mitigate, isolate, replace, publish a VEX statement or patch. Report it upstream if nobody has, and record the decision with a review date, as NIST SP 800-218 RV.2.2 suggests.

Does the Cyber Resilience Act require me to patch open source components myself?

The CRA requires manufacturers to remediate vulnerabilities in their products without delay, including in integrated open source components, and to report component vulnerabilities to the maintainer. Article 13(6) says that if you develop a fix, you share it with the maintainer. It does not dictate that you fork, but it does not let you wait indefinitely either.

What is Safeguard fork and patch?

An early access part of Safeguard's Open Source Manager operating model. Safeguard first tries to get the fix accepted upstream; if the issue is severe or upstream will not move, it forks the package, fixes it and publishes a hardened Gold build.

How do I request a Gold version of a package in Safeguard?

Open Open Source Manager › Inventory and select Request Gold on the package's row, or Source Gold above the table to request every vulnerable package at once. The actions appear only if your plan includes them, and requesting is early access.

Is a Gold Certified package on gold.safeguard.sh a patched fork?

No. On Gold Open Source, Gold Certified means Gold knows of no vulnerabilities in the indexed upstream version and the package is not deprecated. Safeguard's docs state that Gold does not rebuild, sign or attest those components.

How long does a Safeguard Gold request take?

Safeguard has not published a turnaround time for Gold requests or fork and patch. Ask your account team for your account's terms and do not commit a date to customers until you have one in writing.

Can I use a VEX statement instead of patching?

Yes, when it is true. If the vulnerable code is not in your product, not reachable, or blocked by a mitigation, a "not affected" statement with a justification is the standard way to say so. If you are affected but have a workaround, an "affected" statement must carry an action statement describing the mitigation, per CISA's minimum requirements for VEX.

How do I safely install a forked npm package?

Pin it with overrides in the root package.json, map its scope in .npmrc, commit the lockfile, verify provenance against the fork's source, rescan, and gate against the vulnerable upstream version.

Does forking an open source package change its license?

No, but distributing a modified version usually triggers conditions, such as the modification notices required by Apache 2.0 Section 4 and GPL version 3 Section 5.

Can Safeguard patch a vulnerability in a commercial library or SaaS product?

No. Fork and patch covers open source packages Safeguard can build. Proprietary libraries, hosted services, vendor appliances and operating system runtimes you do not build need a fix from their vendor or distribution.

Both gaps, one plan

Everything above is about the second gap: the time before any fix exists. The section below is Safeguard's standard summary of how it closes both gaps, and its fork and patch paragraph is the same early access flow this post has walked through in detail.

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 covers eight categories, including dependencies, licenses, security posture and findings. 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. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

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

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature 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. This fork and patch flow is in early access today, so 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

Neither demo below shows a fork being built; fork and patch happens on Safeguard's side and is early access. They show the parts of this workflow you run yourself: finding the vulnerable package, changing a dependency with approval at each step, and testing the result.

The first demo is a real CLI session. You install the CLI, run safeguard to open the interactive terminal and ask it to fix the lodash CVE in a repository; it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. When a Gold build arrives for a package with no upstream fix, the same flow applies: you ask the assistant to pin the build you were given, and it asks before each edit and each command.

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

The second demo is a real desktop app session, which is early access (beta). The CLI session shows in the desktop app's conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with the upgrade done and tests passing. For a forked dependency, that per step approval is where a reviewer checks the override, the scope mapping and the test run before anything is committed.

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

To try the flow on your own dependencies, get the CLI and apps from safeguard.sh/download and read the full documentation at docs.safeguard.sh/docs.

Quick check

Sources

• Regulation (EU) 2024/2847, Cyber Resilience Act, final adopted text (Council PE-CONS 100/23)
• European Commission: Cyber Resilience Act policy page
• NIST SP 800-218, Secure Software Development Framework v1.1
• NIST SP 800-218 full text (PDF)
• OpenSSF: Guide to implementing a coordinated vulnerability disclosure process for open source projects
• CISA: Coordinated Vulnerability Disclosure Program
• CISA: Minimum Requirements for Vulnerability Exploitability eXchange (VEX), April 2023
• CISA: VEX Use Cases, April 2022
• CycloneDX: Vulnerability Exploitability eXchange
• CycloneDX 1.6 JSON schema (pedigree, patch types, analysis states)
• OpenVEX specification
• SLSA 1.2: Verifying artifacts
• npm Docs: package.json overrides
• npm Docs: Verifying registry signatures
• Go Modules Reference: replace directive
• Apache License, Version 2.0
• GNU General Public License, version 3
• Safeguard Docs: Gold (Requesting a Gold version in Safeguard)
• Safeguard Docs: Gold Open Source
• Safeguard Docs: Open Source Manager
• Safeguard Docs: Open Source Manager user guide
• Safeguard Docs: OSM security database
• Safeguard Docs: Software Composition Analysis
• Safeguard Docs: CLI usage
• Safeguard: Open Source Manager product page
• Gold Open Source

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