SAST vs SCA

Het verschil in één oogopslag

	SAST	SCA
Staat voor	Static application security testing	Software composition analysis
Bekijkt	Uw eigen broncode	Open-sourcecomponenten en componenten van derden
Vindt	Injectie, onveilige verwerking van invoer, onveilige patronen	Bekende kwetsbaarheden, licentieproblemen, verouderde pakketten
Steunt op	Regels of modellen van hoe slechte code eruitziet	Databases met gepubliceerde advisories
Een bevinding verschijnt als	Uw code verandert	Een afhankelijkheid verandert, of er een nieuwe advisory verschijnt
Veelvoorkomende ruis	Fout-positieven op code die eigenlijk veilig is	Echte matches die geen invloed hebben op hoe u het pakket gebruikt
Oplossing	Uw code wijzigen	Het component upgraden of vervangen

Wat SAST doet

Een SAST-tool leest broncode zonder die uit te voeren en volgt hoe gegevens erdoorheen bewegen. Bereikt gebruikersinvoer een databasequery zonder te zijn opgeschoond, dan rapporteert de tool het bestand en de regel. Omdat SAST op uw code werkt, kan het fouten vinden die nooit door iemand zijn gepubliceerd. Het is ook de bron van de klachten over fout-positieven, want het redeneert over wat de code zou kunnen doen en niet over wat die doet.

Wat SCA doet

Een SCA-scan identificeert de componenten in een project en zoekt ze op in kwetsbaarheids- en licentiegegevens. Uw logica analyseert hij niet. Hij weet dat een versie een gepubliceerde fout heeft, dus de resultaten zijn meestal feitelijk, maar hij zegt minder over de vraag of die fout voor u van belang is, tenzij de tool reachability-analyse toevoegt. Zie wat is software composition analysis voor het volledige plaatje.

Waarom u beide nodig hebt

De twee soorten falen staan los van elkaar. Een codebase zonder SAST-bevindingen kan nog steeds een kwetsbare afhankelijkheid leveren, en een schone afhankelijkheidsboom zegt niets over een SQL-injectie in uw eigen handler.

Ook de timing verschilt. Een SAST-bevinding verschijnt als iemand code wijzigt, dus een controle op de pull request vangt de meeste op. Een SCA-bevinding kan opduiken bij een release die u maanden geleden hebt geleverd, op de dag dat er een nieuwe advisory verschijnt, zonder commit die iets in gang zet. SCA heeft daarom iets nodig dat blijft controleren wat er is geleverd.

Waar DAST past

Dynamic application security testing valt een draaiende applicatie van buitenaf aan, zoals een echte aanvaller dat zou doen. Het vindt wat pas tijdens runtime zichtbaar wordt, zoals authenticatie- en configuratieproblemen, zonder de code te lezen.

	SAST	SCA	DAST
Heeft nodig	Broncode	Manifests, images of een buildvastlegging	Een draaiende applicatie
Draait	Op pull requests	Op pull requests, in builds en na de release	Tegen een testomgeving
Het sterkst in	Fouten in uw code	Bekende risico's in afhankelijkheden	Runtime- en configuratiefouten

Wat laat u als eerste draaien?

Voor de meeste teams: SCA. Het is snel opgezet, draait in seconden tot minuten en dekt het grootste deel van wat u levert, want een moderne applicatie bestaat vooral uit afhankelijkheden. Voeg daarna SAST toe, op pull requests, en stem het af op de regels die voor uw stack belangrijk zijn. Voeg DAST toe zodra u een stabiele testomgeving hebt om het op te richten.

Koopt u één platform of meerdere tools?

Platforms zoals Snyk, Checkmarx en GitHub Advanced Security bundelen SAST en SCA, wat één contract en één workflow betekent. Losse tools kunnen op elk gebied sterker zijn. Belangrijker is de invoer: beide soorten scanners werken op basis van wat is gedeclareerd of geschreven, en geen van beide ziet wat de build daadwerkelijk heeft binnengehaald.

Wat geen van beide dekt

SAST en SCA lezen allebei bestanden. Geen van beide observeert de build, dus code die door een install-hook wordt opgehaald, pakketten die uit CI-caches worden teruggezet en de buildtools zelf kunnen buiten beeld blijven. Over dat hiaat gaat ketenbeveiliging van software.

CRACI dekt dat deel en laat codescanning over aan de tools die daarvoor zijn gemaakt. Het doet bewust geen SAST of secrets scanning, en er zijn genoeg uitstekende SAST-tools die ernaast werken. Het is een GitHub Actions-runner die in een SBOM vastlegt wat elke job ophaalt, en de SBOM's van wat is geleverd blijft toetsen aan nieuwe kwetsbaarheden. Zie de beste SCA-tools en waar CRACI daarnaast past.

SAST vs SCA: veelgestelde vragen

Wat is het verschil tussen SAST en SCA?

SAST analyseert de code die uw team schrijft op fouten zoals injectie. SCA analyseert de open-sourcecomponenten en componenten van derden waarvan u afhankelijk bent op bekende kwetsbaarheden en licentieproblemen.

Vervangt SCA SAST?

Nee. Ze bekijken verschillende code. SCA vindt geen fout in uw eigen logica, en SAST vertelt u niet dat een afhankelijkheid een gepubliceerde kwetsbaarheid heeft.

Wat is het verschil tussen SAST, DAST en SCA?

SAST leest uw broncode. SCA controleert uw afhankelijkheden. DAST test een draaiende applicatie van buitenaf. Elk vindt problemen die de andere twee missen.

Is Snyk SAST of SCA?

Allebei. Snyk begon met het scannen van open-sourceafhankelijkheden en biedt ook SAST, samen met scanning van containers en infrastructure as code.

Is SonarQube SAST of SCA?

SonarQube staat vooral bekend om statische analyse van uw eigen code, en dat is SAST. Controleer in de huidige edities wat er verder in zit.

Wat komt eerst, SAST of SCA?

SCA levert meestal sneller resultaat op, omdat het eenvoudig is op te zetten en het grootste deel dekt van wat u levert. SAST vraagt meer afstemming om fout-positieven laag te houden.