Release and CVE policy
How often a new version arrives, how quickly a vulnerability gets fixed in one, and what has to be true before a version is published at all.
How often releases arrive
Through the 0.x series, releases are weekly. From 1.0 the cadence is monthly — one scheduled release a month, with release notes describing what changed and what to read before upgrading.
Two things interrupt that schedule, and we publish both out of cycle: a critical vulnerability with a fix available, and a defect serious enough that we would replace the release you are on rather than leave it standing until the next scheduled one. The release notes say which of the two an out-of-cycle release was; every one so far — 0.8.1, 0.8.2 and 0.8.3 — has been the second.
You choose when to take a release. Nothing upgrades itself, nobody from Tetrate can reach your deployment to make it, and there is no separate upgrade path — see Upgrading to a new release.
Vulnerabilities: what we commit to
| Severity | We publish a release carrying the fix |
|---|---|
| Critical | Within 48 hours — out of cycle |
| Everything else | In the next scheduled release: within 30 days once the monthly cadence starts |
The clock starts when a fix is available to us — an upstream package, base image or dependency version we can actually take. That is deliberate, and it is the same standard our release gate applies below. A vulnerability whose only fix is a release nobody upstream has published yet is not one any vendor can carry a fix for; where that is the situation we say so in the release notes rather than letting the date pass quietly.
What has to be true before a release ships
Every image is scanned with Trivy before it is pushed, and a fixable CRITICAL or HIGH finding stops the release. The scan runs inside the script that cuts the release, before anything reaches a registry, so a version that fails it does not reach one at all.
Where a finding has no fix we can take — most often a vulnerability reported against a third-party binary whose upstream has declined to rebuild it — we may decide to ship it anyway. When we do, that decision is written down before the release goes out, with the reasoning, a named owner and an expiry date, and it is re-reviewed at that expiry and every time the affected image changes.
We publish those acceptances rather than leaving your scanner to find them: Security acceptances in the release notes names every finding we have decided to ship, which images it is in, what makes the residual risk acceptable, and what would end it.
If your scan reports something ours did not
That happens, and it is not a contradiction of anything above: scanners disagree, vulnerability databases update after we publish, and your gate may be configured to flag what ours does not. Send us the finding — see How we scan the images. We will tell you whether a fix exists and, if it does, which release carries it, on the clocks above.