SCA-skanning

Vad som händer i en SCA-skanning

1. Läs målet. Skannern läser manifest och lockfiler som package-lock.json, poetry.lock eller Cargo.lock, eller packar upp en containeravbild.
2. Bygg komponentlistan. Den löser det den hittat till namn och versioner, oftast inklusive transitiva beroenden.
3. Matcha mot data. Varje komponent slås upp i källor som GitHub Advisory Database, OSV och NVD, och dess licens jämförs med din policy.
4. Rapportera. Fynden presenteras rangordnade efter allvarlighetsgrad, oftast med en åtgärdad version. I CI kan en policy få jobbet att misslyckas.

För den bredare disciplin som detta tillhör, se vad är software composition analysis.

Var du bör köra SCA-skanningar

En skanning på ett ställe lämnar luckor. Varje steg besvarar en egen fråga, så de flesta team kör fler än en.

Var	Vad den besvarar	Vad den missar
Utvecklarens dator eller IDE	Är det här paketet säkert att lägga till?	Allt som utvecklaren inte kör den på
Pull request	Tillför den här ändringen en känd risk?	Nya säkerhetsmeddelanden för kod som inte ändrats
CI-bygge	Vad innehåller releasen?	Allt som skannern inte kan se i bygget
Containerregister	Vad finns i den här avbilden?	Kompilerad kod och byggverktyg som inte lämnar spår
Efter release	Påverkas det vi levererat av något nytt?	Ingenting, om registreringen av vad som levererats är komplett

Den sista raden är den som de flesta säkerhetsprogram hoppar över. Ett nytt säkerhetsmeddelande berör en version du levererade för flera månader sedan, och ingen pull request kommer att utlösa en skanning för det.

Så läser du resultaten från en SCA-skanning

Den första skanningen av ett riktigt projekt ger ofta hundratals fynd. Gå igenom dem i den här ordningen:

1. Börja med det som utnyttjas. Ett fynd i CISA:s KEV-katalog går före en högre CVSS-poäng utan känd exploatering. Se så prioriterar du sårbarheter.
2. Kontrollera att det gäller dig. Beroenden som bara används i utveckling levereras inte. Vissa verktyg lägger till reachability-analys för att kontrollera om den sårbara koden över huvud taget kan anropas.
3. Åtgärda på rätt nivå. För ett transitivt fynd ligger åtgärden oftast i paketet som drar in det, vilket en beroendegraf visar.
4. Registrera vad du inte tänker åtgärda. Ett fynd som du beslutat att acceptera bör ange varför, annars gör nästa person om arbetet. VEX är standardsättet att registrera det.

Varför en ren skanning inte betyder ren programvara

• Den ser det som är deklarerat. En skanner läser filerna den har framför sig, så ett repo utan incheckad lockfile ger den lite att arbeta med, och kod som hämtas av en installationshook syns aldrig.
• Den ser det du pekade den mot. Basavbilden, byggverktygen och GitHub Actions i din pipeline ligger utanför applikationens manifest.
• Den känner bara till det som publicerats. Ett nytt skadligt paket har ännu inget säkerhetsmeddelande.
• Listan är inte bygget. Byggen löser versioner när de körs, så det som skanningen läste och det som releasen innehåller kan skilja sig åt.

Det här är begränsningar i själva skanningen, 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.

Gratis och kommersiella skannrar

Gratisalternativen täcker grunderna väl. Dependabot-varningar ingår i GitHub, OWASP Dependency-Check och Trivy har öppen källkod, och Grype fungerar ihop med SBOM-generatorn Syft. Kommersiella verktyg lägger till policy, prioritering, reachability och arbetsflöden över många team. De bästa SCA-verktygen i jämförelse täcker 13 av dem, och den här guiden visar varför gratis generatorer är oense med varandra.

SCA-skanning och registrering under bygget

CRACI är ingen skanner, och du behöver inte ge upp din. CRACI är en GitHub Actions-runner som registrerar varje paket som varje jobb hämtar, i alla led av beroendeträdet och inklusive paket som återställs från CI-cachar, och fortsätter sedan att omvärdera SBOM:erna för det som levererats när nya sårbarheter publiceras. Din skanner täcker pull requests och utvecklardatorer. CRACI täcker bygget och allt som kommer efter det. Se var CRACI passar in bredvid dina SCA-verktyg.

SCA-skanning: vanliga frågor

Vad är en SCA-skanning?

En SCA-skanning läser ett projekts manifest, lockfiler eller containeravbild, tar reda på vilka open source-komponenter det använder och kontrollerar dem mot sårbarhets- och licensdata.

Är SCA samma sak som beroendeskanning?

Nästan. Beroendeskanning betyder oftast att kontrollera beroenden mot kända sårbarheter. SCA är det bredare begreppet och omfattar även licenser, föråldrade paket och att ta fram en förteckning som en SBOM.

När bör SCA-skanningar köras?

På pull requests, för att stoppa nya risker; i CI-bygget, för att beskriva releasen; och löpande efter release, eftersom nya säkerhetsmeddelanden berör programvara du redan levererat.

Hur lång tid tar en SCA-skanning?

Oftast från några sekunder till några minuter, eftersom den läser metadata i stället för att analysera all din kod. Det gör den praktisk att köra på varje pull request.

Varför rapporterar SCA-skannrar olika resultat?

Var och en har egna regler för vad som ska läsas, hur komponenter namnges och vilka sårbarhetsdata som används. Samma commit kan ge olika komponentlistor och olika fynd.

Hittar SCA-skanning skadlig kod?

Matchning mot säkerhetsmeddelanden hittar skadliga releaser först när ett säkerhetsmeddelande finns. Verktyg som analyserar hur paket beter sig kan fånga vissa tidigare. Ett nytt skadligt paket har inget säkerhetsmeddelande den dag det dyker upp.