Tarkvara tarneahela rünnakud on muutumas üha levinumaks ja laastavamaks. Näiteks Gartner ennustab, et 45% kõigist ettevõtetest kogeb 2025. aastaks rikkumist. Lisaks Küberturvalisuse ettevõtmised rõhutab selle ohu tõsidust, prognoosides 2031. aastaks vapustavat 138 miljardi dollari suurust aastast kahju. Kokkuvõttes rõhutavad need prognoosid organisatsioonide pakilist vajadust seada prioriteediks software supply chain security ja rakendama tugevaid meetmeid tundlike andmete, toimingute ja maine kaitsmiseks.
Sest moodne pipelinesõltuvad suuresti välistest komponentidest, kolmandate osapoolte teekide esiletõus, kiiremad tarkvaraarendustsüklid, keerulised tarneahelad, nähtavuse puudumine, uued rünnakutehnikad, SaaS-i kasutuselevõtt ja piiratud ressursid on kõik selle hüppelise kasvu põhjuseks. tarkvara tarneahela rünnakudSeetõttu peavad organisatsioonid nende väljakutsetega tegelemiseks ja oma tarkvara tarneahelate kaitsmiseks võtma kasutusele tervikliku ja aktiivse lähenemisviisi.
Mis on tarkvara tarneahela rünnak?
ENISA määratleb Tarkvara tarneahela rünnak as „Konkreetse vara, nt tarkvarapakkuja infrastruktuuri ja kommertstarkvara ohtu seadmine, et kaudselt kahjustada teatud sihtmärki või sihtmärke, nt tarkvarapakkuja kliente.“ Teisisõnu, tarkvara tarneahela rünnak on pahatahtlik tegevus, mis on suunatud tarkvara tarneahelale, eesmärgiga kahjustada ja sisestada haavatavusi või pahavara arendus- ja levitamisprotsessi. Selle tulemusena kasutab seda tüüpi rünnak ära omavahel ühendatud ja sageli keerulist protsesside, tööriistade ja üksuste võrgustikku, mis on seotud tarkvara loomise ja tarnimisega.
Tarkvara tarneahela rünnakuga seotud põhikomponendid ja kontseptsioonid
Küberohtude luure ja infoturbe kirjandus sageli ebaõnnestub tarkvara tarneahela rünnakud parema analüüsi ja kaitsmise eesmärgil eraldi kategooriatesse. Sellest tulenevalt tutvustatakse selles osas viit põhimõistet, mille on määratlenud MITRE rünnakumustrite kataloogSee kataloog struktureerib tarneahela rünnakute mustreid, et hõlbustada analüüsi, kasutades erinevaid allikaid, sealhulgas NISTi kogutud vaenlase ohte.
Rünnakuseadus: Mis
Rünnakuakt on konkreetne tegevus, mis edastab süsteemile pahatahtliku sisu või kavatsuse. Selle tulemusel tekitab see otsest kahju.
- Näide 1: Süsteemitarkvarasse installitud pahavara ehitusprotsessi ajal.
- Näide 2: Süsteeminõudeid või kujundusdokumente on pahatahtlikult muudetud.
Rünnakuvektor: kuidas
Rünnakuvektor on meetod, mida vastased kasutavad haavatavuste või protsesside nõrkuste ärakasutamiseks. Seega näitab see, kuidas ründajad rünnakupinnale ligi pääsevad ja seda kuritarvitavad.
- Näide 1: Ründaja muudab ohustatud repositooriumi lähtekoodi.
- Näide 2: Ründaja saab volitamata juurdepääsu sisemisele tehnilisele dokumentatsioonile.
Avasta lähemalt meie Rünnaku vektori sõnastik lisateabe saamiseks.
Rünnaku päritolu: The Who
Päritolu tuvastab rünnaku allika. Seega selgitab see ründaja rolli, staatust või suhet süsteemiga.
- Näide 1: Siseringi isik, kellel on privilegeeritud juurdepääs serverite loomisele, muudab skripti.
- Näide 2: Väline ohutegija laadib avalikku registrisse üles troojalase paketi.
Rünnaku eesmärk: miks
Eesmärk selgitab rünnaku taga olevat põhjust. Ennekõike toob see esile, mida vastased saavutada soovivad.
- Häired: teenuste või ehitustööde peatamine.
- Korruptsioon: usalduse vähendamine artefaktide või lähtekoodi muutmise teel.
- Avalikustamine: tundlike saladuste või intellektuaalomandi lekitamine.
Rünnaku mõju: tagajärjed
Lõpuks kirjeldab mõju rünnaku tulemusi, näidates tagajärgi tarkvarapakkujatele ja klientidele.
- Näide 1: Iga projekt, mis kasutab halba programmi, rikneb hiljem.
- Näide 2: Inimesed installivad oma töösüsteemidesse halba tarkvara seda teadmata.
Kõige levinumad tarkvara tarneahela rünnakud
Arvukalt tüüpe tarkvara tarneahela rünnakud olemas ja organisatsioonid peavad olema teadlikud erinevatest ohuvektoritest elutsükli igas etapis. Põhineb SLSA raamistik, USA Riiklik Instituut Standards ja tehnoloogia (NIST)ja Küberturvalisuse ja infrastruktuuri turvalisuse amet (CISA), saab need ohud jagada nelja kategooriasse: lähtekoodi-, ehitus-, paketi- ja sõltuvusriskid.
Tarkvara tarneahela rünnakud lähtekoodi etapis
- Esita vigane kood → vaata kuidas Kolvipäring.get väärkasutamine or ebakindlad deserialiseerimise vead luua otseseid rünnakupindu.
- Kompromiteeritud allika repositoorium
- Ehita muudetud lähtekoodist
- Kirjutage ebaturvalist koodi
- Kriitiliste failide võltsimine → nagu on selgitatud jaotises chmod 777 tagaukse analüüs.
Tarkvara tarneahela rünnakud ehitusetapis
aasta Ehitamise etapp, arendajad kompileerivad ja integreerivad koodi toimivaks versiooniks. Sest See etapp on nii kriitiline, et riskide hulka kuulub turvakontrolli vahelejätmine CI/CD pipeline, koodi muutmine pärast versioonikontrolli või ehitusprotsessi ohtu seadmine. Järelikult, pahatahtlik kood võib märkamatult artefaktidesse hiilida.
- Bypass CI/CD → seotud GitHubi eelinstallitud pahavara.
- Koodi muutmine pärast versioonikontrolli
- Kompromiteeritud ehitusprotsess → leevendatud DevSecOpsi varajane hoiatustuvastus.
- Kompromiteeritud artefaktide hoidla
Tarkvara tarneahela rünnakud paketi etapis
. Paketi etapp on see, kui paneme kogu koodi kokku lõpptoote loomiseks. See osa on riskantne, sest keegi võib kasutada halbu pakette või muuta veebikohti, kust me neid saame. Ründajad saavad neile veebisaitidele üles laadida isegi populaarsete pakettide kahjulikke versioone.
- Kasutage kahjustatud paketti → kaetud pahavara skänneri hinnangud.
- Pakettide kompromiteerimise register
- Laadi üles muudetud pakett → analüüsitakse Namso-gen võltsgeneraatori pahavara.
Tarkvara tarneahela rünnakud sõltuvusetapis
aasta Sõltuvuse etapp, lisame oma tarkvarale kolmandate osapoolte teeke ja pakette. See etapp on riskantne, sest kõik probleemid nendes osades võivad kergesti ja vaikselt levida ülejäänud projekti.
- Kasuta kahjustatud sõltuvust → selgitatud koos DoS-riskid hägustatud sõltuvustes.
- Aegunud või haavatavad sõltuvused
- Transitiivse sõltuvuse riskid
- Pahatahtlike pakettide registrid → leevendatud DevOpsi turvatööriistad ja kolmanda osapoole riskijuhtimine.
Tarneahela iga etapi tavalised riskid SDLC
| Stage | Tüüpilised ohud | Näide |
|---|---|---|
| allikas | • Pahatahtliku või ebaturvalise koodi esitamine • Oluliste failidega manipuleerimine • Allikahoidla ohtu seadmine | XcodeGhost (2015): Apple'i Xcode'i kompilaatorisse süstitud pahatahtlik kood levib iOS-i rakendustes. |
| Ehitama | • Möödasõit CI/CD turvakontrollid • Koodi muutmine pärast versioonikontrolli • Artefaktide hoidlate kahjustamine | SolarWinds Orion (2020): ründajad tungisid hoonesse pipeline, tagaukse lisamine allkirjastatud tarkvarauuendustesse. |
| Pakend | • Muudetud pakettide üleslaadimine • Mürgistuspakendi registrid • Ohustatud esemete levitamine | EventStreami NPM (2018): Ründaja sisestas tagaukse populaarsesse NPM-paketti, mida oli tuhandeid kordi alla laaditud. |
| Sõltuvus | • Vananenud või haavatavate sõltuvuste kasutamine • Transitiivsete sõltuvuste ärakasutamine • Pahatahtlike sarnaste pakettide avaldamine | XZ Utilsi tagauks (2024): troojalaste poolt nakatatud tihendusraamatukogu peaaegu saadeti Linuxi distributsioonidesse allavoolu. |
Levinud tarkvara tarneahela rünnakutehnikad
Vastavalt CISA ja NISTi aruande kohaselt jagunevad tarkvara tarneahela rünnakud sageli kolme põhikategooriasse.
Hiljutised intsidendid näitavad aga täiendavaid vektoreid, millest arendajad peavad aru saama.
Allpool käsitleme praktiliste näidete abil kõige olulisemaid tehnikaid.
Kaaperdamise värskendused
Ründajad kahjustavad pahavara levitamiseks seaduslikke uuendusmehhanisme.
Näiteks 2017. aasta NotPetya rünnak kuritarvitas Ukraina MEDoc maksutarkvara uuendusserverit, edastades
hävitav puhasti pahavara, mis on maskeeritud plaastriks. Selle riski eest kaitsmiseks peaksid meeskonnad rakendama DevOpsi ohtude tuvastamine ja reageerimine tavad, mis märgistavad värskendusvoogudes anomaalset käitumist.
Koodiallkirjastamise õõnestamine
See tehnika hõlmab kehtivate allkirjastamissertifikaatide kuritarvitamist või varastamist, et pahatahtlik kood näiks olevat seaduslik.
Märkimisväärne juhtum oli CCleaneri rünnak 2017. aastal, kus ründajad levitasid kehtivate sertifikaatidega allkirjastatud trooja nakatatud tarkvara.
Seetõttu vajavad organisatsioonid ühtseid terviklikkuse kontrolle, nagu on kirjeldatud jaotises küberturvalisuse platvormi strateegiad
Avatud lähtekoodiga koodi kompromiteerimine
Vastased lisavad populaarsetesse avatud lähtekoodiga pakettidesse tagauksi, mida hiljem tõmmati tuhandetesse projektidesse.
EventStream NPM intsident ja XZ Utilsi tagauks (2024) näitavad, kui kriitiliseks see vektor on muutunud.
Arendajad peaksid üle vaatama sellised ressursid nagu NPM-i turvalisuse KKK ja trükivigadega pakiintsidendid õppida, kuidas vältida mürgitatud sõltuvusi.
Sõltuvussegadus
Alex Birsani poolt 2021. aastal esmakordselt kirjeldatud rünnak kasutab ära sisemiste ja avalike pakettide registrite nimede kokkupõrkeid, pettes ehitussüsteeme tõmbama pahatahtlikke versioone usaldusväärsete sisemiste pakettide asemel.
Kirjaviga ja pahatahtlikud paketid
Ründajad avaldavad pahatahtlikke pakette, mille nimed sarnanevad populaarsete teekide nimedega (nt „requests” asemel „requests”).
Arendajad installivad need kogemata, tuues oma projektidesse pahavara.
Tegelikku näidet analüüsitakse artiklis Namso-generatsiooni pahavara ja meie nimekirjas avatud lähtekoodiga pahavara skannerid.
Ehitama Pipeline Omavoliline
Nagu SolarWinds Orioni kompromissist näha, saavad ründajad tungida ehitusserveritesse, et kompileerimise ajal pahatahtlikku koodi süstida.
See muudab kogu allkirjastatud artefaktide ahela ebausaldusväärseks. Ennetusmeetodite hulka kuulub jälgimine CI/CD ausus koos varajase hoiatamise tuvastamine ja analüüsides
GitHubi eelinstallitud pahavara kampaaniad.
Kuidas tarkvara tarneahela rünnak välja näeb: SolarWindsi juhtum
Eelkõige on SolarWindsi Orioni rünnak tuntuim näide tarkvara tarneahela rikkumisest. See näitab, kuidas ründajad saavad samm-sammult ehitusprotsessis liikuda ja selle tulemusel kahjulikku koodi tuhandete kasutajate seas levitada.
Esiteks pääsesid ründajad SolarWindsi ehitusserveritesse.
Pärast seda lisasid nad vaikselt Orioni värskendustesse pahatahtliku koodi.
Kuna need värskendused allkirjastati ja saadeti usaldusväärse tarkvarana, installisid paljud ettevõtted need riskidest teadlikud olemata.
Kokku mõjutas see enam kui 18 000 organisatsiooni ja ründajad said juurdepääsu väga tundlikele süsteemidele.
Arendaja vaatenurgast annab see rünnak kolm lihtsat õppetundi:
- Perimeetrikaitsest ei piisaründajad muutsid ehitust pipeline ise.
- Pidev kontroll on kriitilise tähtsusega: turvaline build attestations, terviklikkuse kontrollid ja anomaaliate tuvastamine aitavad takistada manipuleerimist.
- Üks mürgitatud ehitis võib minna globaalseksüksik pipeline Kompromiss võib tekitada ülemaailmse julgeolekukriisi.
Xygeni: ülim kõik-ühes rakenduste turvalisuse platvorm
Kuna tarkvara tarneahela rünnakud võivad tabada iga sammu SDLC,
kõik-ühes AppSec platvorm Xygeni, kaitseb lähtekoodi, ehituse, paketi ja sõltuvuse etappe. See annab arendajatele ja turvameeskondadele ühe koha riskide lihtsaks ennetamiseks, tuvastamiseks ja parandamiseks. Selle tulemusena ei pea te enam mitme tööriistaga žongleerima, Xygeni katab kogu elutsükli.
Allika etapi kaitse
Allika staadiumis hõlmavad riskid ohtlikke commits, mürgitatud repositooriumid või muudetud failid. Xygeni skannib koodi reaalajas sügavaga SAST ja saladuste avastamine.
See blokeerib ka kahjulikke commits läbi CI/CD guardrails.
Nii peatatakse probleemid enne, kui need repositooriumist lahkuvad.
Ehitusetapi kaitse
Ehitusfaasis võivad ründajad proovida mööda hiilida pipelinevõi muuta artefakte.
Xygeni turvab ehitusprotsessi SLSA-ga ühilduvate kontrollide, terviklikkuse valideerimise ja võtmeta allkirjadega. Samuti jälgib see ebatavalist käitumist seespool CI/CD töökohti. Selle tulemusel märgistatakse muudetud versioonid kohe ja blokeeritakse enne avaldamist.
Pakendi etapi kaitse
Paketi etapis sisaldavad kahjustatud registrid või muudetud teegid sageli pahavara. Xygeni pahavara tuvastamine ja litsentside skannimine vaatab iga artefakti üle, samal ajal AutoFix soovitab turvalisi uuendusteid oma parandusriski analüüsiga. Ainult kontrollitud ja nõuetele vastavad paketid liiguvad edasi pipeline.
Sõltuvuse etapi kaitse
Kolmanda osapoole kood on suurim rünnakupind. Xygeni tarkvara kompositsioonianalüüs (SCA) See ei piirdu ainult CVE-de loetlemisega, vaid kontrollib ka seda, kas riskantset koodi saab tegelikult ära kasutada. Samuti märgistab see varjatud pahavara ja riskantsed transitiivsed sõltuvused. Ennekõike tagab see, et arendajad edastavad ainult turvalisi sõltuvusi.
Saladused ja infrastruktuuri turvalisus
Lisaks koodile ja pakettidele kasutavad rünnakud sageli ära lekkinud saladusi või nõrka infrastruktuuri. Xygeni otsib avalikustatud võtmeid, märke ja volitusi koodis, konfiguratsioonides ja Dockeri kihtides. See saab ka lekkinud saladusi valideerida ja automaatselt tühistada AutoFixi parandus. Samal ajal, IaC skaneerimine hoiab ära valekonfiguratsioonid, mida ründajad saaksid hiljem kuritarvitada.
Nutikam tuvastamine ja parandused
Enamik tööriistu peatub teadete korral. Xygeni läheb kaugemale. Selle AutoFix mootor loob turvalisi parandusi, pull requestsvõi samm-sammult juhiseid, olenevalt probleemist. Selle parandusriski vaade näitab ka seda, milline paranduse versioon on kõige turvalisem, nii et meeskonnad saavad probleeme lahendada uusi probleeme lisamata.
Üks ühtne platvorm
Sest Xygeni ühendub SAST, SCA, pahavara tuvastamine, saladuste haldamine, IaC skaneerimine, anomaaliate tuvastamine ja turvalised ehituskontrollid ühel AppSec platvormil,
see pakub täielikku katvust kogu SDLCNii arendajad kui ka turvameeskonnad saavad ühe usaldusväärse allika, mis pakub selget ülevaadet, praktilisi lahendusi ja tugevat kaitset tarneahela rünnakute eest.
Kõiki asjaolusid arvesse võttes, Xygeni, ülim kõik-ühes rakenduste turvalisuse platvorm, aitab meeskondadel kiiresti luua ja turvaliselt püsida. Kaitstes lähtekoodi, ehituse, paketi ja sõltuvuse etappe ning lisades igale sammule automaatseid parandusi, tagab see, et tarkvara tarneahela rünnakud peatatakse enne, kui need tootmiskeskkonda jõuavad.
