Hvad er software composition analysis (SCA)?

Sådan virker SCA

1. Identificér komponenterne. Værktøjet læser det, det bliver rettet mod: manifester og lockfiles i et repository, installerede pakker eller indholdet af et container-image eller en binærfil. Resultatet er en fortegnelse over komponenter og versioner, ofte eksporteret som en SBOM.
2. Match dem mod kendte risici. Hver komponent slås op i sårbarhedsdatabaser som GitHub Advisory Database, OSV og NVD, og dens deklarerede licens tjekkes mod din politik.
3. Prioritér. Fund rangeres efter alvorlighed, og nogle værktøjer tilføjer reachability-analyse for at tjekke, om din kode overhovedet kan kalde den sårbare funktion.
4. Ret. Mange værktøjer foreslår en rettet version eller åbner en pull request, sådan som Dependabot og Renovate gør. Ved en sårbar transitiv afhængighed ligger rettelsen som regel i den pakke, der trækker den ind, og det viser en afhængighedsgraf.

Hvad SCA finder

• Kendte sårbarheder i de versioner, du bruger, med de advisories, der beskriver dem.
• Licensrisiko, for eksempel en copyleft-licens i et proprietært produkt.
• Forældede og uvedligeholdte pakker, der ikke vil få sikkerhedsrettelser.
• Ondsindede pakker, i værktøjer, der også analyserer, hvordan pakker opfører sig, og ikke kun matcher advisories.

SCA vs. SAST

SCA og statisk applikationssikkerhedstest (SAST) sælges ofte sammen, men de ser på forskellig kode og besvarer forskellige spørgsmål.

	SCA	SAST
Hvad det analyserer	De open source- og tredjepartskomponenter, du er afhængig af	Den kode, dit team skriver
Hvad det finder	Kendte sårbarheder, licensproblemer, forældede pakker	Fejl i din kode, for eksempel injection eller usikker håndtering af input
Hvad det læser	Manifester, lockfiles, installerede pakker, images eller binærfiler	Kildekode
Hvad der gør et fund nyt	En ændring i afhængighederne eller en ny advisory for en version, du allerede leverer	En ændring i din kode
Typisk output	Sårbare komponenter med rettede versioner og en SBOM	Steder i koden med fejlen og et forslag til rettelse

Du har brug for begge dele. En kodebase uden SAST-fund kan stadig levere en sårbar afhængighed, og et rent afhængighedstræ siger intet om din egen kode. Se SAST vs. SCA for den fulde sammenligning. Én forskel betyder noget for, hvordan du kører dem: Et SAST-fund dukker op, når din kode ændres, mens et SCA-fund kan dukke op på en release, du leverede for måneder siden, den dag en ny advisory offentliggøres.

Hvor SCA stopper

Alle SCA-resultater afhænger af trin ét: at identificere komponenterne. En komponent, værktøjet aldrig identificerede, kan ikke matches, prioriteres eller rettes, og den dukker heller ikke op som et hul. De almindelige blinde vinkler:

• Det, filerne ikke siger. De fleste SCA-værktøjer læser manifester og lockfiles. En manglende eller forældet lockfile, pakker gendannet fra CI-caches, build-værktøjer, downloads og install-scripts ender aldrig i fortegnelsen. Se hvorfor en lockfile ikke er en registrering af det leverede.
• Værktøjer er uenige. To scannere, der rettes mod det samme commit, returnerer forskellige komponentlister, fordi hver har sine egne regler for, hvad der skal læses, og hvordan det skal navngives. Se hvad open source-SBOM-generatorer overser.
• Binærfiler. Software, der distribueres som en færdigbygget binærfil, deklarerer lidt eller intet, som en manifestlæser kan se.
• Kun kendte sårbarheder. Matchning finder det, der er offentliggjort. En ny ondsindet pakke eller en ikke-offentliggjort fejl har endnu ingen advisory.
• Et øjebliksbillede. En scanning i en pull request beskriver det øjeblik. Nye advisories for versioner, der allerede er i produktion, kræver noget, der bliver ved med at tjekke det leverede.

Det er ikke en fejl i ét produkt. Det er sådan, scanning virker, kommerciel eller open source. CRACI har fundet sårbare pakker, som Snyk og Aikido ikke rapporterede, fordi komponenterne aldrig var i det, de scannede.

Registrér buildet, behold din SCA

CRACI lukker identifikationshullet fra build-siden. Det er en GitHub Actions-runner, der registrerer hver pakke, hvert job henter, i alle lag af træet og inklusive pakker gendannet fra CI-caches, i en SBOM, der angiver sin egen fuldstændighed. Det bliver ved med at genvurdere SBOM'erne for det leverede, efterhånden som nye sårbarheder offentliggøres, og build-historikken viser, hvilke tidligere builds der indeholdt en sårbar pakke.

CRACI laver bevidst ikke SAST eller reachability-analyse. Teams kører det ved siden af et SCA- eller SAST-værktøj, der dækker pull requests og deres egen kode. Se SCA-værktøjer sammenlignet, hvor CRACI passer ind ved siden af dine SCA-værktøjer, eller book en demo for at sammenligne en registreret SBOM med din nuværende scanning.

Software composition analysis: ofte stillede spørgsmål

Hvad er SCA inden for cybersikkerhed?

Software composition analysis (SCA) er praksissen med at finde open source- og tredjepartskomponenterne i din software og tjekke dem for kendte sårbarheder, licensproblemer og forældede versioner. Det dækker den kode, du er afhængig af, i modsætning til den kode, du skriver.

Hvad er forskellen på SCA og SAST?

SAST analyserer den kode, dit team skriver, for fejl som injection-bugs. SCA analyserer de komponenter, du er afhængig af, for kendte sårbarheder og licensproblemer. De besvarer forskellige spørgsmål, så de fleste sikkerhedsprogrammer kører begge.

Hvad betyder SCA-scanning?

En SCA-scanning læser et projekts manifester, lockfiles, installerede pakker eller et container-image, finder ud af, hvilke komponenter det indeholder, og matcher dem mod sårbarheds- og licensdata. Resultatet er en liste over fund, ofte med en SBOM af de komponenter, den identificerede.

Er en SBOM det samme som SCA?

Nej. En SBOM er en fortegnelse: listen over komponenter i en release. SCA er analysen: at identificere komponenter og tjekke dem for risiko. Mange SCA-værktøjer producerer en SBOM undervejs, og en SBOM kan fodre sårbarhedsovervågning efter releasen.

Hvad er begrænsningerne ved SCA?

Det analyserer kun de komponenter, det kan identificere, som regel ud fra manifester og lockfiles. Pakker gendannet fra CI-caches, build-værktøjer, downloads og binærfiler uden pakkemetadata kan blive overset. Det finder kendte sårbarheder, ikke ukendte, og en scanning er et øjebliksbillede, medmindre værktøjet bliver ved med at tjekke det leverede.

Hvad er de bedste SCA-værktøjer?

Det afhænger af, hvad du har brug for ud over det grundlæggende: reachability-analyse, detektion af ondsindede pakker, licenspolitik eller workflow for udviklere. Se vores sammenligning af 13 SCA-værktøjer for, hvad hvert af dem dækker, og hvor det stopper.