SCA-skannaus

Mitä SCA-skannauksessa tapahtuu

1. Kohteen luku. Skanneri lukee manifestit ja lukitustiedostot (lockfile), kuten package-lock.json, poetry.lock tai Cargo.lock, tai purkaa konttikuvan.
2. Komponenttiluettelon kokoaminen. Se muuntaa löytämänsä nimiksi ja versioiksi, yleensä myös transitiiviset riippuvuudet.
3. Tietojen vertailu. Jokainen komponentti haetaan lähteistä, kuten GitHub Advisory Database, OSV ja NVD, ja sen lisenssiä verrataan käytäntöösi.
4. Raportointi. Löydökset listataan vakavuuden mukaan, yleensä korjatun version kanssa. CI:ssä käytäntö voi kaataa jobin.

Laajemmasta käytännöstä, johon tämä kuuluu, kerrotaan sivulla mitä on ohjelmistokoostumuksen analyysi.

Missä SCA-skannaukset kannattaa ajaa

Yksi skannaus yhdessä paikassa jättää aukkoja. Jokainen vaihe vastaa eri kysymykseen, joten useimmat tiimit ajavat useamman kuin yhden.

Missä	Mihin se vastaa	Mikä siltä jää näkemättä
Kehittäjän kone tai IDE	Onko tämä paketti turvallista lisätä?	Kaikki, missä kehittäjä ei sitä aja
Pull request	Tuoko tämä muutos tunnetun riskin?	Uudet tietoturvatiedotteet koodista, joka ei muuttunut
CI-buildi	Mitä julkaisu sisältää?	Kaikki, mitä skanneri ei buildissa näe
Konttirekisteri	Mitä tässä kuvassa on?	Käännetty koodi ja build-työkalut, joista ei jää jälkeä
Julkaisun jälkeen	Koskeeko jokin uusi sitä, mitä toimitimme?	Ei mitään, jos tieto toimitetusta on kattava

Viimeinen rivi on se, jonka useimmat ohjelmat ohittavat. Uusi tietoturvatiedote koskee versiota, jonka toimitit kuukausia sitten, eikä mikään pull request käynnistä skannausta sen vuoksi.

Miten SCA-skannauksen tuloksia luetaan

Oikean projektin ensimmäinen skannaus tuottaa usein satoja löydöksiä. Käy ne läpi tässä järjestyksessä:

1. Aloita siitä, mitä hyödynnetään. Löydös, joka on CISA:n KEV-luettelossa, menee korkeamman CVSS-pistemäärän edelle, jos sen hyödyntämisestä ei tiedetä. Lue miten haavoittuvuuksia priorisoidaan.
2. Tarkista, että se koskee sinua. Pelkät kehitysaikaiset riippuvuudet eivät päädy toimitukseen. Jotkin työkalut lisäävät reachability-analyysin, joka tarkistaa, voidaanko haavoittuvaa koodia ylipäätään kutsua.
3. Korjaa oikealla tasolla. Transitiivisen löydöksen korjaus on yleensä paketissa, joka vetää sen mukaan, ja sen näyttää riippuvuusgraafi.
4. Kirjaa, mitä et korjaa. Hyväksytyn löydöksen kohdalla pitää lukea, miksi, tai seuraava tekee saman työn uudelleen. VEX on vakiintunut tapa kirjata se.

Miksi puhdas skannaus ei tarkoita puhdasta ohjelmistoa

• Se näkee sen, mitä on ilmoitettu. Skanneri lukee edessään olevat tiedostot, joten repositorio, johon ei ole commitoitu lukitustiedostoa, antaa sille vähän työstettävää, eikä asennuskoukun hakema koodi näy koskaan.
• Se näkee sen, mihin sen osoitit. Peruskuva, build-työkalut ja CI/CD-putkesi GitHub Actions ovat erillään sovelluksesi manifestista.
• Se tietää vain sen, mitä on julkaistu. Uudella haitallisella paketilla ei ole vielä tietoturvatiedotetta.
• Luettelo ei ole buildi. Buildit ratkaisevat versiot ajon aikana, joten se, mitä skannaus luki, ja se, mitä julkaisu sisältää, voivat poiketa toisistaan.

