SCA-skanning

Hva som skjer i en SCA-skanning

1. Leser målet. Skanneren leser manifester og lockfiler som package-lock.json, poetry.lock eller Cargo.lock, eller pakker ut et container-image.
2. Bygger komponentlisten. Den løser det den fant, til navn og versjoner, vanligvis inkludert transitive avhengigheter.
3. Matcher dataene. Hver komponent slås opp i kilder som GitHub Advisory Database, OSV og NVD, og lisensen sammenlignes med policyen din.
4. Rapporterer. Funn kommer ut rangert etter alvorlighetsgrad, vanligvis med en rettet versjon. I CI kan en policy få jobben til å feile.

Den bredere praksisen dette hører til, finner du i hva er software composition analysis.

Hvor du bør kjøre SCA-skanninger

Én skanning på ett sted etterlater hull. Hvert stadium svarer på et annet spørsmål, så de fleste team kjører flere.

Hvor	Hva den svarer på	Hva den går glipp av
Utviklermaskin eller IDE	Er denne pakken trygg å legge til?	Alt utvikleren ikke kjører den på
Pull request	Legger denne endringen til en kjent risiko?	Nye advisories for kode som ikke er endret
CI-bygg	Hva inneholder utgivelsen?	Det skanneren ikke kan se i bygget
Containerregister	Hva er i dette imaget?	Kompilert kode og byggeverktøy som ikke etterlater spor
Etter utgivelse	Er det vi leverte, berørt av noe nytt?	Ingenting, hvis oversikten over det som ble levert, er fullstendig

Den siste raden er den de fleste programmer hopper over. En ny advisory berører en versjon du leverte for måneder siden, og ingen pull request vil utløse en skanning for den.

Slik leser du resultatene av en SCA-skanning

En første skanning av et ekte prosjekt gir ofte hundrevis av funn. Gå gjennom dem i denne rekkefølgen:

1. Begynn med det som utnyttes. Et funn i KEV-katalogen til CISA går foran en høyere CVSS-score uten kjent utnyttelse. Se slik prioriterer du sårbarheter.
2. Sjekk at det gjelder. Avhengigheter som bare brukes i utvikling, leveres ikke. Noen verktøy legger til reachability-analyse for å sjekke om den sårbare koden i det hele tatt kan kalles.
3. Rett på riktig nivå. For et transitivt funn ligger rettingen vanligvis i pakken som trekker det inn, og det viser en avhengighetsgraf.
4. Registrer det du ikke vil rette. Et funn du har bestemt deg for å akseptere, bør si hvorfor, ellers gjentar neste person arbeidet. VEX er standardmåten å registrere det på.

Hvorfor en ren skanning ikke betyr ren programvare

• Den ser det som er deklarert. En skanner leser filene foran seg, så et repositorium uten committet lockfile gir den lite å jobbe med, og kode hentet av en installasjonshook dukker aldri opp.
• Den ser det du pekte den mot. Base-imaget, byggeverktøyene og GitHub Actions i pipelinen din er atskilt fra applikasjonens manifest.
• Den vet bare det som er publisert. En ny ondsinnet pakke har ingen advisory ennå.
• Listen er ikke bygget. Bygg løser versjoner når de kjører, så det skanningen leste og det utgivelsen inneholder, kan være forskjellig.

Dette er begrensninger ved selve skanningen, 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.

Gratis og kommersielle skannere

Gratisalternativene dekker det grunnleggende godt. Dependabot-varsler følger med GitHub, OWASP Dependency-Check og Trivy er åpen kildekode, og Grype fungerer sammen med SBOM-generatoren Syft. Kommersielle verktøy legger til policy, prioritering, reachability og arbeidsflyt på tvers av mange team. De beste SCA-verktøyene sammenlignet dekker 13 av dem, og denne guiden viser hvorfor gratis generatorer er uenige med hverandre.

SCA-skanning og registrering under bygget

CRACI er ikke en skanner, og du trenger ikke å gi opp din. 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, og som deretter fortsetter å vurdere SBOM-ene for det som er levert, på nytt etter hvert som nye sårbarheter publiseres. Skanneren din dekker pull requests og utviklermaskiner. CRACI dekker bygget og alt etter det. Se hvor CRACI passer inn ved siden av SCA-verktøyene dine.

SCA-skanning: ofte stilte spørsmål

Hva er en SCA-skanning?

En SCA-skanning leser manifestene, lockfilene eller container-imaget til et prosjekt, finner ut hvilke komponenter med åpen kildekode det bruker, og sjekker dem mot sårbarhets- og lisensdata.

Er SCA det samme som avhengighetsskanning?

Nesten. Avhengighetsskanning betyr vanligvis å sjekke avhengigheter for kjente sårbarheter. SCA er det bredere begrepet og dekker også lisenser, utdaterte pakker og produksjon av en oversikt som en SBOM.

Når bør SCA-skanninger kjøre?

På pull requests, for å stoppe nye risikoer; i CI-bygget, for å beskrive utgivelsen; og kontinuerlig etter utgivelse, fordi nye advisories berører programvare du allerede har levert.

Hvor lang tid tar en SCA-skanning?

Vanligvis fra sekunder til noen få minutter, fordi den leser metadata i stedet for å analysere all koden din. Det gjør det praktisk å kjøre den på hver pull request.

Hvorfor rapporterer SCA-skannere ulike resultater?

Hver har sine egne regler for hva som skal leses, hvordan komponenter navngis og hvilke sårbarhetsdata som brukes. Samme commit kan gi ulike komponentlister og ulike funn.

Finner SCA-skanning skadevare?

Matching mot advisories finner ondsinnede utgivelser først når det finnes en advisory. Verktøy som analyserer hvordan pakker oppfører seg, kan fange noen tidligere. En ny ondsinnet pakke har ingen advisory den dagen den dukker opp.