Faster than the advisory

On April 30, around 1:22 p.m. ET, a patch for a nasty bug was applied to Argo CD, a popular GitOps controller. The bug allowed any logged-in user to read Kubernetes Secrets by making a routine diff request, which is not something you necessarily want in your production system.

Seventy-seven minutes after the update hit the release page, automation in the Chainguard Factory picked up the newly minted upstream, and the new version was merged in that evening. The argoproj security team published the repository-level advisory just before 10 p.m. Eastern. GitHub’s global advisory database — the feed your scanner watches — caught up on May 7, six days later.

For six days, the patched Argo CD was in Wolfi and Chainguard OS, while advisory-driven scanner workflows had no idea there was a bug to patch. The fix even arrived in Wolfi over 7 hours before the maintainer’s advisory.

It’s pretty cool when you can pull in a security fix before most automated advisory feeds even know there’s an issue, and in isolation, this case might seem like a bit of a fluke. But this situation, where the Chainguard Factory incorporates an upstream fix before the issue is public, happens more often than you’d think.

This situation, in which remediation precedes many (if not most) major disclosure milestones, is the result of Chainguard’s technical choices around Wolfi and Chainguard OS. These choices allow us to move incredibly fast to stay current with upstream maintainers and pull in fixes at automation speed. And this timeline-breaking speed is becoming increasingly important in a world of timeline-breaking models such as Anthropic’s Mythos.

Timeline fracture

It’s a year of crisis in the software security supply chain. Edgescan’s Vulnerability Statistics Report puts average remediation time for high- or critical-severity application/API vulnerabilities at 54.81 days. Mandiant, meanwhile, found that average time-to-exploit has continually decreased from 63 days in 2018 to an estimated -7 days in 2025 — meaning, on average, exploitation now happens a week before a patch is even released. In April, Anthropic’s report on Mythos described the next-generation model finding a remote crash bug in OpenBSD that had been sitting there for 27 years. If frontier models can find zero days in almost any software, then zero days can pop up anywhere, and disclosure timelines no longer apply.

Software security planning always relied on remediation timelines. Those timelines used to extend long enough for a security team to pace the work, set quarterly objectives, and reasonably expect to be ahead of the attacker on a given critical bug. In 2026, those smooth lines have become jagged. The 90-day window organizations assumed existed between disclosure and exploitation has evaporated and, in many cases, has been inverted.

Time is, like, not a thing anymore, man.

What is disclosure, anyway?

Security folks sometimes like to talk about “disclosure,” as in “the bug was fixed before disclosure,” like it’s a specific point in time. The earliest point that can reasonably be considered disclosure is when a maintainer or organization is informed of a security issue. However, disclosure can also refer to the process of informing other parties about an issue, often via advisory feeds. Considered in this way, the process of disclosure on a typical GitHub-hosted project can look something like this:

• The maintainer or organization is told, possibly by a security researcher or other interested party

• A repository-level advisory is posted on the project’s own security tab

• The project-level advisory is aggregated into the global GitHub Security Advisory database (GHSA) 

• The advisory is mirrored into the National Vulnerability Database (NVD), the NIST-maintained feed that many compliance frameworks watch

• Scanners pick up the new advisory from one or more of the above sources and register hits against the vulnerability

Different stakeholders are generally concerned with different points on this disclosure timeline. For example, many organizations only register a CVE when it appears in scanner results, which is when their patching workflow kicks in. A security researcher might be watching the project’s own security tab; an auditor might not register the bug until it lands in NVD. Each of these is the right event for that job, and there isn’t a single one of them that means “the world has been told.” Ultimately, though, for most organizations running automated tooling, GHSA aggregation is the event that matters in practice, since it’s when a bug enters the feed scanners read. (Throughout this post, when we say “GHSA,” we mean this global aggregation step, not the repo-level advisory, which confusingly shares the same identifier.)

So, how time-bending is Chainguard?

Chainguard’s role in this ecosystem is to closely track upstream fixes and pull them into Wolfi and Chainguard OS as quickly as possible. But how fast is fast, and does fast mean “before disclosure”?

In an analysis of all critical Go-ecosystem CVEs published from January 1, 2026, to May 20, 2026, where affected software was maintained in Wolfi, 16 of 29 (55%) of remediations were pulled into Wolfi before the CVE was published on GHSA. (Critical severity is based on GHSA’s own bar; remediation time is the merge commit timestamp in wolfi-dev/os; GHSA milestones the global advisory published_at field; all timestamps given in UTC.) A few highlights from this list:

