You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: use endoflife.date for all EOL data, fix Temporal payload limit, and improve classification (#17)
## Summary
Fixes the detection pipeline to produce real, usable compliance data for
EKS and ElastiCache using only [endoflife.date](https://endoflife.date)
for EOL data — no AWS API credentials needed.
### What changed
**Temporal payload fix**
- Removed `RetrieveFindings` activity that returned all findings through
Temporal gRPC (12K+ findings = 10MB, exceeds 4MB limit)
- `CreateSnapshot` now reads directly from the in-memory store —
findings never transit Temporal
- Fails hard on empty snapshots (all workflows failed) or store read
errors
**EOL data from endoflife.date only**
- `ProductCycle.EOL` and `.Support` changed from `string` to `any`
(endoflife.date returns booleans or date strings)
- Enabled EKS via endoflife.date (was blocked by
`ProductsWithNonStandardSchema`)
- Fixed `aurora-postgresql` mapping to `amazon-aurora-postgresql`
- Added `aurora-mysql` mapping (pending
[endoflife.date#9534](endoflife-date/endoflife.date#9534))
- Removed `ProductsWithNonStandardSchema` blocklist and dead code
**Version matching**
- EOL provider uses prefix matching: cycle `8.0` matches resource
version `8.0.35`
- Policy uses prefix matching with `k8s-` prefix normalization
**Classification**
- Extended support is now YELLOW, not RED (check order fix + policy fix)
- EKS 1.30/1.32 correctly show "in extended support (6x standard cost)"
- ElastiCache Redis 5.0.6 correctly shows extended support
### Validated with docker-compose (real Wiz data)
| Resource | Findings | Yellow | Green | Unknown |
|----------|----------|--------|-------|---------|
| EKS | 155 | 90 (1.30, 1.32 in ext. support) | 65 | 0 |
| ElastiCache | 3,974 | 138 (Redis 5.0.6) | 3,739 | 97 |
| Aurora MySQL | 12,238 | 0 | 0 | 12,238 (no EOL source yet) |
### Single-pod assumption
The in-memory store is shared between detection and snapshot activities
because everything runs on a single Temporal worker. This is intentional
— we don't anticipate scaling this service to multiple pods.
---------
Co-authored-by: Amp <amp@ampcode.com>
0 commit comments