Hva er software composition analysis (SCA)?

Slik fungerer SCA

1. Identifiser komponentene. Verktøyet leser det det blir pekt mot: manifester og lockfiler i et repositorium, installerte pakker eller innholdet i et container-image eller en binærfil. Resultatet er en oversikt over komponenter og versjoner, ofte eksportert som en SBOM.
2. Match dem mot kjente risikoer. Hver komponent slås opp i sårbarhetsdatabaser som GitHub Advisory Database, OSV og NVD, og den deklarerte lisensen sjekkes mot policyen din.
3. Prioriter. Funn rangeres etter alvorlighetsgrad, og noen verktøy legger til reachability-analyse for å sjekke om koden din i det hele tatt kan kalle den sårbare funksjonen.
4. Rett. Mange verktøy foreslår en rettet versjon eller åpner en pull request, slik Dependabot og Renovate gjør. For en sårbar transitiv avhengighet ligger rettingen vanligvis i pakken som trekker den inn, og det viser en avhengighetsgraf.

Dette finner SCA

• Kjente sårbarheter i versjonene du bruker, med advisories som beskriver dem.
• Lisensrisiko, for eksempel en copyleft-lisens i et proprietært produkt.
• Utdaterte og uvedlikeholdte pakker som ikke vil få sikkerhetsrettinger.
• Ondsinnede pakker, i verktøy som også analyserer hvordan pakker oppfører seg, ikke bare matcher advisories.

SCA vs. SAST

SCA og statisk testing av applikasjonssikkerhet (SAST) selges ofte sammen, men de ser på ulik kode og svarer på ulike spørsmål.

	SCA	SAST
Hva det analyserer	Komponentene med åpen kildekode og fra tredjeparter som du er avhengig av	Koden teamet ditt skriver
Hva det finner	Kjente sårbarheter, lisensproblemer, utdaterte pakker	Feil i koden din, for eksempel injection eller usikker håndtering av inndata
Hva det leser	Manifester, lockfiler, installerte pakker, images eller binærfiler	Kildekode
Hva som gir et nytt funn	En endret avhengighet, eller en ny advisory for en versjon du allerede leverer	En endring i koden din
Typisk resultat	Sårbare komponenter med rettede versjoner, og en SBOM	Steder i koden med feilen og en foreslått retting

Du trenger begge. En kodebase uten SAST-funn kan fortsatt levere en sårbar avhengighet, og et rent avhengighetstre sier ingenting om din egen kode. Se SAST vs. SCA for hele sammenligningen. Én forskjell har betydning for hvordan du kjører dem: Et SAST-funn dukker opp når koden din endres, mens et SCA-funn kan dukke opp på en utgivelse du leverte for måneder siden, samme dag en ny advisory publiseres.

Her stopper SCA

Hvert SCA-resultat avhenger av første steg: å identifisere komponentene. En komponent verktøyet aldri identifiserte, kan ikke matches, prioriteres eller rettes, og den dukker heller ikke opp som et hull. De vanlige blindsonene:

• Det filene ikke sier. De fleste SCA-verktøy leser manifester og lockfiler. En manglende eller utdatert lockfile, pakker gjenopprettet fra CI-cacher, byggeverktøy, nedlastinger og installasjonsskript når aldri oversikten. Se hvorfor en lockfile ikke viser hva som ble levert.
• Verktøy er uenige. To skannere pekt mot samme commit gir ulike komponentlister, fordi hver har sine egne regler for hva som skal leses og hvordan det navngis. Se hva SBOM-generatorer med åpen kildekode går glipp av.
• Binærfiler. Programvare distribuert som en ferdigbygd binærfil deklarerer lite eller ingenting som en manifestleser kan se.
• Bare kjente sårbarheter. Matching finner det som er publisert. En ny ondsinnet pakke eller en ukjent feil har ingen advisory ennå.
• Et øyeblikksbilde. En skanning i en pull request beskriver det øyeblikket. Nye advisories for versjoner som allerede er i produksjon, krever noe som fortsetter å sjekke det som ble levert.

Dette er ikke en feil i ett produkt. Det er slik skanning fungerer, kommersiell eller åpen kildekode. CRACI har funnet sårbare pakker som Snyk og Aikido ikke rapporterte, fordi komponentene aldri var med i det de skannet.

Registrer bygget, behold SCA-verktøyet

CRACI tetter identifiseringshullet fra byggesiden. Det er en GitHub Actions-runner som registrerer hver pakke hver jobb henter, på alle nivåer i treet og inkludert pakker gjenopprettet fra CI-cacher, i en SBOM som angir sin egen fullstendighet. CRACI fortsetter å vurdere SBOM-ene for det som er levert, på nytt etter hvert som nye sårbarheter publiseres, og byggehistorikken viser hvilke tidligere bygg som inneholdt en sårbar pakke.

CRACI gjør ikke SAST eller reachability-analyse, og det er et bevisst valg. Team kjører det ved siden av et SCA- eller SAST-verktøy som dekker pull requests og deres egen kode. Se SCA-verktøy sammenlignet, hvor CRACI passer inn ved siden av SCA-verktøyene dine, eller book en demo for å sammenligne en registrert SBOM med den skanningen du har i dag.

Software composition analysis: ofte stilte spørsmål

Hva er SCA i cybersikkerhet?

Software composition analysis (SCA) er praksisen med å finne komponentene med åpen kildekode og fra tredjeparter i programvaren din og sjekke dem for kjente sårbarheter, lisensproblemer og utdaterte versjoner. Det dekker koden du er avhengig av, i motsetning til koden du skriver.

Hva er forskjellen på SCA og SAST?

SAST analyserer koden teamet ditt skriver, og leter etter feil som injection. SCA analyserer komponentene du er avhengig av, og leter etter kjente sårbarheter og lisensproblemer. De svarer på ulike spørsmål, så de fleste sikkerhetsprogrammer kjører begge.

Hva betyr SCA-skanning?

En SCA-skanning leser manifestene, lockfilene, de installerte pakkene eller container-imaget til et prosjekt, finner ut hvilke komponenter som inngår, og matcher dem mot sårbarhets- og lisensdata. Resultatet er en liste med funn, ofte med en SBOM over komponentene den identifiserte.

Er en SBOM det samme som SCA?

Nei. En SBOM er en oversikt: listen over komponenter i en utgivelse. SCA er analysen: å identifisere komponenter og sjekke dem for risiko. Mange SCA-verktøy produserer en SBOM underveis, og en SBOM kan mate sårbarhetsovervåking etter utgivelsen.

Hva er begrensningene ved SCA?

Det analyserer bare komponentene det kan identifisere, vanligvis fra manifester og lockfiler. Pakker gjenopprettet fra CI-cacher, byggeverktøy, nedlastinger og binærfiler uten pakkemetadata kan bli oversett. Det finner kjente sårbarheter, ikke ukjente, og en skanning er et øyeblikksbilde med mindre verktøyet fortsetter å sjekke det som ble levert.

Hva er de beste SCA-verktøyene?

Det avhenger av hva du trenger utover det grunnleggende: reachability-analyse, oppdagelse av ondsinnede pakker, lisenspolicy eller utviklerarbeidsflyt. Se sammenligningen vår av 13 SCA-verktøy for hva hvert dekker og hvor det stopper.