Supply-chain security
monsys.ai dekt drie categorieën supply-chain risk:
- OS-packages — apt/rpm/winget/wmic → NVD + EPSS
- Container images — Docker images → Trivy (hub-side)
- Application dependencies — npm/pip/composer/go/gem → OSV.dev
Geen van de drie vereist extra software op de klant-host. De agent rapporteert namen + versies; de hub doet het CVE-werk.
OS-packages
De agent leest pakketmanager-state uit:
| OS | Bron |
|---|---|
| Debian/Ubuntu | dpkg-query -W |
| RHEL/Alma/Rocky | rpm -qa |
| Alpine | apk info -vv |
| Windows | winget list met fallback naar wmic product get |
Resultaat per agent: inventory_packages rij met (name, version, manager). Hub matcht tegen de actuele NVD-feed + EPSS exploit-waarschijnlijkheid, met version-range parsing voor exact-, geq-/leq-, en multi-range expressions.
Per match wordt een risk_score berekend:
base = cvss × max(epss, 0.05)× 1.5 als CVE >30 dagen oud zonder patch (age factor)× 2.0 als bekende public exploit bestaat (exploit factor)× 1.5 als het pakket op een internet-facing port luistertcapped at 10.0Internet-exposure wordt afgeleid uit inventory_ports met address NOT IN ('127.0.0.1', '::1') matched op proces-naam.
Endpoint: GET /api/v1/inventory/cves (fleet-wide) of ?agent=<uuid> (per host). Filter parameters: cve, pkg, min_cvss, tag. CSV export: &format=csv.
Container images
Voor klanten die Docker draaien rapporteert de agent inventory_containers rijen — image-naam + tag, image-digest, run-state, port mappings, run-as user, cap_add, privileged flag.
De hub draait trivy image --severity=HIGH,CRITICAL --scanners=vuln tegen elke unieke (image, tag) elke 6h. Trivy gebruikt de officiële vuln-database (gemirrord uit GitHub Advisory + NVD); wij syncen die DB één keer op de hub.
Belangrijk: Trivy staat niet op de klant-host. We hebben in een eerdere iteratie kort overwogen om dat wel te doen, maar dat vereist root-toegang en software-installatie bij elke klant. De hub-side aanpak werkt voor:
- Public registries (Docker Hub, GHCR, Quay) — meteen
- Private registries — eenmalig
trivy registry loginop de hub host
Findings komen in inventory_container_cves en zijn zichtbaar in de Containers-tab van elke agent.
Limitaties:
- Geen scan van images die enkel via een private registry achter een VPN beschikbaar zijn waarvan de hub geen netwerk-toegang heeft. Voor dat scenario zie RFC-0001 Tailscale integration.
- Geen scan van running container internals (process tree, mounted secrets) — alleen wat in de image-manifests zit.
Application dependencies (npm/pip/composer/go/gem)
De agent walkt /var/www, /opt, /srv, /home/*, /root (max diepte 6) en parset lockfiles:
| Manifest | Ecosystem |
|---|---|
package-lock.json (v1/v2/v3) | npm |
yarn.lock | npm |
pnpm-lock.yaml | npm |
requirements.txt | PyPI |
Pipfile.lock | PyPI |
composer.lock | Packagist |
Gemfile.lock | RubyGems |
go.sum | Go |
Alleen (name, version, ecosystem, is_direct) tuples worden naar de hub gestuurd — geen file-inhoud. Caps per host: max 100 projects, max 20.000 packages, max 6 niveaus diep. node_modules, vendor, .git worden overgeslagen.
De hub DependencyScanWorker batch-queryt https://api.osv.dev/v1/querybatch (1000 tuples/request, gratis, public). Voor elke match haalt hij /v1/vulns/<id> op voor details. Resultaten in inventory_dependency_cves met severity (CRITICAL/HIGH/MODERATE/LOW), fix-versie, summary, aliases.
Cold-start cadence: elke 30s in de eerste 15 min na hub-start (vangt nieuwe deps op), daarna 6h steady.
Wat OSV.dev WEL dekt
- Bekende CVE’s met aliases (CVE-, GHSA-, PYSEC-, RUSTSEC-, …)
- Affected version ranges met fix-versies
- Severity uit GitHub Advisory DB (genormaliseerd door ons naar CRITICAL/HIGH/MODERATE/LOW)
- Cross-ecosystem aliases — één GHSA kan zowel npm als Python betreffen
Wat OSV.dev NIET dekt
- Typosquatting —
react-domvsreact.dom. Geen pattern detection. - Malicious install scripts —
npm installvan een legitiem-uitziend pakket dat backdoors plaatst. Vereist tarball-analyse. - Compromised maintainer accounts waar een normaal pakket plots malicious code bevat (event-stream-stijl).
Voor die categorieën heb je gedrags-analyse nodig zoals Socket.dev of npm audit signatures (sigstore signing). Beide kunnen later geïntegreerd worden.
Best practices voor klanten
npm ci --ignore-scriptsin CI en productie —npm installalleen in dev waar je weet wat je laat draaien.- Pin productie-dependencies (
package-lock.jsoncommitten, geen^X.Y.Zranges). - Zet alert rules op: een nieuwe CRITICAL CVE in
inventory_dependency_cvesvoor agent met tagproduction→ notify in 1 min. - Maintenance windows tijdens deploys — anders triggert je rolling-update een alert-storm.
- Audit log check één keer per week voor abnormale
playbook_runofbranding-PUT acties.