Ga naar inhoud

Supply-chain security

monsys.ai dekt drie categorieën supply-chain risk:

  1. OS-packages — apt/rpm/winget/wmic → NVD + EPSS
  2. Container images — Docker images → Trivy (hub-side)
  3. 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:

OSBron
Debian/Ubuntudpkg-query -W
RHEL/Alma/Rockyrpm -qa
Alpineapk info -vv
Windowswinget 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 luistert
capped at 10.0

Internet-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 login op 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:

ManifestEcosystem
package-lock.json (v1/v2/v3)npm
yarn.locknpm
pnpm-lock.yamlnpm
requirements.txtPyPI
Pipfile.lockPyPI
composer.lockPackagist
Gemfile.lockRubyGems
go.sumGo

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

  • Typosquattingreact-dom vs react.dom. Geen pattern detection.
  • Malicious install scriptsnpm install van 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

  1. npm ci --ignore-scripts in CI en productie — npm install alleen in dev waar je weet wat je laat draaien.
  2. Pin productie-dependencies (package-lock.json committen, geen ^X.Y.Z ranges).
  3. Zet alert rules op: een nieuwe CRITICAL CVE in inventory_dependency_cves voor agent met tag production → notify in 1 min.
  4. Maintenance windows tijdens deploys — anders triggert je rolling-update een alert-storm.
  5. Audit log check één keer per week voor abnormale playbook_run of branding-PUT acties.