Het probleem
Elke dag komen er security-advisories binnen, en voor elke advisory moet iemand met de hand uitzoeken: gebruiken we dit, waar, en welke versie? Het antwoord is meestal "niet in gebruik" of "extern beheerd", maar dat uitzoeken kost elke keer tijd. En de keren dat het wél raak is, wil je het zeker weten.
De bouwstenen
- CSAF-feed van het NCSC. Dezelfde adviezen staan openbaar als machineleesbare CSAF-documenten, met een
changes.csvdie de nieuwste bovenaan zet. Kans en schade staan in de notes. - Pakketlijsten.
dpkg-queryper server via SSH: naam, versie, architectuur. - OSV. De OSV-database van Canonical bevat per Ubuntu-release (inclusief ESM) welke versie een kwetsbaarheid oplost.
De PoC
Een Python-script (osvmatch) haalt de pakketlijsten op, legt ze naast OSV en geeft per server een lijst van pakketten met een bekende fix die nog niet geïnstalleerd is. De CSAF-feed bepaalt welke advisories nieuw zijn en welke CVE's erbij horen.
Twee dingen die ik onderweg leerde:
- In de OSV-records voor betaalde ondersteuning (Ubuntu Pro/ESM) staat de fix vaak niet in het gewone veld, maar alleen in
ecosystem_specific.binaries. - Een vergelijking met de bestaande apt-exporter leverde een verrassing op: de exporter meldde één beschikbare update, de scan tientallen. De spiegelserver waar de servers hun beveiligingsupdates vandaan haalden, bleek al maanden niet bijgewerkt. Zo'n scan controleert dus niet alleen je servers, maar ook je updatekanaal.
Ontwerpkeuzes
- Draaien op de monitoringhost, die al bij alle servers kan, niet in Kubernetes.
- Alleen lezen: pakketlijsten, geen configuratie of data.
- Output als metrics en een tabel, zodat een dashboard per advisory laat zien welke servers geraakt zijn.
Status
Voorbereidingsdocument en werkende PoC klaar; de keuze voor een proefopstelling ligt bij het team.