Google-k SLSA (Supply-chain Levels for Software Artifacts) esparrua aurkeztu zuen, eta produktu bat idazteko, probatzeko, muntatzeko eta banatzeko fasean egindako erasoetatik garapen-azpiegiturak babesteko esperientzia laburtzen du.
Garapen-prozesuak gero eta konplexuagoak dira eta hirugarrenen tresnen menpekoak dira, eta horrek baldintza onak sortzen ditu azken produktuan ahultasunak identifikatzea eta ustiatzearekin ez, garapen-prozesua bera arriskuan jartzearekin zerikusia duten erasoak aurrera egiteko (hornikuntza-katearen erasoak, normalean helburu kodea idazteko prozesuan aldaketa gaiztoak sartzea, banatutako osagaiak eta mendekotasunak ordezkatzea).
Esparruak produktuaren garapen, muntaketa, proba eta banaketaren fasean aldaketa gaiztoak egiteko mehatxuarekin lotutako 8 eraso mota hartzen ditu kontuan.
- A. Atzeko ateak dituzten iturburu-kodearen aldaketak edo ahultasunak eragiten dituzten ezkutuko akatsak barne.
Eraso baten adibidea: "Hypocrite Commits" - Linux nukleoan ahuleziak dituzten adabakiak sustatzeko saiakera bat.
Iradokitako segurtasun-metodoa: bi garatzailek aldaketa bakoitzaren berrikuspen independentea.
- B. Iturburu-kodea kontrolatzeko plataformaren konpromisoa.
Eraso baten adibidea: atzeko ate batekin konpromiso maltzurren injekzioa PHP proiektu baten Git biltegian garatzaileen pasahitzak filtratu ondoren.
Iradokitako babes-metodoa: Kodea kudeatzeko plataformaren segurtasuna areagotu (PHP-ren kasuan, erasoa gutxi erabiltzen den HTTPS interfaze baten bidez egin da, eta horri esker, pasahitz batekin saioa hastean aldaketak bidal daitezke SSH gakoa egiaztatu gabe, nahiz eta izan ere, MD5 fidagarria erabili zen pasahitzak hash egiteko).
- C. Eraikitze edo etengabeko integrazio sistemara kodea transferitzeko fasean aldaketak egitea (biltegiko kodearekin bat ez datorren kodea eraikitzen da).
Eraso baten adibidea: Webmin-en atzeko atea txertatzea eraikuntza-azpiegituran aldaketak eginez, biltegiko fitxategietatik desberdinak diren kode-fitxategiak erabiltzearen ondorioz.
Proposatzen den babes-metodoa: osotasuna egiaztatzea eta kodearen iturburua identifikatzea asanblada zerbitzarian.
- D. Muntaketa plataformaren konpromisoa.
Eraso baten adibidea: SolarWinds erasoa, zeinetan SolarWinds Orion produktuan atzeko atea instalatzea bermatu zen muntaketa fasean.
Proposatutako babes-metodoa: muntaketa-plataformarako segurtasun-neurri aurreratuak ezartzea.
- E. Kode gaiztoaren sustapena kalitate baxuko menpekotasunen bidez.
Eraso baten adibide bat: gertaera-korronteen liburutegi ezagunean atzeko atea sartzea, kaltegabeko mendekotasuna gehituz eta, gero, kode gaiztoa sartuz mendekotasun horren eguneratzeetako batean (aldaketa gaiztoa ez zen git biltegian islatu, baina izan zen. amaitutako MNP paketean bakarrik aurkeztu).
Iradokitako babes-metodoa: errekurtsiboki aplikatu SLSA eskakizunak mendekotasun guztietan (gertaera-korrontearen kasuan, egiaztapenak Git biltegi nagusiko edukiarekin bat ez datorren kodearen muntaia agerian utziko luke).
- F. CI/CD sisteman sortu ez diren artefaktuak kargatzea.
Eraso baten adibidea: CodeCov script-ari kode gaiztoa gehitzea, erasotzaileek bezeroen etengabeko integrazio-sistemaren inguruneetan gordetako informazioa ateratzeko aukera emanez.
Proposatutako babes-metodoa: artefaktuen iturriaren eta osotasunaren kontrola (CodeCov-en kasuan, codecov.io webgunetik bidalitako Bash Uploader script-a ez datorrela bat proiektuaren biltegiko kodearekin).
- G. Pakete-biltegiaren konpromisoa.
Eraso baten adibidea: ikertzaileek paketeen biltegi ezagun batzuen ispiluak zabaldu ahal izan zituzten haien bidez pakete gaiztoak banatzeko.
Iradokitako babes-metodoa: banatutako artefaktuak deklaratutako iturburu-kodeetatik konpilatuta daudela egiaztatzea.
- H. Erabiltzailea pakete okerra instalatzeko nahastea.
Eraso baten adibidea: typosquatting erabiltzea (NPM, RubyGems, PyPI) paketeak idazteko aplikazio ezagunen antzekoak diren biltegietan jartzeko (adibidez, coffe-script-en ordez coffee-script).
Markatutako mehatxuak blokeatzeko, SLSAk gomendio multzo bat eskaintzen du, baita auditoretza metadatuen sorrera automatizatzeko tresnak ere. SLSAk eraso-metodo arruntak laburbiltzen ditu eta segurtasun-geruzen kontzeptua sartzen du. Maila bakoitzak azpiegitura-eskakizun batzuk ezartzen ditu garapenean erabilitako artefaktuen osotasuna bermatzeko. Onartutako SLSA maila zenbat eta altuagoa izan, orduan eta babes gehiago ezarriko dira eta azpiegitura hobeto babestuta egongo da eraso arruntetatik.
- SLSA 1-ek eraikitze-prozesua guztiz automatizatuta egotea eta artefaktuak nola eraikitzeari buruzko metadatuak ("jatorria") sortzea eskatzen du, iturriei, mendekotasunei eta eraikitze-prozesuari buruzko informazioa barne (ikuskaritzarako metadatu-sorgailu adibide bat eskaintzen da GitHub Ekintzetarako). SLSA 1ek ez ditu aldaketa gaiztoen aurkako babes-elementurik sartzen, baizik eta kodea identifikatzen du eta metadatuak eskaintzen ditu ahultasunak kudeatzeko eta arriskuen azterketarako.
- SLSA 2 - lehen maila hedatzen du autentifikatutako metadatuak sortzen dituzten bertsio-kontrola eta muntaketa-zerbitzuak erabiltzea eskatuz. SLSA 2 erabiltzeak kodearen jatorria trazatzeko aukera ematen du eta kodearen baimenik gabeko aldaketak eragozten ditu konfiantzazko eraikuntza zerbitzuen kasuan.
- SLSA 3 - baieztatzen du iturburu-kodeak eta eraikitze-plataformak kodea ikuskatzeko eta emandako metadatuen osotasuna bermatzen duten estandarren eskakizunak betetzen dituztela. Suposatzen da auditoreek plataformak estandarren eskakizunen arabera ziurta ditzaketela.
- SLSA 4 maila gorena da, aurreko mailak baldintza hauekin osatuz:
- Aldaketa guztien derrigorrezko berrikuspena bi garatzaile ezberdinek.
- Eraikuntza-urrats, kodea eta mendekotasun guztiak guztiz deklaratu behar dira, mendekotasun guztiak bereizita atera eta egiaztatu behar dira, eta eraikuntza-prozesua lineaz kanpo egin behar da.
- Eraikitze-prozesu errepikagarria erabiliz, eraikitze-prozesua zuk zeuk errepikatu dezakezu eta exekutagarria emandako iturburu-kodetik eraikitzen dela ziurtatzen duzu.
Iturria: opennet.ru