A vulnerability scanner can only tell you what its underlying intelligence knows. That creates a gap that is easy to miss in modern software supply chains: a security fix can exist in upstream source before a public vulnerability record appears, and a fixed release can be available before downstream systems recognize that they need to consume it. The reverse can also happen. A newly published upstream release can itself be compromised before automated systems have had enough time to establish whether it is safe.
Consider OpenSSH's regreSSHion vulnerability, later assigned CVE-2024-6387. Researchers contacted the OpenSSH developers in May 2024, and successive iterations of the security fix followed before the coordinated public disclosure on July 1. The OpenSSH security advisory documents the disclosure and remediation timeline. The important point is not simply that OpenSSH had a vulnerability. It is that remediation activity was already taking place upstream before the vulnerability became a public CVE record.
The Go project provides an even more concrete example from the downstream consumer's perspective. Go 1.24.4 was released on June 5, 2025, with security fixes including a fix for the issue later published as CVE-2025-22874. The official Go release history records the June 5 release, while the Go vulnerability record for CVE-2025-22874 shows the public vulnerability record appearing on June 11. The fixed software therefore existed as a released upstream version before the vulnerability appeared in the public vulnerability record.
Neither example represents a failure of responsible disclosure. In coordinated vulnerability disclosure, it is normal for maintainers and researchers to work privately before making an issue public. What these examples demonstrate is that a security fix and a public vulnerability record are separate events, and they do not necessarily happen at the same time.
That distinction matters when the downstream security process is built primarily around vulnerability databases.
Why patching when the CVE lands is incomplete
The conventional vulnerability-management workflow is straightforward. A vulnerability is disclosed, a CVE is published, vulnerability intelligence is updated, scanners identify affected software, and remediation begins. This workflow is necessary for managing known vulnerabilities at scale, but it is inherently reactive because the vulnerability record becomes the trigger for action.
The underlying software, however, does not wait for a CVE. Code changes upstream, maintainers publish new releases, and package repositories begin serving new versions independently of when a vulnerability database is updated.
The Linux kernel provides a useful example of how these processes can be separated. The Linux kernel's CVE documentation describes CVE assignment as a process associated with fixes already available in released kernel trees and notes that CVEs are not automatically assigned to unfixed security issues. The kernel security-bug documentation also makes clear that patch inclusion should not be delayed while waiting for a CVE identifier.
This means the software development and remediation process can move before the vulnerability-management system has a CVE to consume. CVE data remains an important source of security intelligence, but it should not necessarily be the only signal that causes an organization to examine or rebuild the software it consumes.
If a remediation process starts only when a vulnerability record appears, it necessarily introduces a dependency on the speed and completeness of vulnerability disclosure. If the process can also respond to upstream software changes, it can begin evaluating the change at the point where the software itself changes.
That moves the security process earlier in the supply chain.
The mechanism: the trigger is an upstream release, not a CVE record
This is where the build model becomes important.
CleanStart images are not assembled by simply taking upstream binary packages and placing them into a smaller container. Packages are rebuilt from source through a controlled, hermetic build environment. The resulting image can then be associated with its source, build process, provenance, and resulting software inventory.
That changes what can trigger a rebuild.
In a vulnerability-driven model, the sequence generally begins with a vulnerability database update. A scanner identifies an affected package or image, the issue is prioritized, a fixed version is selected, and the resulting artifact is rebuilt and tested.
A source-driven model can begin one step earlier. An upstream release or source change becomes a signal for examination. The source can be evaluated, the package can be rebuilt through the controlled build process, and the resulting artifact can go through verification before it is made available for consumption.
The difference is important because an upstream release is the earliest observable event that tells a downstream producer that the software has changed. A CVE may arrive later, and sometimes much later. A scanner cannot identify information that does not yet exist in the vulnerability intelligence it consumes.
This does not mean that every upstream change represents a security fix. Most upstream changes do not. It means that an upstream change can be treated as a signal worth evaluating rather than waiting for someone else to classify that change as a vulnerability first.
The lag between upstream and downstream matters
Once upstream software changes, another question becomes important: how long does it take for that change to become available in the software artifacts that organizations actually consume?
That lag can be measured. For a package or image, compare the upstream release date with the version incorporated into the downstream artifact and the date on which that artifact was rebuilt. It is also useful to determine whether the upstream change was associated with a published vulnerability record at the time it occurred.
The resulting gap tells you something that a conventional vulnerability scan does not.
An image can be completely clean according to its scanner and still be behind the current upstream release. That does not automatically make the image vulnerable. The newer release may contain a bug fix, performance improvement, feature, or unrelated change. The scanner's clean result simply answers a narrower question: whether the artifact contains vulnerabilities represented in the intelligence available to the scanner.
It does not tell you whether the artifact reflects the latest upstream state or how long the artifact has been carrying an older version.
For software foundations, those are different dimensions of the problem.
Why CleanStart does not race every upstream release
If the objective is to respond to upstream changes earlier, the obvious question is why not rebuild immediately.
The reason is that earlier is not automatically safer. A newly published release can contain an unintended regression, an insecure change, or malicious code. The publishing account, repository, dependency, or release process itself can also have been compromised.
The September 2025 compromise involving the npm packages chalk, debug, and other packages illustrates this risk. An attacker obtained the credentials of an npm maintainer and published malicious versions of widely used packages. The poisoned versions remained available for roughly two hours before they were detected and removed. GitHub subsequently introduced a default three-day cooldown for ordinary Dependabot version updates, specifically to create additional time for problems in newly published releases to be identified. The GitHub explanation of the Dependabot cooldown provides the incident context and rationale.
The lesson for a software producer is that reacting quickly to an upstream release and verifying that release are not competing objectives. Both matter, but there is a tradeoff between consuming a change immediately and giving security controls enough time to evaluate what changed.
CleanStart does not treat every upstream release as something to consume immediately. The process allows time for an upstream change to be evaluated before it becomes part of a CleanStart artifact. This introduces a deliberate tradeoff between release velocity and verification, recognizing that a newly published release should not automatically be treated as production-ready.
The broader industry is beginning to recognize the same tradeoff. GitHub's Dependabot documentation describes a configurable cooldown period for dependency updates, while GitHub's explanation of the feature describes the default three-day window as a way to give maintainers and security researchers time to identify problems in newly published releases. Security updates are treated differently, so the mechanism does not intentionally delay known security fixes.
A cooldown is not a security control by itself. Its value comes from creating time for other security controls to operate before a newly published dependency or software release is propagated further downstream.
How this compares to the alternatives
Distribution-maintained base images take a different approach. Debian, Red Hat, and other distributions maintain stable package versions and selectively backport security fixes, often keeping application-facing versions stable while incorporating relevant upstream changes. That model is valuable when API stability and long-term maintenance are priorities, because distribution security teams can incorporate fixes without requiring every downstream consumer to move to the latest upstream version.
The tradeoff is that the process depends on the distribution identifying the relevant upstream issue, determining its applicability, and producing the appropriate backport. There can also be cases where a change in upstream software has not yet been classified as a security issue and therefore does not enter the distribution's security-remediation workflow.
The scanner-first model has a different limitation. Build the software, scan the resulting artifact, and remediate findings. This works well for known vulnerabilities, but a vulnerability database cannot identify a security issue that has not yet entered the database. That is a structural limitation of the model, not a criticism of any particular scanner.
A source-build model starts earlier in the chain by treating upstream source changes as another signal to examine and incorporate rather than waiting for vulnerability intelligence to become the trigger. The objective is not to replace vulnerability scanning, but to complement it with earlier visibility into what is changing upstream and stronger evidence about what ultimately gets built.
What this does not solve
No source-driven rebuild process eliminates software supply-chain risk.
An upstream source repository can itself be compromised. A maintainer account can be stolen. A malicious commit can be introduced without immediately looking suspicious. A large release can contain enough changes that some deserve more scrutiny than others. A verification window can reduce some of these risks, but it cannot establish that every upstream change is safe.
There is also an important boundary around application code. CleanStart can control how the software components it builds are sourced, evaluated, and incorporated into its images. It cannot determine whether an organization's own application code contains a vulnerability.
The verification window should therefore be understood as a security control and risk-management decision, not as a guarantee that an artifact is safe. The objective is to avoid treating a newly published upstream release as automatically safe to consume simply because it has come from an established project.
Check your own exposure
There is a simple way to understand how much your current process depends on vulnerability databases.
Pick five packages that are important to your production container images. For each one, record the version currently present in production, the latest upstream release, the upstream release date, the date your current image was built, whether the difference between the two versions is associated with a published CVE, and how long it took for your organization to consume the upstream change.
The interesting cases are not necessarily the ones with a CVE. Look at the changes where upstream moved forward but your image remained unchanged while your vulnerability scanner continued to report the artifact as clean.
That gap represents software freshness, not necessarily vulnerability. It tells you how far the artifact has moved from the current upstream state, which is a different dimension of software supply-chain posture.
The software supply chain does not begin with the CVE
Vulnerability databases remain one of the most important sources of security intelligence in modern software development. They give security teams a common language for known vulnerabilities and make remediation measurable at scale. But they describe only one part of the software supply chain.
Upstream source changes happen before downstream artifacts are rebuilt. Releases happen before scanners evaluate the resulting images. In some cases, remediation activity and even fixed software can exist before the corresponding public vulnerability record becomes available.
That creates an opportunity for software producers to work from an earlier signal. An upstream release can trigger examination and rebuilding rather than waiting for vulnerability intelligence to become the reason to act. The changed source can be reviewed, the resulting artifact can be built through a controlled process, and provenance can provide evidence of where that artifact came from and how it was produced.
This does not eliminate vulnerability intelligence, and it does not make scanners less useful. It puts vulnerability intelligence into a broader supply-chain process where upstream change, source evaluation, controlled builds, verification, and artifact provenance all contribute to understanding what software is actually being consumed.
The goal is not simply to know whether an image has a CVE. It is to know what changed upstream, how that change was evaluated, what was built from it, and what artifact ultimately reached production.
The software supply chain changes upstream first. A resilient security process needs to see that change, verify it, and establish what was actually built before it reaches production.
