SAST vs. SCA

Erot yhdellä silmäyksellä

	SAST	SCA
Lyhenne tulee sanoista	Static application security testing (sovellusten staattinen tietoturvatestaus)	Software composition analysis (ohjelmistokoostumuksen analyysi)
Tarkastelee	Omaa lähdekoodiasi	Avoimen lähdekoodin ja kolmansien osapuolten komponentteja
Löytää	Injektiot, syötteiden turvattoman käsittelyn, turvattomat koodimallit	Tunnetut haavoittuvuudet, lisenssiongelmat, vanhentuneet paketit
Perustuu	Sääntöihin tai malleihin siitä, miltä huono koodi näyttää	Julkaistujen tietoturvatiedotteiden tietokantoihin
Löydös syntyy, kun	Koodisi muuttuu	Riippuvuus muuttuu tai uusi tietoturvatiedote julkaistaan
Tyypillinen kohina	Vääriä hälytyksiä koodista, joka on todellisuudessa turvallista	Todellisia osumia, jotka eivät vaikuta siihen, miten käytät pakettia
Korjaus	Muuta koodiasi	Päivitä tai vaihda komponentti

Mitä SAST tekee

SAST-työkalu lukee lähdekoodia ajamatta sitä ja seuraa, miten data kulkee sen läpi. Jos käyttäjän syöte päätyy tietokantakyselyyn puhdistamatta, se ilmoittaa tiedoston ja rivin. Koska se käsittelee omaa koodiasi, se voi löytää virheitä, joita kukaan ei ole koskaan julkaissut. Siitä johtuvat myös valitukset vääristä hälytyksistä, sillä se päättelee, mitä koodi saattaisi tehdä, eikä sitä, mitä se todella tekee.

Mitä SCA tekee

SCA-skannaus tunnistaa projektin komponentit ja hakee niitä haavoittuvuus- ja lisenssitiedoista. Se ei analysoi sovelluslogiikkaasi. Se tietää, että versiossa on julkaistu virhe, joten sen tulokset ovat yleensä tosiasioita, mutta se kertoo vähemmän siitä, koskeeko virhe sinua, ellei työkalu lisää reachability-analyysia. Kokonaiskuvan saat sivulta mitä ohjelmistokoostumuksen analyysi on.

Miksi tarvitset molemmat

Nämä kaksi puutetta ovat toisistaan riippumattomia. Koodikanta, jossa ei ole yhtään SAST-löydöstä, voi silti sisältää haavoittuvan riippuvuuden, eikä puhdas riippuvuuspuu kerro mitään SQL-injektiosta omassa käsittelijässäsi.

Myös ajoitus eroaa. SAST-löydös syntyy, kun joku muuttaa koodia, joten pull requestin tarkistus havaitsee suurimman osan niistä. SCA-löydös voi ilmaantua kuukausia sitten toimittamaasi julkaisuun sinä päivänä, kun uusi tietoturvatiedote julkaistaan, ilman yhtäkään committia, joka käynnistäisi mitään. SCA tarvitsee siksi jotain, joka tarkistaa jatkuvasti, mitä on toimitettu.

Mihin DAST sijoittuu

Dynaaminen sovellusten tietoturvatestaus (DAST) hyökkää käynnissä olevaan sovellukseen ulkopuolelta, kuten oikea hyökkääjä tekisi. Se löytää ongelmat, jotka näkyvät vasta ajon aikana, kuten tunnistautumisen ja konfiguraation ongelmat, lukematta koodia.

	SAST	SCA	DAST
Tarvitsee	Lähdekoodin	Manifestit, kuvat tai buildin tallenteen	Käynnissä olevan sovelluksen
Ajetaan	Pull requesteissa	Pull requesteissa, buildeissa ja julkaisun jälkeen	Testiympäristöä vastaan
Vahvimmillaan	Oman koodisi virheissä	Riippuvuuksien tunnetuissa riskeissä	Ajonaikaisissa ja konfiguraatiovirheissä

