Wat is software composition analysis (SCA)? Zo werkt het

Hoe SCA werkt

De componenten identificeren. De tool leest waar u hem op richt: manifests en lockfiles in een repository, geïnstalleerde pakketten, of de inhoud van een containerimage of binary. Het resultaat is een inventaris van componenten en versies, vaak geëxporteerd als SBOM.
Ze matchen met bekende risico's. Elk component wordt opgezocht in kwetsbaarheidsdatabases zoals de GitHub Advisory Database, OSV en de NVD, en de gedeclareerde licentie wordt getoetst aan uw beleid.
Prioriteren. Bevindingen worden gerangschikt op ernst, en sommige tools voegen reachability-analyse toe om te controleren of uw code de kwetsbare functie überhaupt kan aanroepen.
Oplossen. Veel tools stellen een gepatchte versie voor of openen een pull request, zoals Dependabot en Renovate doen. Bij een kwetsbare transitieve afhankelijkheid zit de oplossing meestal in het pakket dat hem binnenhaalt, en dat ziet u in een dependency graph.

Wat SCA vindt

Bekende kwetsbaarheden in de versies die u gebruikt, met de advisories die ze beschrijven.
Licentierisico, zoals een copyleftlicentie in een propriëtair product.
Verouderde en niet-onderhouden pakketten die geen beveiligingsfixes meer krijgen.
Kwaadaardige pakketten, in tools die ook analyseren hoe pakketten zich gedragen in plaats van alleen advisories te matchen.

SCA vs SAST

SCA en static application security testing (SAST) worden vaak samen verkocht, maar ze kijken naar verschillende code en beantwoorden verschillende vragen.

	SCA	SAST
Wat het analyseert	De open-source- en externe componenten waarvan u afhankelijk bent	De code die uw team schrijft
Wat het vindt	Bekende kwetsbaarheden, licentieproblemen, verouderde pakketten	Fouten in uw code, zoals injection of onveilige verwerking van invoer
Wat het leest	Manifests, lockfiles, geïnstalleerde pakketten, images of binaries	Broncode
Waardoor een bevinding nieuw is	Een wijziging in afhankelijkheden, of een nieuwe advisory voor een versie die u al levert	Een wijziging in uw code
Typische uitvoer	Kwetsbare componenten met gepatchte versies, en een SBOM	Locaties in de code met de fout en een voorgestelde oplossing

U hebt beide nodig. Een codebase zonder SAST-bevindingen kan nog steeds een kwetsbare afhankelijkheid leveren, en een schone afhankelijkheidsboom zegt niets over uw eigen code. Zie SAST vs SCA voor de volledige vergelijking. Eén verschil is van belang voor hoe u ze laat draaien: een SAST-bevinding verschijnt wanneer uw code verandert, terwijl een SCA-bevinding kan verschijnen bij een release die u maanden geleden hebt geleverd, op de dag dat een nieuwe advisory wordt gepubliceerd.

Waar SCA ophoudt

Elk SCA-resultaat hangt af van stap één: de componenten identificeren. Een component dat de tool nooit heeft geïdentificeerd, kan niet worden gematcht, geprioriteerd of opgelost, en het verschijnt ook niet als hiaat. De gebruikelijke blinde vlekken:

Wat niet in de bestanden staat. De meeste SCA-tools lezen manifests en lockfiles. Een ontbrekende of verouderde lockfile, pakketten die uit CI-caches zijn teruggezet, buildtools, downloads en installatiescripts bereiken de inventaris nooit. Zie waarom een lockfile geen record is van wat is geleverd.
Tools spreken elkaar tegen. Twee scanners die op dezelfde commit worden gericht, geven verschillende componentenlijsten terug, omdat elke scanner eigen regels heeft voor wat hij leest en hoe hij het benoemt. Zie wat open-source SBOM-generatoren missen.
Binaries. Software die als voorgecompileerde binary wordt verspreid, declareert weinig of niets wat een manifestlezer kan zien.
Alleen bekende kwetsbaarheden. Matchen vindt wat is gepubliceerd. Een nieuw kwaadaardig pakket of een niet-openbaar gemaakte fout heeft nog geen advisory.
Een momentopname. Een scan in een pull request beschrijft dat moment. Nieuwe advisories voor versies die al in productie zijn, vragen om iets wat blijft controleren wat is geleverd.

Dit is geen fout in één product. Zo werkt scannen, commercieel of open source. CRACI heeft kwetsbare pakketten gevonden die Snyk en Aikido niet rapporteerden, omdat de componenten nooit in hun scan zaten.

Leg de build vast, behoud uw SCA

CRACI dicht het identificatiegat vanaf de kant van de build. Het is een GitHub Actions-runner die elk pakket dat elke job ophaalt, op elk niveau van de boom en inclusief pakketten die uit CI-caches zijn teruggezet, vastlegt in een SBOM die zijn eigen volledigheid vermeldt. Het blijft de SBOM's van wat is geleverd opnieuw beoordelen zodra nieuwe kwetsbaarheden worden gepubliceerd, en de buildhistorie toont welke eerdere builds een kwetsbaar pakket bevatten.

CRACI doet bewust geen SAST of reachability-analyse. Teams gebruiken het naast een SCA- of SAST-tool die pull requests en hun eigen code dekt. Zie SCA-tools vergeleken, waar CRACI past naast uw SCA-tools, of boek een demo om een vastgelegde SBOM te vergelijken met uw huidige scan.

Software composition analysis: veelgestelde vragen

Wat is SCA in cybersecurity?

Software composition analysis (SCA) is het vinden van de open-source- en externe componenten in uw software en het controleren daarvan op bekende kwetsbaarheden, licentieproblemen en verouderde versies. Het dekt de code waarvan u afhankelijk bent, en niet de code die u schrijft.

Wat is het verschil tussen SCA en SAST?

SAST analyseert de code die uw team schrijft op fouten zoals injection-bugs. SCA analyseert de componenten waarvan u afhankelijk bent op bekende kwetsbaarheden en licentieproblemen. Ze beantwoorden verschillende vragen, dus de meeste beveiligingsprogramma's gebruiken beide.

Wat betekent SCA-scanning?

Een SCA-scan leest de manifests, lockfiles, geïnstalleerde pakketten of een containerimage van een project, bepaalt welke componenten erin zitten en matcht die met kwetsbaarheids- en licentiegegevens. Het resultaat is een lijst bevindingen, vaak met een SBOM van de geïdentificeerde componenten.

Is een SBOM hetzelfde als SCA?

Nee. Een SBOM is een inventaris: de lijst met componenten in een release. SCA is de analyse: componenten identificeren en ze op risico controleren. Veel SCA-tools maken onderweg een SBOM, en een SBOM kan na de release dienen als invoer voor kwetsbaarheidsmonitoring.

Wat zijn de beperkingen van SCA?

Het analyseert alleen de componenten die het kan identificeren, meestal uit manifests en lockfiles. Pakketten die uit CI-caches zijn teruggezet, buildtools, downloads en binaries zonder pakketmetadata kunnen worden gemist. Het vindt bekende kwetsbaarheden, geen onbekende, en een scan is een momentopname, tenzij de tool blijft controleren wat is geleverd.

Wat zijn de beste SCA-tools?

Dat hangt af van wat u naast de basis nodig hebt: reachability-analyse, detectie van kwaadaardige pakketten, licentiebeleid of een workflow voor ontwikkelaars. Zie onze vergelijking van 13 SCA-tools voor wat elk dekt en waar het ophoudt.