SAST vs SCA

Forskjellen i korte trekk

	SAST	SCA
Står for	Static application security testing	Software composition analysis
Ser på	Din egen kildekode	Komponenter med åpen kildekode og fra tredjeparter
Finner	Injection, usikker håndtering av input, usikre mønstre	Kjente sårbarheter, lisensproblemer, utdaterte pakker
Bygger på	Regler eller modeller for hvordan dårlig kode ser ut	Databaser med publiserte advisories
Et funn dukker opp når	Koden din endres	En avhengighet endres, eller en ny advisory publiseres
Vanlig støy	Falske positiver på kode som faktisk er trygg	Reelle treff som ikke påvirker hvordan du bruker pakken
Retting	Endre koden din	Oppgradere eller bytte ut komponenten

Hva SAST gjør

Et SAST-verktøy leser kildekode uten å kjøre den og følger hvordan data beveger seg gjennom den. Hvis brukerinput når en databasespørring uten å være renset, rapporterer det filen og linjen. Fordi det jobber med koden din, kan det finne feil ingen noen gang har publisert. Det er også kilden til klagene på falske positiver, siden det resonnerer om hva koden kan gjøre, ikke hva den gjør.

Hva SCA gjør

En SCA-skanning identifiserer komponentene i et prosjekt og slår dem opp i sårbarhets- og lisensdata. Den analyserer ikke logikken din. Den vet at en versjon har en publisert feil, så resultatene er vanligvis faktabaserte, men den sier mindre om feilen betyr noe for deg, med mindre verktøyet legger til reachability-analyse. Se hva er software composition analysis for hele bildet.

Hvorfor du trenger begge

De to feiltypene er uavhengige av hverandre. En kodebase uten SAST-funn kan likevel levere en sårbar avhengighet, og et rent avhengighetstre sier ingenting om en SQL-injection i din egen handler.

Tidspunktet er også forskjellig. Et SAST-funn dukker opp når noen endrer kode, så en sjekk på pull requesten fanger de fleste. Et SCA-funn kan dukke opp på en utgivelse du leverte for måneder siden, den dagen en ny advisory publiseres, uten noen commit som utløser noe. SCA trenger derfor noe som fortsetter å sjekke det som ble levert.

Hvor DAST passer inn

Dynamic application security testing angriper en kjørende applikasjon utenfra, slik en ekte angriper ville gjort. Den finner det som bare viser seg under kjøring, som problemer med autentisering og konfigurasjon, uten å lese koden.

	SAST	SCA	DAST
Trenger	Kildekode	Manifester, images eller en byggeregistrering	En kjørende applikasjon
Kjører	På pull requests	På pull requests, i bygg og etter utgivelse	Mot et testmiljø
Best på	Feil i koden din	Kjente risikoer i avhengigheter	Feil under kjøring og i konfigurasjon

Hva bør du kjøre først?

For de fleste team: SCA. Det er raskt å sette opp, det kjører på sekunder til minutter, og det dekker den største delen av det du leverer, fordi det meste av en moderne applikasjon er avhengigheter. Legg deretter til SAST på pull requests, og juster det til reglene som betyr noe for din stack. Legg til DAST når du har et stabilt testmiljø å peke det mot.

Bør du kjøpe én plattform eller flere verktøy?

Plattformer som Snyk, Checkmarx og GitHub Advanced Security pakker sammen SAST og SCA, noe som betyr én kontrakt og én arbeidsflyt. Separate verktøy kan være sterkere på hvert område. Det som betyr mer, er inputen: Begge typer skannere jobber ut fra det som er deklarert eller skrevet, og ingen av dem ser hva bygget faktisk trakk inn.

Det ingen av dem dekker

SAST og SCA leser begge filer. Ingen av dem observerer bygget, så kode hentet av en installasjonshook, pakker gjenopprettet fra CI-cacher og selve byggeverktøyene kan forbli utenfor synsfeltet. Det hullet er det sikkerhet i programvareleverandørkjeden handler om.

CRACI dekker den delen og overlater kodeskanning til verktøyene som er laget for det. CRACI gjør ikke SAST eller skanning etter hemmeligheter, med vilje, og mange utmerkede SAST-verktøy fungerer ved siden av CRACI. CRACI er en GitHub Actions-runner som registrerer det hver jobb henter, i en SBOM, og som fortsetter å sjekke SBOM-ene for det som er levert, mot nye sårbarheter. Se de beste SCA-verktøyene og hvor CRACI passer inn ved siden av dem.

SAST vs SCA: ofte stilte spørsmål

Hva er forskjellen på SAST og SCA?

SAST analyserer koden teamet ditt skriver, for feil som injection. SCA analyserer komponentene med åpen kildekode og fra tredjeparter du er avhengig av, for kjente sårbarheter og lisensproblemer.

Erstatter SCA SAST?

Nei. De ser på ulik kode. SCA finner ikke en feil i din egen logikk, og SAST forteller deg ikke at en avhengighet har en publisert sårbarhet.

Hva er forskjellen på SAST, DAST og SCA?

SAST leser kildekoden din. SCA sjekker avhengighetene dine. DAST tester en kjørende applikasjon utenfra. Hver av dem finner problemer de to andre går glipp av.

Er Snyk SAST eller SCA?

Begge deler. Snyk begynte med skanning av avhengigheter med åpen kildekode og tilbyr også SAST, sammen med skanning av containere og infrastruktur som kode.

Er SonarQube SAST eller SCA?

SonarQube er best kjent for statisk analyse av din egen kode, altså SAST. Sjekk de gjeldende utgavene for hva annet de inkluderer.

Hva kommer først, SAST eller SCA?

SCA er vanligvis den raskeste gevinsten, fordi det er enkelt å sette opp og dekker den største delen av det du leverer. SAST krever mer justering for å holde falske positiver nede.