SCA-scanning: hoe het werkt en waar u het laat draaien

Wat er gebeurt in een SCA-scan

Het doel lezen. De scanner leest manifests en lockfiles zoals package-lock.json, poetry.lock of Cargo.lock, of pakt een containerimage uit.
De componentenlijst opbouwen. Hij zet wat hij heeft gevonden om in namen en versies, meestal inclusief transitieve afhankelijkheden.
De gegevens matchen. Elk component wordt opgezocht in bronnen zoals de GitHub Advisory Database, OSV en de NVD, en de licentie wordt vergeleken met uw beleid.
Rapporteren. Bevindingen komen eruit gerangschikt op ernst, meestal met een gepatchte versie. In CI kan een beleid de job laten mislukken.

Zie wat is software composition analysis voor de bredere discipline waar dit bij hoort.

Waar laat u SCA-scans draaien?

Eén scan op één plek laat hiaten achter. Elke fase beantwoordt een andere vraag, dus de meeste teams laten er meer dan één draaien.

Waar	Wat het beantwoordt	Wat het mist
Machine van de ontwikkelaar of IDE	Is dit pakket veilig om toe te voegen?	Alles waarop de ontwikkelaar de scan niet uitvoert
Pull request	Voegt deze wijziging een bekend risico toe?	Nieuwe advisories voor code die niet is gewijzigd
CI-build	Wat bevat de release?	Alles wat de scanner in de build niet kan zien
Containerregistry	Wat zit er in deze image?	Gecompileerde code en buildtools die geen spoor nalaten
Na de release	Wordt wat we hebben geleverd door iets nieuws getroffen?	Niets, als het record van wat is geleverd volledig is

De laatste rij is degene die de meeste programma's overslaan. Een nieuwe advisory raakt een versie die u maanden geleden hebt geleverd, en geen enkele pull request start daarvoor een scan.

Hoe leest u de resultaten van een SCA-scan?

Een eerste scan van een echt project levert vaak honderden bevindingen op. Werk ze in deze volgorde af:

Begin met wat wordt misbruikt. Een bevinding in de KEV-catalogus van CISA gaat boven een hogere CVSS-score zonder bekend misbruik. Zie hoe u kwetsbaarheden prioriteert.
Controleer of hij van toepassing is. Afhankelijkheden die alleen voor ontwikkeling dienen, worden niet geleverd. Sommige tools voegen reachability-analyse toe om te controleren of de kwetsbare code überhaupt kan worden aangeroepen.
Los het op het juiste niveau op. Bij een transitieve bevinding zit de oplossing meestal in het pakket dat de afhankelijkheid binnenhaalt, en dat ziet u in een dependency graph.
Leg vast wat u niet gaat oplossen. Bij een bevinding die u hebt geaccepteerd, hoort te staan waarom, anders doet de volgende persoon het werk opnieuw. VEX is de standaardmanier om dat vast te leggen.

Waarom een schone scan geen schone software betekent

Hij ziet wat is gedeclareerd. Een scanner leest de bestanden die hij voor zich heeft, dus een repository zonder gecommitte lockfile geeft hem weinig houvast, en code die een install-hook ophaalt, verschijnt nooit.
Hij ziet waar u hem op richt. De base image, de buildtools en de GitHub Actions in uw pipeline staan los van het manifest van uw applicatie.
Hij kent alleen wat is gepubliceerd. Een nieuw kwaadaardig pakket heeft nog geen advisory.
De lijst is niet de build. Builds bepalen versies pas wanneer ze draaien, dus wat de scan las en wat de release bevat, kunnen verschillen.

Dit zijn beperkingen van scannen zelf, commercieel of open source. CRACI heeft kwetsbare pakketten gevonden die Snyk en Aikido niet rapporteerden, omdat de componenten nooit in hun scan zaten.

Gratis en commerciële scanners

Gratis opties dekken de basis goed. Dependabot-meldingen komen met GitHub mee, OWASP Dependency-Check en Trivy zijn open source, en Grype werkt samen met de SBOM-generator Syft. Commerciële tools voegen beleid, prioritering, reachability en workflow over veel teams toe. De beste SCA-tools vergeleken behandelt er 13, en deze gids laat zien waarom gratis generatoren elkaar tegenspreken.

SCA-scanning en vastlegging tijdens de build

CRACI is geen scanner, en u hoeft die van u niet op te geven. Het is een GitHub Actions-runner die elk pakket vastlegt dat een job ophaalt, op elk niveau van de boom en inclusief pakketten die uit CI-caches zijn teruggezet, en daarna de SBOM's van wat is geleverd opnieuw blijft beoordelen zodra nieuwe kwetsbaarheden worden gepubliceerd. Uw scanner dekt pull requests en machines van ontwikkelaars. CRACI dekt de build en alles wat daarna komt. Zie waar CRACI past naast uw SCA-tools.

SCA-scanning: veelgestelde vragen

Wat is een SCA-scan?

Een SCA-scan leest de manifests, lockfiles of containerimage van een project, bepaalt welke open-sourcecomponenten het gebruikt en toetst die aan kwetsbaarheids- en licentiegegevens.

Is SCA hetzelfde als dependency scanning?

Bijna. Dependency scanning betekent meestal dat afhankelijkheden worden gecontroleerd op bekende kwetsbaarheden. SCA is de bredere term en omvat ook licenties, verouderde pakketten en het opstellen van een inventaris zoals een SBOM.

Wanneer moeten SCA-scans draaien?

Op pull requests, om te voorkomen dat nieuwe risico's binnenkomen; in de CI-build, om de release te beschrijven; en doorlopend na de release, omdat nieuwe advisories software raken die u al hebt geleverd.

Hoe lang duurt een SCA-scan?

Meestal enkele seconden tot een paar minuten, omdat hij metadata leest en niet al uw code analyseert. Daardoor is het praktisch om hem op elke pull request te laten draaien.

Waarom rapporteren SCA-scanners verschillende resultaten?

Elke scanner heeft eigen regels voor wat hij leest, hoe hij componenten benoemt en welke kwetsbaarheidsgegevens hij gebruikt. Dezelfde commit kan verschillende componentenlijsten en verschillende bevindingen opleveren.

Vindt SCA-scanning malware?

Matchen op advisories vindt kwaadaardige releases pas zodra er een advisory bestaat. Tools die het gedrag van pakketten analyseren, kunnen sommige eerder opmerken. Een nieuw kwaadaardig pakket heeft op de dag dat het verschijnt geen advisory.