SAST vs. SCA

Forskellen i korte træk

	SAST	SCA
Står for	Static application security testing	Software composition analysis
Ser på	Din egen kildekode	Open source- og tredjepartskomponenter
Finder	Injection, usikker håndtering af input, usikre mønstre	Kendte sårbarheder, licensproblemer, forældede pakker
Bygger på	Regler eller modeller for, hvordan dårlig kode ser ud	Databaser med offentliggjorte advisories
Et fund opstår, når	Din kode ændres	En afhængighed ændres, eller en ny advisory offentliggøres
Typisk støj	Falske positiver på kode, der faktisk er sikker	Reelle match, der ikke påvirker, hvordan du bruger pakken
Rettelse	Ændr din kode	Opgradér eller udskift komponenten

Hvad SAST gør

Et SAST-værktøj læser kildekode uden at køre den og følger, hvordan data bevæger sig gennem den. Hvis brugerinput når en databaseforespørgsel uden at blive renset, rapporterer det fil og linje. Fordi det arbejder på din kode, kan det finde fejl, som ingen nogensinde har offentliggjort. Det er også kilden til klagerne over falske positiver, da det ræsonnerer over, hvad koden måske gør, og ikke over, hvad den gør.

Hvad SCA gør

En SCA-scanning identificerer komponenterne i et projekt og slår dem op i sårbarheds- og licensdata. Den analyserer ikke din logik. Den ved, at en version har en offentliggjort fejl, så dens resultater er som regel faktuelle, men den siger mindre om, hvorvidt fejlen betyder noget for dig, medmindre værktøjet tilføjer reachability-analyse. Se hvad er software composition analysis for det fulde billede.

Derfor har du brug for begge

De to former for svigt er uafhængige. En kodebase uden SAST-fund kan stadig levere en sårbar afhængighed, og et rent afhængighedstræ siger intet om en SQL-injection i din egen handler.

Timingen er også forskellig. Et SAST-fund opstår, når nogen ændrer kode, så et tjek på pull requests fanger de fleste af dem. Et SCA-fund kan opstå på en release, du leverede for måneder siden, den dag en ny advisory offentliggøres, uden et commit til at udløse noget. SCA kræver derfor noget, der bliver ved med at tjekke det leverede.

Hvor DAST passer ind

Dynamic application security testing angriber en kørende applikation udefra, sådan som en rigtig angriber ville gøre. Det finder det, der kun viser sig under kørsel, såsom problemer med godkendelse og konfiguration, uden at læse koden.

	SAST	SCA	DAST
Kræver	Kildekode	Manifester, images eller en registrering af buildet	En kørende applikation
Kører	På pull requests	På pull requests, i builds og efter release	Mod et testmiljø
Bedst til	Fejl i din kode	Kendte risici i afhængigheder	Fejl under kørsel og i konfiguration

Hvilken skal du køre først?

For de fleste teams SCA. Det er hurtigt at sætte op, det kører på sekunder til minutter, og det dækker den største del af det, du leverer, fordi det meste af en moderne applikation er afhængigheder. Tilføj derefter SAST på pull requests, og tilpas det til de regler, der betyder noget for din stack. Tilføj DAST, når du har et stabilt testmiljø at køre det mod.

Skal du købe én platform eller flere værktøjer?

Platforme som Snyk, Checkmarx og GitHub Advanced Security samler SAST og SCA, hvilket betyder én kontrakt og ét workflow. Separate værktøjer kan være stærkere på hvert område. Det, der betyder mere, er inputtet: Begge typer scannere arbejder ud fra det, der er deklareret eller skrevet, og ingen af dem ser, hvad buildet faktisk hentede.

Det, ingen af dem dækker

SAST og SCA læser begge filer. Ingen af dem observerer buildet, så kode hentet af et install-hook, pakker gendannet fra CI-caches og selve build-værktøjerne kan forblive uden for synsfeltet. Det hul er det, som forsyningskædesikkerhed for software handler om.

CRACI dækker den del og overlader kodescanning til de værktøjer, der er bygget til det. Det laver bevidst ikke SAST eller secrets-scanning, og masser af fremragende SAST-værktøjer fungerer ved siden af det. Det er en GitHub Actions-runner, der registrerer, hvad hvert job henter, i en SBOM og bliver ved med at tjekke SBOM'erne for det leverede mod nye sårbarheder. Se de bedste SCA-værktøjer og hvor CRACI passer ind ved siden af dem.

SAST vs. SCA: ofte stillede spørgsmål

Hvad er forskellen på SAST og SCA?

SAST analyserer den kode, dit team skriver, for fejl som injection. SCA analyserer de open source- og tredjepartskomponenter, du afhænger af, for kendte sårbarheder og licensproblemer.

Erstatter SCA SAST?

Nej. De ser på forskellig kode. SCA finder ikke en fejl i din egen logik, og SAST fortæller dig ikke, at en afhængighed har en offentliggjort sårbarhed.

Hvad er forskellen på SAST, DAST og SCA?

SAST læser din kildekode. SCA tjekker dine afhængigheder. DAST tester en kørende applikation udefra. Hver af dem finder problemer, de to andre overser.

Er Snyk SAST eller SCA?

Begge dele. Snyk begyndte med scanning af open source-afhængigheder og tilbyder også SAST samt scanning af containere og infrastructure as code.

Er SonarQube SAST eller SCA?

SonarQube er bedst kendt for statisk analyse af din egen kode, altså SAST. Tjek de aktuelle udgaver for, hvad de ellers indeholder.

Hvad kommer først, SAST eller SCA?

SCA er som regel den hurtigste gevinst, fordi det er enkelt at sætte op og dækker den største del af det, du leverer. SAST kræver mere tilpasning for at holde falske positiver nede.