Kumpi kannattaa ajaa ensin?

Useimmille tiimeille SCA. Se on nopea ottaa käyttöön, se valmistuu sekunneissa tai minuuteissa ja kattaa suurimman osan siitä, mitä toimitat, koska nykyaikainen sovellus koostuu pääosin riippuvuuksista. Lisää seuraavaksi SAST pull requesteihin ja säädä se sääntöihin, joilla on merkitystä teknologiapinollesi. Lisää DAST, kun sinulla on vakaa testiympäristö, jota vastaan sitä voi ajaa.

Yksi alusta vai useita työkaluja?

Alustat kuten Snyk, Checkmarx ja GitHub Advanced Security niputtavat SAST:n ja SCA:n, mikä tarkoittaa yhtä sopimusta ja yhtä työnkulkua. Erilliset työkalut voivat olla vahvempia kummallakin alueella. Tärkeämpää on kuitenkin syöte: molemmat skannerityypit toimivat sen pohjalta, mitä on ilmoitettu tai kirjoitettu, eikä kumpikaan näe, mitä buildi todella haki.

Mitä kumpikaan ei kata

SAST ja SCA lukevat molemmat tiedostoja. Kumpikaan ei tarkkaile buildia, joten asennuskoukun hakema koodi, CI-välimuisteista palautetut paketit ja itse build-työkalut voivat jäädä näkymättä. Juuri tästä aukosta ohjelmistotoimitusketjun tietoturvassa on kyse.

CRACI kattaa tämän osan ja jättää koodin skannauksen siihen tehdyille työkaluille. Se ei tee SAST-analyysia eikä salaisuuksien skannausta, tarkoituksella, ja monet erinomaiset SAST-työkalut toimivat sen rinnalla. Se on GitHub Actions -runneri, joka tallentaa SBOM:iin, mitä kukin jobi hakee, ja tarkistaa jatkuvasti toimitettujen versioiden SBOM:t uusia haavoittuvuuksia vastaan. Katso parhaat SCA-työkalut ja mihin CRACI sijoittuu niiden rinnalla.

SAST vs. SCA: usein kysytyt kysymykset

Mitä eroa on SAST:lla ja SCA:lla?

SAST analysoi tiimisi kirjoittamaa koodia esimerkiksi injektioiden kaltaisten virheiden varalta. SCA analysoi avoimen lähdekoodin ja kolmansien osapuolten komponentit, joista olet riippuvainen, tunnettujen haavoittuvuuksien ja lisenssiongelmien varalta.

Korvaako SCA SAST:n?

Ei. Ne tarkastelevat eri koodia. SCA ei löydä virhettä omasta logiikastasi, eikä SAST kerro, että riippuvuudessa on julkaistu haavoittuvuus.

Mitä eroa on SAST:lla, DAST:lla ja SCA:lla?

SAST lukee lähdekoodiasi. SCA tarkistaa riippuvuutesi. DAST testaa käynnissä olevaa sovellusta ulkopuolelta. Kukin löytää ongelmia, jotka kaksi muuta ohittavat.

Onko Snyk SAST vai SCA?

Molempia. Snyk aloitti avoimen lähdekoodin riippuvuuksien skannauksesta ja tarjoaa myös SAST:n sekä konttien ja infrastruktuurikoodin (IaC) skannauksen.

Onko SonarQube SAST vai SCA?

SonarQube tunnetaan parhaiten oman koodisi staattisesta analyysista, eli SAST:sta. Tarkista nykyisistä versioista, mitä muuta ne sisältävät.

Kumpi ensin, SAST vai SCA?

SCA on yleensä nopeampi voitto, koska se on helppo ottaa käyttöön ja kattaa suurimman osan siitä, mitä toimitat. SAST vaatii enemmän säätämistä, jotta väärät hälytykset pysyvät kurissa.