Pre-Disclosure Patching

What Is Pre-Disclosure Patching?

Pre-disclosure patching means shipping a fix for a vulnerability that has no published CVE identifier and no public advisory. The flaw is real and the fix is real; only the public record is missing. It happens under a coordinated-disclosure embargo, through a maintainer's private security process, or on the basis of a provider's own research.

Coordinated disclosure deliberately creates this gap. Reporters, maintainers and selected downstream packagers learn of a flaw first, build and test a correction, and agree a date on which the advisory and the identifier become public.

Until that date arrives, a patched build can circulate in the open while the reason for it does not. The artifact is ahead of the paperwork, by design rather than by accident, and anyone consuming that artifact has no database entry to consult about it.

How the Embargo Window Works

An embargo is an agreement about timing, and it has a defined inside.

• The reporter and the maintainer. The people who found the flaw and must fix it, who agree the disclosure date between them.
• Downstream packagers. Distributions and image builders needing lead time to rebuild, usually via a private list.
• A CVE Numbering Authority. An identifier can be reserved early and held unpublished until the date, which is why a fix may predate any visible record.
• Everyone else. Users, scanners and vulnerability databases, who learn of it when the advisory publishes.

A corrected build can therefore reach your registry before any database knows the flaw exists. That is the process working as intended.

The same situation arises without an embargo. A provider that finds and fixes a flaw in its own build may ship the correction long before anyone files for an identifier.

Why Scanners Cannot See It

A vulnerability scanner matches package names and versions against a database of known identifiers. Before publication there is no identifier and no affected-version range, so there is nothing to match.

The consequence is awkward. A patched artifact and an unpatched one look identical to a scanner: neither produces a finding, and the clean result says nothing about whether the fix is present. The scanner is answering a narrower question than the one being asked.

Evidence has to come from elsewhere:

• Image provenance. A signed attestation of how, when and from which source an artifact was built.
• An SBOM. A component inventory recording exact versions present, which can be matched retrospectively once a fix is named.
• The provider's changelog. Build records or release notes stating what changed, often the only human-readable account during an embargo.
• A VEX statement, later. Once an identifier exists, a fixed or not_affected status can be published against it; not_affected must carry a justification.

How to Handle Embargoed Fixes in Production Environments

The goal is to keep enough evidence that a clean scan today can be re-examined tomorrow.

• Treat a clean scan as evidence of no known issue, not evidence of a patched build.
• Record the digest of every deployed artifact, so you know later what ran.
• Keep an SBOM per build, so a newly published identifier can be matched backwards.
• Ask providers where fixes without an identifier are documented, and in what form.
• Re-scan stored artifacts when advisories publish, rather than only at build time.

How Hardened Container Images Relate to This Gap

Providers that rebuild from source on their own cadence can incorporate an upstream correction before it appears in a public database. That is a property of the build model, not a claim about any particular provider's speed.

What a buyer can actually verify is the evidence trail. Ask what provenance is attached, whether an SBOM ships with every image, where change records are published, and how long those records stay available afterwards. Echo states that its images are built on controlled build infrastructure at SLSA L3, signed and attested, and delivered with SBOM, provenance and VEX (echo.ai/product).

Echo builds hardened minimal base images and vetted open-source libraries; the surrounding practice is covered in CVE remediation.

FAQs

Can a fix exist before a CVE is published?

Yes, and it is common. Identifiers are frequently reserved during an embargo and published only on the agreed disclosure date, while maintainers and downstream packagers build and distribute the fix beforehand. Some corrections are shipped as ordinary bug fixes and never receive an identifier at all, which makes them harder to track.

Why does a scanner report nothing for an embargoed flaw?

Scanners compare installed versions against published advisory data. During an embargo no advisory exists, so there is no affected-version range to match and no finding to raise. The absence of a result reflects the absence of published data, not an assessment that the artifact is safe or that a fix has been applied.

Who is allowed inside an embargo window?

Typically the reporter, the maintainers, a CVE Numbering Authority, and downstream packagers such as distributions and image builders who need time to rebuild. Membership is usually governed by a private list with explicit rules about sharing. Everyone outside that circle, including scanners and vulnerability databases, learns of the flaw only when the advisory publishes.

What is the difference between an embargoed fix and a silent fix?

An embargoed fix has an agreed publication date; the record is coming. A silent fix is shipped with no advisory planned, often because the maintainer considered it a routine bug. Both leave scanners blind in the short term, but only the silent one leaves a permanent gap in the public record.

How can a team prove an artifact contains a fix?

By keeping evidence that does not depend on a vulnerability database. Signed provenance establishes what was built and when, an SBOM records the exact component versions present, and the provider's changelog states what changed. Together these let you match an artifact to a correction once the identifier finally appears in a public database.