L Paraqiten zhvilluesit e Google "SLSA" (Nivelet e zinxhirit të furnizimit për artefakte softuerësh) i cili ka për qëllim të kujdeset për mbrojtja e infrastrukturës së zhvillimit të sulmeve të kryera në kodimin, testimin, ndërtimin dhe shpërndarjen e një produkti.
Zhvilluesit përmend se proceset e zhvillimit janë gjithnjë e më komplekse dhe varen nga mjetet e palëve të treta, e cila krijon kushte të favorshme për promovimin e sulmeve që lidhen jo me identifikimin dhe shfrytëzimin e dobësive në produktin përfundimtar, por me angazhimin e vetë procesit të zhvillimit.
Rreth SLSA
Përmendet se SLSA përqendrohet në dy parimet themelore të mëposhtme:
Jo i njëanshëm - Asnjë person nuk mund të modifikojë artefaktin e softuerit kudo në zinxhirin e furnizimit të softuerit pa shqyrtim dhe miratim të qartë nga të paktën një "person i besuar" tjetër. [^ 1] Qëllimi është parandalimi, parandalimi ose zbulimi i hershëm i rreziqeve / ndryshimeve të këqija.
Auditues - Objekti i softuerit mund të gjurmohet në mënyrë të sigurt dhe transparente në burimet origjinale, të lexueshme nga njerëzit dhe varësitë. Qëllimi kryesor është analiza e automatizuar e burimit dhe varësisë, si dhe hetimet ad-hoc.
Për të bllokuar kërcënimet me flamur, SLSA ofron një sërë udhëzimesh dhe mjetesh për të automatizuar krijimin e meta të dhënave për auditim. SLSA përmbledh metodat e zakonshme të sulmit dhe prezanton konceptin e shtresave të mbrojtjes.
Secila shtresë ka kërkesa specifike të infrastrukturës për të siguruar integritetin e objekteve të përdorura në zhvillim, dmth. sa më i lartë të jetë niveli i mbështetur SLSA, aq më shumë mbrojtje do të zbatohen dhe infrastruktura do të mbrohet më mirë nga sulmet tipike.
Niveli 1 i SLSA-së
Në këtë nivel kërkon që procesi i ndërtimit të jetë plotësisht i automatizuar dhe të gjenerojë meta të dhëna ("Provenance") mbi mënyrën se si mblidhen artefakte, përfshirë burimin, varësinë dhe informacionin e procesit të ndërtimit (një model gjenerator i meta të dhënave për auditim sigurohet për veprimet e GitHub). SLSA 1 nuk përfshin elemente të mbrojtjes nga ndryshimet keqdashëseAi vetëm identifikon kodin në mënyrën më të thjeshtë dhe ofron meta të dhëna për menaxhimin e cenueshmërisë dhe analizën e rrezikut.
Niveli 2 i SLSA-së
Këtu shtresa e parë shtrihet duke kërkuar përdorimin e një sistemi të kontrollit të burimit dhe ndërtimin e shërbimeve që gjenerojnë meta të dhëna të vërtetuara. Perdorimi i SLSA 2 ju lejon të gjurmoni origjinën e kodit dhe parandalon ndryshimet e paautorizuara në kodin tuaj, në rastin e përdorimit të shërbimeve të besueshme të montimit.
Niveli 3 i SLSA-së
Nga kjo pikëose kodi burimor dhe platforma e ndërtimit konfirmohen për të përmbushur kërkesat e standardeve për të siguruar që kodi mund të auditohet dhe se integriteti i meta të dhënave të siguruara është i garantuar. Auditorët supozohet të jenë në gjendje të certifikojnë platforma për pajtueshmëri me kërkesat e standardeve.
Niveli 4 i SLSA-së
Ky është niveli më i lartë dhe gjithashtu plotëson nivelet e mëparshme duke shtuar kërkesat shumë më të rrepta të të cilave janë rishikimi i detyrueshëm i të gjitha ndryshimeve nga dy zhvillues të ndryshëm, si dhe të gjithë hapat e përpilimit, kodin dhe varësitë. Ato duhet të jenë deklaruar plotësisht, të gjitha varësitë duhet të kontrollohen dhe kontrollohen veçmas, dhe procesi i ndërtimit duhet të bëhet jashtë linje.
Përdorimi i një procesi të përpilimit të përsëritshëm gjithashtu siguron aftësinë për të përsëritur procesin e përpilimit dhe për të siguruar që e ekzekutueshmja është përpiluar nga burimet e dhëna.
Përveç tij kjo kornizë merr parasysh 8 lloje të sulmeve lidhur me kërcënimet e ndryshimeve keqdashëse në fazën e zhvillimit, përpilimit, testimit dhe shpërndarjes së kodit të produktit.
Llojet e sulmit që merren parasysh janë:
1.- Përfshirja në kodin burimor të ndryshimeve që përmbajnë dyer të pasme ose gabime të fshehta që çojnë në dobësi.
2.- Angazhimi i platformës së kontrollit të burimit.
3.- Bëni ndryshime në fazën e transferimit të kodit në hartimin ose sistemin e integrimit të vazhdueshëm (mblidhet kodi që nuk korrespondon me kodin e depozitës).
4.- Angazhimi i platformës së ndërtimit
5.- Promovimi i kodit me qëllim të keq përmes varësive me cilësi të ulët.
6.- Duke ngarkuar objekte që nuk gjenerohen në sistemin CI / CD.
7.- Kompromisi i depozitës së paketës.
8.- Konfuzion tek përdoruesi për të instaluar paketën e gabuar.
Më në fund nëse doni të dini më shumë rreth saj, ju mund të kontrolloni detajet Në lidhjen vijuese.