Vad är software composition analysis (SCA)? Så fungerar det

Så fungerar SCA

Identifiera komponenterna. Verktyget läser det du pekar det mot: manifest och lockfiler i ett repo, installerade paket eller innehållet i en containeravbild eller binär. Resultatet är en förteckning över komponenter och versioner, ofta exporterad som en SBOM.
Matcha dem mot kända risker. Varje komponent slås upp i sårbarhetsdatabaser som GitHub Advisory Database, OSV och NVD, och dess deklarerade licens jämförs med din policy.
Prioritera. Fynden rangordnas efter allvarlighetsgrad, och vissa verktyg lägger till reachability-analys för att kontrollera om din kod över huvud taget kan anropa den sårbara funktionen.
Åtgärda. Många verktyg föreslår en åtgärdad version eller öppnar en pull request, som Dependabot och Renovate gör. För ett sårbart transitivt beroende ligger åtgärden oftast i paketet som drar in det, vilket en beroendegraf visar.

Vad SCA hittar

Kända sårbarheter i de versioner du använder, med säkerhetsmeddelandena som beskriver dem.
Licensrisk, till exempel en copyleft-licens i en proprietär produkt.
Föråldrade och ounderhållna paket som inte kommer att få säkerhetsfixar.
Skadliga paket, i verktyg som också analyserar hur paket beter sig i stället för att bara matcha säkerhetsmeddelanden.

SCA vs SAST

SCA och statisk applikationssäkerhetstestning (SAST) säljs ofta tillsammans, men de tittar på olika kod och besvarar olika frågor.

	SCA	SAST
Vad det analyserar	Komponenterna från öppen källkod och tredje part som du är beroende av	Koden som ditt team skriver
Vad det hittar	Kända sårbarheter, licensproblem, föråldrade paket	Brister i din kod, som injektion eller osäker hantering av indata
Vad det läser	Manifest, lockfiler, installerade paket, avbilder eller binärer	Källkod
Vad som skapar ett nytt fynd	En ändring i beroendena, eller ett nytt säkerhetsmeddelande för en version du redan levererar	En ändring i din kod
Typiskt resultat	Sårbara komponenter med åtgärdade versioner, och en SBOM	Platser i koden med bristen och ett förslag på åtgärd

Du behöver båda. En kodbas utan SAST-fynd kan ändå leverera ett sårbart beroende, och ett rent beroendeträd säger ingenting om din egen kod. Se SAST vs SCA för hela jämförelsen. En skillnad spelar roll för hur du kör dem: ett SAST-fynd dyker upp när din kod ändras, medan ett SCA-fynd kan dyka upp på en release som du levererade för flera månader sedan, samma dag som ett nytt säkerhetsmeddelande publiceras.

Där SCA tar slut

Varje SCA-resultat beror på steg ett: att identifiera komponenterna. En komponent som verktyget aldrig identifierade kan inte matchas, prioriteras eller åtgärdas, och den syns inte heller som en lucka. De vanliga blinda fläckarna:

Det som filerna inte säger. De flesta SCA-verktyg läser manifest och lockfiler. En saknad eller inaktuell lockfile, paket som återställs från CI-cachar, byggverktyg, nedladdningar och installationsskript når aldrig förteckningen. Se varför en lockfile inte är en registrering av vad som levererades.
Verktygen är oense. Två skannrar som pekas mot samma commit ger olika komponentlistor, eftersom var och en har egna regler för vad som ska läsas och hur det ska namnges. Se vad SBOM-generatorer med öppen källkod missar.
Binärer. Programvara som distribueras som en förkompilerad binär deklarerar lite eller inget som en manifestläsare kan se.
Bara kända sårbarheter. Matchning hittar det som har publicerats. Ett nytt skadligt paket eller en ej offentliggjord brist har ännu inget säkerhetsmeddelande.
En ögonblicksbild. En skanning i en pull request beskriver just det ögonblicket. Nya säkerhetsmeddelanden för versioner som redan är i produktion kräver något som fortsätter att kontrollera det som levererats.

Det här är ingen brist i en enskild produkt. Det är så skanning fungerar, kommersiell eller med öppen källkod. CRACI har hittat sårbara paket som Snyk och Aikido inte rapporterade, eftersom komponenterna aldrig fanns i det de skannade.

Registrera bygget, behåll din SCA

CRACI täpper till identifieringsluckan från byggsidan. Det är en GitHub Actions-runner som registrerar varje paket som varje jobb hämtar, i alla led av trädet och inklusive paket som återställs från CI-cachar, i en SBOM som anger sin egen fullständighet. CRACI fortsätter att omvärdera SBOM:erna för det som levererats när nya sårbarheter publiceras, och bygghistoriken visar vilka tidigare byggen som innehöll ett sårbart paket.

CRACI gör inte SAST eller reachability-analys, och det är ett medvetet val. Team kör det bredvid ett SCA- eller SAST-verktyg som täcker pull requests och deras egen kod. Se SCA-verktyg i jämförelse, var CRACI passar in bredvid dina SCA-verktyg, eller boka en demo för att jämföra en registrerad SBOM med din nuvarande skanning.

Software composition analysis: vanliga frågor

Vad är SCA inom cybersäkerhet?

Software composition analysis (SCA) innebär att hitta komponenterna från öppen källkod och tredje part i din programvara och kontrollera om de har kända sårbarheter, licensproblem eller föråldrade versioner. Det täcker koden du är beroende av, till skillnad från koden du skriver.

Vad är skillnaden mellan SCA och SAST?

SAST analyserar koden ditt team skriver efter brister som injektionsbuggar. SCA analyserar komponenterna du är beroende av efter kända sårbarheter och licensproblem. De besvarar olika frågor, så de flesta säkerhetsprogram kör båda.

Vad betyder SCA-skanning?

En SCA-skanning läser ett projekts manifest, lockfiler, installerade paket eller en containeravbild, tar reda på vilka komponenter det innehåller och matchar dem mot sårbarhets- och licensdata. Resultatet är en lista med fynd, ofta med en SBOM över de komponenter den identifierade.

Är en SBOM samma sak som SCA?

Nej. En SBOM är en förteckning: listan över komponenterna i en release. SCA är analysen: att identifiera komponenter och kontrollera om de innebär risker. Många SCA-verktyg tar fram en SBOM på vägen, och en SBOM kan mata sårbarhetsbevakning efter releasen.

Vilka begränsningar har SCA?

Det analyserar bara de komponenter det kan identifiera, oftast från manifest och lockfiler. Paket som återställs från CI-cachar, byggverktyg, nedladdningar och binärer utan paketmetadata kan missas. Det hittar kända sårbarheter, inte okända, och en skanning är en ögonblicksbild om inte verktyget fortsätter att kontrollera det som levererats.

Vilka är de bästa SCA-verktygen?

Det beror på vad du behöver utöver grunderna: reachability-analys, upptäckt av skadliga paket, licenspolicy eller utvecklararbetsflöde. Se vår jämförelse av 13 SCA-verktyg för vad vart och ett täcker och var det tar slut.