Both SecDB advisory feeds are currently being served as empty files (HTTP 200, Content-Length: 0), which breaks vulnerability ingestion for our scanner which is consuming them.
Affected URLs
https://packages.cgr.dev/chainguard/security.jsonhttps://packages.wolfi.dev/os/security.json
Evidence
$ curl -sI https://packages.cgr.dev/chainguard/security.json
HTTP/2 200
content-length: 0
x-goog-stored-content-length: 0
etag: "d41d8cd98f00b204e9800998ecf8427e" # MD5 of the empty string
last-modified: Fri, 10 Jul 2026 01:16:21 GMT
$ curl -sI https://packages.wolfi.dev/os/security.json
HTTP/2 200
content-length: 0
etag: "d41d8cd98f00b204e9800998ecf8427e"
last-modified: Fri, 10 Jul 2026 01:16:22 GMT
Both objects carry the empty-string etag (d41d8cd98f00...) and were last modified within one second of each other (01:16:21 and 01:16:22 UTC on 2026-07-10), which points to a single publishing job that wrote both feeds as 0 bytes, rather than a transient CDN/network issue. The feeds have remained empty for several hours.
Impact
Scanners fetch a 200 OK and then fail to parse the empty payload (e.g. JSON unmarshalling errors on the first byte), so no Wolfi/Chainguard advisory data is ingested. A 200 + empty body is worse than a 4xx/5xx here, because clients that retry on transport errors will keep succeeding on the fetch and failing on the parse.
Expected
The feeds should serve the full advisory database. Per "SecDB is the past, OSV is the future", SecDB feeds are committed to "remain functional through the end of 2026," so this appears to be an unintended regression rather than the planned sunset.
Questions
- Is this a known issue with the current secdb publishing pipeline?
- Can the empty artifacts be re-published from the last good generation?
Both SecDB advisory feeds are currently being served as empty files (HTTP 200,
Content-Length: 0), which breaks vulnerability ingestion for our scanner which is consuming them.Affected URLs
https://packages.cgr.dev/chainguard/security.jsonhttps://packages.wolfi.dev/os/security.jsonEvidence
Both objects carry the empty-string etag (
d41d8cd98f00...) and were last modified within one second of each other (01:16:21 and 01:16:22 UTC on 2026-07-10), which points to a single publishing job that wrote both feeds as 0 bytes, rather than a transient CDN/network issue. The feeds have remained empty for several hours.Impact
Scanners fetch a 200 OK and then fail to parse the empty payload (e.g. JSON unmarshalling errors on the first byte), so no Wolfi/Chainguard advisory data is ingested. A 200 + empty body is worse than a 4xx/5xx here, because clients that retry on transport errors will keep succeeding on the fetch and failing on the parse.
Expected
The feeds should serve the full advisory database. Per "SecDB is the past, OSV is the future", SecDB feeds are committed to "remain functional through the end of 2026," so this appears to be an unintended regression rather than the planned sunset.
Questions