1. Step-ca (Smallstep’s open source certificate authority), unauthenticated cert issuance via SCEP: pulled in 12 hours before GHSA.

2. Oauth2-proxy 7.15.2, an authentication bypass via X-Forwarded-Uri header spoofing, plus a sibling advisory in the same commit: pulled in 30 hours before GHSA.

3. Akuity’s Kargo, an authorization bypass in its batch resource API, was pulled in nearly 2 days before GHSA.

4. Filebrowser, a default-permissions misconfiguration that silently granted admin on signup: pulled in 2.4 days before GHSA, with the upstream cycle of two release tags and a repo advisory packed into a 90-minute window.

5. Rclone, an unauthenticated endpoint that allowed local command execution, plus a sibling advisory in the same commit, pulled in nearly 3 days before GHSA.

6. Argo CD 3.3.9, the Kubernetes Secret extraction bug we discussed above: pulled in 6 days before GHSA. 

7. Rancher’s Fleet, a Helm impersonation bug that retained cluster-admin during template rendering: pulled in 10 days before GHSA.

8. Rancher’s local-path-provisioner, which had a path-traversal bug in its pathPattern parameter, was pulled a full month before GHSA. 

One extreme outlier is not representative, but it is certainly fun to talk about. Kyverno is a widely used Kubernetes admission controller for policy enforcement. Wolfi pulled in a patched version remediating a policy bypass bug 424 days before the GHSA was published. This sounds heroic, but in this case, it was mostly because the CVE had been incidentally remediated in the code base before the vulnerability in prior versions was discovered by a researcher. The Chainguard Factory tracks upstream releases at machine speed, and security fixes routinely arrive as normal version bumps before advisory metadata catches up. This case also highlights that speed is critical not only for known vulnerabilities but also for as-yet-undisclosed zero days.

So, how quickly does Chainguard remediate CVEs? We’re fast enough that, in this specific dataset, we beat the GHSA publication more than half the time. Further, in 7 of those 16 pre-GHSA remediations, we also beat the repo-level advisory. That means we shipped the fix before the maintainer published information about the vulnerability on the repository level. That’s generally the first public indication, aside from a commit, that a vulnerability exists.

So does Chainguard pull in fixes before disclosure? If disclosure means publication on GHSA, then yes, we frequently have fixes pulled into Wolfi and Chainguard OS before GHSA publication. If you prefer disclosure to mean the stricter “published on the repository advisory feed,” then yes, we also frequently (though less often) pull in a fix before the repo-level advisory feed publishes information on a vulnerability.

You might be fast, but why does it matter?

The pre-Mythos world treated the gap between initial disclosure and scanner alert as mostly harmless, since disclosed vulnerabilities could only be exploited so quickly. Today, the window between when a maintainer ships a fix and when tooling learns of a vulnerability is exactly the window an AI-assisted attacker needs to find a related bug and weaponize it, or extrapolate a commit into a vulnerability still running in most production systems.

Where’s this all going? We now live in a world where zero days will come at us from unexpected angles. Maintainers running a preview of a model such as Mythos may reasonably choose to quietly fix and delay disclosure, knowing that most project consumers are likely to dally on old versions and that repo-level advisories can be quickly picked up by a growing cohort of attackers. As Mythos-level capabilities go more mainstream, the long tail of projects that frontier-grade AI has not yet hardened will be hustling to improve security.

In short, we’re dealing with two major issues, both of which mean it’s highly advisable to track upstream fixes closely. First, any gap between the upstream maintainer releasing a fix and that fix showing up in your production system is a gift to attackers. Second, zero days will be popping like mushrooms from unexpected locations. While closely tracking upstream isn’t a magic bullet, it’s sure as hell not a good idea to run on an OS that can't pull in maintainer fixes quickly. If you’re a high-value target, traveling at the speed of traditional distros ain’t going to cut it anymore.

Arm yourself

In this emerging world where red teams seem consistently faster and more sophisticated than expected, wouldn’t it be nice to run on infrastructure that’s also faster and more sophisticated than expected?

Based on our analysis, Chainguard frequently pulls in remediations before major machine-readable disclosure milestones — including the global GitHub Advisory Database publication and, in some cases, even the maintainer’s repo-level advisory. That’s not our explicit goal, simply a byproduct of our emphasis on speed and our ability to closely track upstream in our rolling distribution. If you’d like to learn more about how this speed is possible, check out our resources on the Chainguard Factory or learn about Driftless AF, our agentic framework for aligning where we are and where we want to go within the Factory.

See you soon. Probably before you expect. 😎