A vulnerability is only meaningful in context. "There's a CVE in OpenSSH" is interesting; "there's a CVE in OpenSSH 9.7p1 and we're running 9.6p1" is actionable; "there's a CVE that's already being actively exploited and we have a vulnerable copy on Box A" is immediate.
The hard part is the joining. CVE feeds are huge, generic, and most entries don't apply to any given box. To turn raw feeds into action you need to know exactly what's installed, on which node, at what version. We wrote a daemon that does this every morning. It's called flame-sploit-watcher.
What it does
Once a day, the watcher:
- Pulls the latest Alpine security database for each fleet node's distro version (Alpine 3.19 for one node, Alpine 3.23 for the other two — both
mainandcommunityrepositories) - Pulls the CISA Known Exploited Vulnerabilities catalog — the list of CVEs that are actually being exploited right now, not just theoretically dangerous
- Reads the installed package list from each node (over WireGuard, not the public internet)
- Joins: for each installed package, is there a known CVE with a fix version greater than what's installed?
- Filters by severity threshold (we set ours to High and above; Low gets logged but not alerted)
- Posts a single coalesced message to our security Discord channel — sorted critical-first, deduplicated against findings already reported
Findings persist to a seen.tsv so the same CVE doesn't re-alert every day. New findings get fresh alerts; resolved ones (fixed by a package upgrade) drop off automatically.
What it found on day one
We deployed the watcher and let it run its first cycle without any pre-filtering, to get an honest snapshot. It found eight things — all real, all actionable, all worth fixing:
- musl on the primary needed an
apk upgrade musl(two CVEs fixed in r6) - rsync on both fleet nodes needed an upgrade to r2 — patches a path-traversal class bug
- xz on the fleet nodes needed 5.8.3 — earlier versions had been backdoored upstream (the famous March 2024 supply chain incident; the fix kept landing in distro updates for a year)
- OpenSSH on the primary node needed an Alpine 3.19 → 3.20 jump because the older Alpine main repo doesn't ship the fixed version yet
- Node.js on the primary needed to be removed entirely — because the CVE was in CISA's actively-exploited catalogue and we have an internal policy of not running Node anyway
That last one is a good illustration of why the watcher matters. We had Node.js installed for a one-off task months ago and forgotten about it. The package was never wanted, the CVE just made the cleanup urgent. The watcher pointed at the package and said "this needs attention" without us having to remember it was there.
What it doesn't catch (yet)
The Alpine security database only tracks CVEs that have been triaged and assigned a fix version for that distro's package version. If a CVE is published but Alpine hasn't merged the fix yet, the watcher's join misses it.
The canonical example right now is the kernel CVE we wrote about a few days ago — it's in the CISA exploitation catalogue, but no Alpine kernel package fix has shipped. Our watcher correctly flags the kernel package as installed, but the cross-reference comes up empty until the Alpine entry exists. The CISA list itself is enough to know we have to act, but the per-package join is what tells us whether action is possible yet.
The next phase of the watcher (planned, not yet shipped) cross-references the National Vulnerability Database's CPE matching, which lets us catch "the upstream knows but the distro hasn't packaged the fix yet" cases. That gives us a head start on mitigation work — even if the patch isn't ready, we want to know we'll need one.
Why this is a daemon, not a Tuesday-morning chore
The honest reason this is a daemon and not a manual checklist is that manual security checks decay. Anyone who has worked in security has seen the spreadsheet that says "patches reviewed weekly" with a last-modified date six months ago. The watcher posts to Discord every day at the same time. If it stops posting, the silence itself is alerting.
It's also fast. The whole cycle runs in well under a minute. The cost of running it is zero. The cost of not running it is the next supply-chain bug that ships in a package we forgot about.
Most of security work isn't fighting attackers. It's just keeping the inventory accurate. If you don't know exactly what's running on every box at what version, you don't have a security posture — you have hope.