Skip to content

Fail CI when a CVE exception has passed its expires date - #501

Closed
ai-collaboration-app[bot] wants to merge 4 commits into
stackstate-7.78.2from
cve-exception-expiry-fail-closed
Closed

Fail CI when a CVE exception has passed its expires date#501
ai-collaboration-app[bot] wants to merge 4 commits into
stackstate-7.78.2from
cve-exception-expiry-fail-closed

Conversation

@ai-collaboration-app

@ai-collaboration-app ai-collaboration-app Bot commented Aug 28, 2026

Copy link
Copy Markdown

The repository-local exceptions carry expiry dates, but their only image scan runs in inform mode. Add a required CI check so expired or malformed deferrals block new publication.

The checker now accepts exactly the evaluator's YYYY-MM-DD grammar and has negative tests for alternate ISO forms and malformed documents. The four current entries expire on 2026-09-04.

Tracking: #500
CVE coordination: https://github.com/StackVista/cve-reporter/issues/29

Validated with the checker test suite, the live exception tree, git diff --check, and Zizmor.

stackstate-ci and others added 3 commits August 28, 2026 20:32
The exceptions/ tree carries `expires` dates that nothing enforced. The
scan-image evaluator does fail closed on expiry — a missing, unparseable or past
date turns the exception back into a live finding — but its exit code is 0
unconditionally in `inform` mode, and that is the mode this repo's only consumer
of the tree runs in (the report-only scan in build-deb.yml, since #487). The
gating chart scan in StackVista/cve-reporter does not read the tree at all, so
the dates were advisory.

All four current entries expire 2026-09-04, two of them standing deferrals for
Python advisories on the embedded 3.13.15 interpreter where no released fix
exists. With this wired into the required roll-up the check goes red the day
after an entry lapses, so renewing one means re-verifying upstream rather than
letting a deferral drift into a silent permanent acceptance. It warns for two
weeks beforehand so the red is never a surprise.

The job needs no secrets and no self-hosted runner, so unlike every other job
in this workflow it also covers fork pull requests.

Co-authored-by: Cve Ticket Reconciler <cve-ticket-reconciler@stackstate.invalid>
Nothing explained the tree, so the split between the report-only scan that
consumes it and the gating chart scan that ignores it was only discoverable by
reading both pipelines. Someone hitting the new expiry check needs to know that
the fix is to re-verify upstream, not to push the date out.

Co-authored-by: Cve Ticket Reconciler <cve-ticket-reconciler@stackstate.invalid>
Both recorded a 2026-08-21 re-check and pointed at #489, which was opened for the
OpenSSL exception and is superseded now that 3.5.8 is pinned. Re-verified against
upstream CPython tags: 3.13.15 is still the newest 3.13 and 3.15 has only reached
3.15.0rc1, so the 3.15.0a6 fix CVE-2025-15367 advertises exists in no released
version. Point them at the coordination ticket that actually tracks the batch.

Co-authored-by: Cve Ticket Reconciler <cve-ticket-reconciler@stackstate.invalid>
Use the evaluator's exact YYYY-MM-DD grammar and cover divergent ISO forms with checked tests so the CI guard cannot accept an exception the scan rejects.

Co-authored-by: Louis Lotter <louis.lotter@suse.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants