Google præsenterede SLSA-rammen (Supply-chain Levels for Software Artifacts), som opsummerer den eksisterende erfaring med at beskytte udviklingsinfrastruktur mod angreb, der udføres i kodnings-, test-, bygge- og distributionsstadierne af produktet.
Udviklingsprocesserne bliver stadig mere komplekse og afhængige af tredjepartsværktøjer, hvilket skaber gunstige betingelser for angreb, der ikke fokuserer på at opdage og udnytte sårbarheder i det færdige produkt, men på at kompromittere selve udviklingsprocessen (angreb i 'supply chain', som typisk er rettet mod at indføre skadelige ændringer i kodningsprocessen, udskifte distribuerede komponenter og afhængigheder).
Rammen tager højde for 8 typer angreb relateret til trusler om indføring af skadelige ændringer i koden under udviklingen, bygningen, testningen og distributionen af produktet.
- A. Inkludering af ændringer i kildekoden, der indeholder bagdøre eller skjulte fejl, der fører til sårbarheder.
Eksempel på angreb: 'Hypocrite Commits' — forsøg på at indføre patches med sårbarheder i Linux-kernen.
Foreslået beskyttelsesmetode: uafhængig gennemgang af hver ændring af to udviklere.
- B. Kompromittering af kildekodeadministrationsplatformen.
Eksempel på angreb: indførelse af skadelige commits med en bagdør i Git-repositoriet for PHP-projektet efter lækage af udviklernes adgangskoder.
Foreslået beskyttelsesmetode: Styrkelse af sikkerheden på kildekodeadministrationsplatformen (i tilfælde af PHP blev angrebet udført via en HTTPS-grænseflade, der blev sjældent brugt, hvilket tillod indsendelse af ændringer med adgangskode-login uden SSH-nøglekontrol, samtidig med at der blev anvendt usikret MD5 til hash af adgangskoder).
- C. Indføring af ændringer under overførslen af koden til bygge- eller kontinuerlig integrationssystem (koden, der samles, stemmer ikke overens med koden fra depotet).
Eksempel på angreb: indførelse af en bagdør i Webmin ved at foretage ændringer i byggeinfrastrukturen, hvilket førte til brug af filer med kode, der adskiller sig fra filer i depotet.
Foreslået beskyttelsesmetode: Kontrol af integriteten og identifikation af kildens oprindelse af den indkommende kode ved samlingen. serveren.
- D. Kompromittering af byggeplatformen.
Eksempel på angreb: SolarWinds-angrebet, hvor en bagdør blev indført i SolarWinds Orion-produktet under opbygningsprocessen.
Den foreslåede beskyttelsesmetode: implementering af udvidede sikkerhedsforanstaltninger for byggeplatformen.
- E. Fremme af skadelig kode gennem usikre afhængigheder.
Eksempel på angreb: indsprøjtning af en backdoor i det populære bibliotek event-stream ved at tilføje en uskyldig afhængighed, som derefter inkluderede skadelig kode i en af opdateringerne (den skadelige ændring blev ikke reflekteret i git-repositoriet, men var kun til stede i det færdige MNP-pakke).
Den foreslåede beskyttelsesmetode: rekursiv anvendelse af SLSA-kravene på alle afhængigheder (i tilfælde af event-stream ville kontrollen have afsløret en kodeopbygning, der ikke svarede til indholdet i det primære Git-repositorium).
- F. Download af artefakter, der ikke er oprettet i CI/CD-systemet.
Eksempel på angreb: tilføjelse af skadelig kode til CodeCov-skriptet, hvilket gjorde det muligt for angribere at udtrække oplysninger gemt i systemerne til kontinuerlig integration hos kunder.
Den foreslåede beskyttelsesmetode: kontrol med kilden og integriteten af artefakter (i tilfældet med CodeCov kunne det have været fastslået, at Bash Uploader-skriptet leveret fra codecov.io ikke svarede til koden fra projektets repository).
- G. Kompromittering af pakken-repositoriet.
Eksempel på angreb: forskere formåede at oprette spejle af nogle populære pakke-repositorier med det formål at sprede skadelige pakker gennem dem.
Den foreslåede beskyttelsesmetode: Kontrol med, at de udbudte artefakter er samlet fra de angivne kildekoder.
- H. Forvirring af brugeren til at installere den forkerte pakke.
Eksempel på angreb: brug af typosquatting (NPM, RubyGems, PyPI) til at placere pakker med navnelighed til populære applikationer i repositorierne (for eksempel coffe-script i stedet for coffee-script).
For at blokere de markerede trusler foreslår SLSA et sæt anbefalinger samt værktøjer til automatisering af metadataoprettelse til revision. SLSA opsummerer typiske angrebsmetoder og introducerer begrebet beskyttelsesniveauer. Hvert niveau stiller bestemte krav til infrastrukturen, der sikrer integriteten af de artefakter, der anvendes under udviklingen. Jo højere det støttede SLSA-niveau er, desto flere beskyttelsesforanstaltninger er implementeret, og desto bedre er infrastrukturen beskyttet mod typiske angreb.
- SLSA 1 — kræver, at byggeprocessen er helt automatiseret og genererer metadata („provenance“) om, hvordan artefakterne er samlet, inklusive oplysninger om kildekoder, afhængigheder og byggeprocessen (et eksempel på en metadata-generator til revision er foreslået til GitHub Actions). SLSA 1 omfatter ikke elementer til at beskytte mod skadelige ændringer, men identificerer blot koden på den enkleste måde og leverer metadata til håndtering af sårbarheder og risikanalyse.
- SLSA 2 — udvider det første niveau med kravet om brug af versionsstyringssystemer og bygge-tjenester, der genererer autentificerede metadata. Anvendelsen af SLSA 2 gør det muligt at spore oprindelsen af koden og forhindrer uautoriserede ændringer i koden, når der anvendes troværdige bygge-tjenester.
- SLSA 3 — bekræfter, at kildekoderne og byggeplatformen opfylder kravene i standarderne, der sikrer, at revisionsmulighederne for koden og integriteten af de leverede metadata er opfyldt. Det antages, at revisorer kan certificere platforme i forhold til standardernes krav.
- SLSA 4 — det højeste niveau, der tilføjer de tidligere niveauer følgende krav:
- Obligatorisk gennemgang af alle ændringer af to forskellige udviklere.
- Alle bygge-trin, kode og afhængigheder skal være fuldt deklareret, alle afhængigheder skal hentes og kontrolleres separat, og byggeprocessen skal udføres uden internetadgang.
- Anvendelsen af en gentagelig byggeproces — muligheden for at gentage byggeprocessen selv og bekræfte, at den kørte fil er samlet ud fra de leverede kildekoder.
Kilde: opennet.ru
