Timur Tukaev
ec2203a934
Four independent reviews of the first draft of this reporting found that it overstated remediation, understated how much of the backlog was never applicable, and contained a disclosure leak the stated rule had not anticipated. What lands here is the corrected version. The reconciliation is the substantive artifact. It audits every finding the CVE-scanning pipeline has tracked against what the project actually shipped, because the pipeline has no write-back from this repository and so has never marked anything fixed. Findings: remediation did happen and is invisible to the tracker, concentrated in one wave in June 2026 rather than the steady stream an earlier draft claimed; 57% of the backlog was never applicable or cannot be assessed, the largest block being packages that contain no executable vulnerable code, chiefly kernel headers, since a container never provides a running kernel; reachable exposure in a stock install is an estimated 2-5% of the tracker; four component bumps are available upstream and not yet taken; and the pipeline itself has seven defects, including deduplication by CVE identifier alone and a broken attribution step that left 16% of findings unattributable. The monthly reports are cut back to per-month facts. Remediation is no longer attributed to individual months: crossing a severity-banded count of still-open findings with one month's component bumps, which anyone can enumerate from the commit log, narrows the search for unpatched exposure more than a bare count does. An earlier draft did exactly that while refusing to publish bare counts on disclosure grounds. The triage-latency figure is also gone, because 494 of 495 decisions were recorded in a single bulk pass and a per-finding latency cannot be recovered from a closing timestamp. Two process-tracking issues that the pipeline's severity filter should have excluded are no longer counted as findings, so the total is 825 rather than 827. The disclosure rule is revised in two directions, both more open: findings with no upstream fix will be named with mitigation guidance, since there is nothing to wait for and a mitigation is then the only available control; and the generator's guard now covers every advisory namespace rather than CVE alone, refuses to emit any file if any file would leak, and takes released evidence rather than a stale tracker label as its source of truth. SECURITY.md, the self-assessment and the GTR are brought into line: all three previously described this reporting as unpublishable, and the GTR refused on principle the counts the reports print. Assisted-By: Claude <noreply@anthropic.com> Signed-off-by: Timur Tukaev <timur.tukaev@aenix.io>
4.2 KiB
Cozystack security report — August 2026
Generated 2026-08-11 from the tracker state on that date. This month is incomplete: data is cut off at 2026-08-10. Figures are counted from the tracked findings of the organization-wide CVE-scanning pipeline described in SECURITY.md.
Read this alongside the backlog reconciliation. The state counts below are what the pipeline recorded, and the pipeline has no write-back from the main repository, so it has never marked anything fixed and its outstanding counts overstate real exposure. The reconciliation establishes what was actually remediated and how much of the backlog was never applicable. Do not read the tables here as a measure of exposure without it.
Disclosure. Findings are reported as counts by severity; an individual finding is named once its fix is merged and released. Counts cover findings the pipeline tracks as actionable, after its filters for development-and-build-only dependencies, findings whose upstream has had no fix for over a year, and findings with no severity assigned in any database. Two of those filters are known not to work as documented — see the reconciliation.
New findings tracked this month
17 — 17 high
Triage decisions recorded this month
No triage decisions were recorded this month.
Remediation activity this month
2 version bumps were merged, representing 1 distinct changes once backports of the same change to release branches are collapsed. These are counted from diffs: a pull request that only moves a chart version, edits an upgrade path or changes CI configuration is not counted as a bump, because it cannot carry a fix into an artifact.
How many tracked findings those bumps carried away is deliberately not stated per month. Attributing findings to one month's bumps would cross a severity-banded count of still-open findings with a component list that is publicly enumerable from the commit log, which narrows the search for unpatched exposure more than a bare count does. The remediation disposition of the whole backlog is given once, with an as-of date, in the reconciliation.
Position at 2026-08-10
| State | Count | By severity |
|---|---|---|
| Awaiting a triage decision | 331 | 13 critical, 318 high |
| Confirmed — real, needs a fix | 332 | 30 critical, 292 high, 10 medium |
| Accepted risk — real, not reachable or not worth the change | 61 | 6 critical, 52 high, 3 medium |
| Dismissed — not applicable | 101 | 5 critical, 93 high, 3 medium |
| Total tracked | 825 |
Nothing appears as fixed in any month because the pipeline cannot record that state at all. Confirmed findings therefore accumulate and never drain, which is a property of the tooling rather than a measure of outstanding work.
Where the process stands
Triage is behind its target and has no owner. The rotating Security Champion role that owns the triage clock is defined in the pipeline's governance document and is currently unassigned. That is why decisions arrived in a single bulk pass rather than continuously, and it is the project's real gap — not the bookkeeping problem below.
The configured detection schedule is every six hours for critical findings and weekly for the rest. Whether every scheduled run executed cannot be established from finding data alone, and the record has gaps: no weekly cohort appears for 2026-05-26, and intervals between critical findings reach 26 days. Absence of findings is not proof of a missed run, but neither is it proof of a completed one.
Remediation is happening and the tracker cannot see it. Fixes land in the main repository as ordinary pinned-component bumps and nothing writes that back here. The reconciliation sets out what was actually fixed, which components still need a bump that is already available upstream, and the defects found in the pipeline itself.
Reporting a vulnerability
Please do not use public issues. Use GitHub Private Vulnerability Reporting or contact a maintainer privately; the full policy is in SECURITY.md.