SCA-scanning

Hvad der sker i en SCA-scanning

1. Læs målet. Scanneren læser manifester og lockfiles som package-lock.json, poetry.lock eller Cargo.lock eller pakker et container-image ud.
2. Opbyg komponentlisten. Den omsætter det, den fandt, til navne og versioner, som regel inklusive transitive afhængigheder.
3. Match dataene. Hver komponent slås op i kilder som GitHub Advisory Database, OSV og NVD, og dens licens sammenlignes med din politik.
4. Rapportér. Fund kommer ud rangeret efter alvorlighed, som regel med en rettet version. I CI kan en politik få jobbet til at fejle.

Se hvad er software composition analysis for den bredere praksis, det hører til.

Hvor du skal køre SCA-scanninger

Én scanning ét sted efterlader huller. Hvert stadie besvarer et andet spørgsmål, så de fleste teams kører mere end én.

Hvor	Hvad den besvarer	Hvad den overser
Udviklermaskine eller IDE	Er denne pakke sikker at tilføje?	Alt, hvad udvikleren ikke kører den på
Pull request	Tilføjer denne ændring en kendt risiko?	Nye advisories for kode, der ikke er ændret
CI-build	Hvad indeholder releasen?	Alt, hvad scanneren ikke kan se i buildet
Container-registry	Hvad er der i dette image?	Kompileret kode og build-værktøjer, der ikke efterlader spor
Efter release	Er det, vi har leveret, ramt af noget nyt?	Intet, hvis registreringen af det leverede er komplet

Den sidste række er den, de fleste sikkerhedsprogrammer springer over. En ny advisory rammer en version, du leverede for måneder siden, og ingen pull request vil udløse en scanning for den.

Sådan læser du resultaterne af en SCA-scanning

En første scanning af et rigtigt projekt giver ofte hundredvis af fund. Gå dem igennem i denne rækkefølge:

1. Start med det, der bliver udnyttet. Et fund i CISA's KEV-katalog slår en højere CVSS-score uden kendt udnyttelse. Se sådan prioriterer du sårbarheder.
2. Tjek, at det gælder. Afhængigheder, der kun bruges til udvikling, bliver ikke leveret. Nogle værktøjer tilføjer reachability-analyse for at tjekke, om den sårbare kode overhovedet kan kaldes.
3. Ret på det rigtige niveau. Ved et transitivt fund ligger rettelsen som regel i den pakke, der trækker det ind, og det viser en afhængighedsgraf.
4. Registrér, hvad du ikke vil rette. Et fund, du har besluttet at acceptere, bør sige hvorfor, ellers gentager den næste person arbejdet. VEX er standardmåden at registrere det på.

Derfor betyder en ren scanning ikke ren software

• Den ser det, der er deklareret. En scanner læser de filer, den har foran sig, så et repository uden committet lockfile giver den lidt at arbejde med, og kode hentet af et install-hook dukker aldrig op.
• Den ser det, du retter den mod. Base-imaget, build-værktøjerne og GitHub Actions i din pipeline er adskilt fra din applikations manifest.
• Den kender kun det, der er offentliggjort. En ny ondsindet pakke har endnu ingen advisory.
• Listen er ikke buildet. Builds resolver versioner, når de kører, så det, scanningen læste, og det, releasen indeholder, kan være forskelligt.

Det er begrænsninger ved selve scanningen, kommerciel eller open source. CRACI har fundet sårbare pakker, som Snyk og Aikido ikke rapporterede, fordi komponenterne aldrig var i det, de scannede.

Gratis og kommercielle scannere

Gratis muligheder dækker det grundlæggende godt. Dependabot-alarmer følger med GitHub, OWASP Dependency-Check og Trivy er open source, og Grype arbejder sammen med SBOM-generatoren Syft. Kommercielle værktøjer tilføjer politik, prioritering, reachability og workflow på tværs af mange teams. De bedste SCA-værktøjer sammenlignet dækker 13 af dem, og denne guide viser, hvorfor gratis generatorer er uenige med hinanden.

SCA-scanning og registrering under buildet

CRACI er ikke en scanner, og du behøver ikke at opgive din. 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, og derefter bliver ved med at genvurdere SBOM'erne for det leverede, efterhånden som nye sårbarheder offentliggøres. Din scanner dækker pull requests og udviklermaskiner. CRACI dækker buildet og alt derefter. Se hvor CRACI passer ind ved siden af dine SCA-værktøjer.

SCA-scanning: ofte stillede spørgsmål

Hvad er en SCA-scanning?

En SCA-scanning læser et projekts manifester, lockfiles eller container-image, finder ud af, hvilke open source-komponenter det bruger, og tjekker dem mod sårbarheds- og licensdata.

Er SCA det samme som dependency scanning?

Næsten. Dependency scanning betyder som regel, at afhængigheder tjekkes for kendte sårbarheder. SCA er den bredere betegnelse og dækker også licenser, forældede pakker og produktion af en fortegnelse som en SBOM.

Hvornår skal SCA-scanninger køre?

På pull requests for at stoppe nye risici, i CI-buildet for at beskrive releasen og løbende efter release, fordi nye advisories rammer software, du allerede har leveret.

Hvor lang tid tager en SCA-scanning?

Som regel fra sekunder til få minutter, fordi den læser metadata i stedet for at analysere al din kode. Derfor er det praktisk at køre den på hver pull request.

Hvorfor rapporterer SCA-scannere forskellige resultater?

Hver har sine egne regler for, hvad der skal læses, hvordan komponenter navngives, og hvilke sårbarhedsdata der bruges. Det samme commit kan give forskellige komponentlister og forskellige fund.

Finder SCA-scanning malware?

Matchning mod advisories finder først ondsindede releases, når der findes en advisory. Værktøjer, der analyserer pakkers adfærd, kan fange nogle tidligere. En ny ondsindet pakke har ingen advisory den dag, den dukker op.