Nämä ovat itse skannauksen rajoja, oli työkalu kaupallinen tai avointa lähdekoodia. CRACI on löytänyt haavoittuvia paketteja, joita Snyk ja Aikido eivät raportoineet, koska komponentit eivät koskaan olleet siinä, mitä ne skannasivat.

Ilmaiset ja kaupalliset skannerit

Ilmaiset vaihtoehdot kattavat perusasiat hyvin. Dependabot-hälytykset tulevat GitHubin mukana, OWASP Dependency-Check ja Trivy ovat avointa lähdekoodia, ja Grype toimii yhdessä Syft-SBOM-generaattorin kanssa. Kaupalliset työkalut tuovat käytännöt, priorisoinnin, reachability-analyysin ja työnkulut monelle tiimille. Parhaat SCA-työkalut vertailussa käy läpi 13 niistä, ja tämä opas näyttää, miksi ilmaiset generaattorit ovat keskenään eri mieltä.

SCA-skannaus ja buildin aikainen tallennus

CRACI ei ole skanneri, eikä sinun tarvitse luopua omastasi. Se on GitHub Actions -runneri, joka tallentaa jokaisen paketin, jonka kukin jobi hakee, puun jokaisella syvyydellä ja myös CI-välimuisteista palautetut paketit, ja arvioi sen jälkeen toimitettujen versioiden SBOM:t jatkuvasti uudelleen, kun uusia haavoittuvuuksia julkaistaan. Skannerisi kattaa pull requestit ja kehittäjien koneet. CRACI kattaa buildin ja kaiken sen jälkeen. Lue miten CRACI sopii SCA-työkalujesi rinnalle.

SCA-skannaus: usein kysytyt kysymykset

Mikä on SCA-skannaus?

SCA-skannaus lukee projektin manifestit, lukitustiedostot tai konttikuvan, selvittää, mitä avoimen lähdekoodin komponentteja se käyttää, ja tarkistaa ne haavoittuvuus- ja lisenssitietoja vasten.

Onko SCA sama asia kuin riippuvuuksien skannaus?

Melkein. Riippuvuuksien skannaus tarkoittaa yleensä riippuvuuksien tarkistamista tunnettujen haavoittuvuuksien varalta. SCA on laajempi termi, ja se kattaa myös lisenssit, vanhentuneet paketit ja inventaarion, kuten SBOM:n, tuottamisen.

Milloin SCA-skannauksia pitäisi ajaa?

Pull requesteissa, jotta uudet riskit eivät pääse sisään; CI-buildissa, jotta julkaisu tulee kuvatuksi; ja jatkuvasti julkaisun jälkeen, koska uudet tietoturvatiedotteet koskevat jo toimittamaasi ohjelmistoa.

Kuinka kauan SCA-skannaus kestää?

Yleensä sekunneista muutamaan minuuttiin, koska se lukee metatietoja eikä analysoi koko koodiasi. Siksi sen ajaminen jokaisessa pull requestissa on käytännöllistä.

Miksi SCA-skannerit raportoivat eri tuloksia?

Jokaisella on omat sääntönsä sille, mitä lukea, miten komponentit nimetään ja mitä haavoittuvuustietoja käytetään. Sama commit voi tuottaa eri komponenttiluettelot ja eri löydökset.

Löytääkö SCA-skannaus haittaohjelmia?

Tietoturvatiedotteisiin perustuva vertailu löytää haitalliset julkaisut vasta, kun tiedote on olemassa. Työkalut, jotka analysoivat pakettien käyttäytymistä, voivat havaita osan aiemmin. Uudella haitallisella paketilla ei ole tiedotetta sinä päivänä, kun se ilmestyy.