A one page brief from Safeguard. October 2026.
Read the full paper: Fixing Open Source at the Source: The Case for Continuously Verified Components Before January 2027 (PDF, 6 pages), by Hritik Kumar, Safeguard.sh Inc. It sets out the argument below in full, with 18 references.
The problem in one paragraph
Almost every application now ships more open source code than code its own team wrote, and most of that code arrives as dependencies nobody on the team chose directly. When a flaw is found in one of those components, the fix depends on a volunteer maintainer, a release schedule and then thousands of downstream teams noticing and upgrading. Log4Shell showed how long that chain can take: CISA's guidance urged organisations to find and patch every affected system, and many spent months doing it. The xz Utils backdoor (CVE-2024-3094) showed the other risk: a trusted component can be compromised at the source. CISA's Known Exploited Vulnerabilities catalog keeps growing, and many of its entries sit in widely shared libraries and images.
Why the clock matters now
Regulation has moved from guidance to deadlines. Under the EU Cyber Resilience Act, Regulation (EU) 2024/2847, manufacturers of products with digital elements have had to report actively exploited vulnerabilities since 11 September 2026: an early warning within 24 hours and a notification within 72 hours, as Ireland's national cyber security centre summarises. Most of the Act's other obligations apply from 11 December 2027. A team that cannot say which open source components it ships, and which of them are vulnerable, cannot meet a 24 hour clock.
That is why we have set ourselves a goal: help our customers fix the open source they depend on before January 2027. That leaves most of a year to clean up the backlog before the Act's main obligations apply in December 2027. It is a goal and not a promise about any single package. The rest of this page explains how we are working toward it.
What "fixed" should mean
A fixed component is not simply the newest version. We hold Gold components to a stricter bar, and we keep holding them to it:
| The Gold bar | Why it matters |
|---|---|
| Zero exploitable critical or high CVEs | Removes the findings auditors and attackers both look at first |
| A completed license check | Avoids shipping obligations you did not plan for |
| SLSA L3 or higher provenance and a Sigstore signature | Lets you prove where the artifact came from and that it was not altered |
| A public evidence page per artifact | Gives an auditor something concrete to check |
| Continuous monitoring | An artifact loses its Gold badge if it regresses |
How Gold works
Gold Open Source (gold.safeguard.sh) is free and needs no login. Search a package or a CVE 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 badges, RSS feeds and the safeguard-sh/gold-scan-action GitHub Action, which can fail a build on a known exploited vulnerability.
Gold Registry provides hardened, drop in replacements for upstream packages and container images that meet the bar above. Teams can point their own package directory at it, so hardened equivalents resolve without changing how developers install anything. Both Gold offerings are generally available.
When upstream has no fix, we first work to get the fix accepted upstream, because a fix at the source helps everyone. If the issue is severe or upstream will not move, we build a fork, fix the vulnerability there and publish a hardened Gold build. That fork and patch flow is in early access today, so ask which packages it covers before you plan around it.
Fix it without waiting for upstream
Most open source risk sits in two gaps: the time between a fix being published and that fix reaching your production builds, and the time before any fix exists at all. Three habits close both:
- Know what you ship. Generate an SBOM for every build, so a new advisory becomes a lookup rather than a search.
- Move to the safe version automatically. Safeguard's autonomous remediation opens tested, policy gated pull requests to the fixed version. It ships switched off, so your team decides how much runs on its own.
- Start from components that are already fixed. Pull from Gold Registry for new work, and use Gold Open Source in CI so a vulnerable version cannot quietly return.
One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system you do not build yourself, the fix still has to come from that vendor. Gold covers the open source dependencies and container images you build and ship.
What to do this quarter
- Look up your top twenty dependencies on gold.safeguard.sh today. It is free.
- Add the Gold scan action to one pipeline, set to fail on known exploited vulnerabilities.
- Produce an SBOM for each product you ship into the EU, and map who reports to ENISA if a component is actively exploited.
- Talk to us about moving your most used packages and base images to Gold before January 2027.
See it working
Click through it at your own pace, or open it full screen.
Sources
- Full paper: Fixing Open Source at the Source (PDF)
- Regulation (EU) 2024/2847, the Cyber Resilience Act (EUR-Lex)
- National Cyber Security Centre Ireland: EU Cyber Resilience Act
- CISA: Reported supply chain compromise affecting XZ Utils, CVE-2024-3094 (29 March 2024)
- CISA: Apache Log4j vulnerability guidance
- CISA: Known Exploited Vulnerabilities catalog
- Gold Open Source
