Google introduserte rammeverket SLSA (Supply-chain Levels for Software Artifacts), som oppsummerer eksisterende erfaring med å beskytte utviklingsinfrastruktur mot angrep utført på stadiet med å skrive kode, teste, sette sammen og distribuere et produkt.
Utviklingsprosesser blir stadig mer komplekse og avhengige av tredjepartsverktøy, noe som skaper gunstige forutsetninger for fremme av angrep knyttet ikke til å identifisere og utnytte sårbarheter i sluttproduktet, men til å kompromittere selve utviklingsprosessen (forsyningskjedeangrep, vanligvis rettet mot introdusere ondsinnede endringer i prosessen med å skrive kode, substitusjon av distribuerte komponenter og avhengigheter).
Rammeverket tar hensyn til 8 typer angrep relatert til trusselen om å gjøre ondsinnede endringer på stadiet av kodeutvikling, montering, testing og distribusjon av produktet.
- A. Inkludert endringer i kildekoden som inneholder bakdører eller skjulte feil som fører til sårbarheter.
Eksempel på et angrep: "Hyklere forplikter seg" - et forsøk på å fremme patcher med sårbarheter inn i Linux-kjernen.
Foreslått sikkerhetsmetode: uavhengig gjennomgang av hver endring av to utviklere.
- B. Kompromittering av kildekodekontrollplattformen.
Eksempel på et angrep: injeksjon av ondsinnede forpliktelser med en bakdør inn i Git-depotet til et PHP-prosjekt etter at utviklerpassord ble lekket.
Foreslått beskyttelsesmetode: Økt sikkerhet for kodeadministrasjonsplattformen (i tilfelle PHP ble angrepet utført gjennom et lite brukt HTTPS-grensesnitt, som gjorde det mulig å sende endringer ved innlogging med passord uten å sjekke SSH-nøkkelen, til tross for det faktum at upålitelig MD5 ble brukt til å hash passord).
- C. Foreta endringer på stadiet av overføring av kode til bygget eller kontinuerlig integrasjonssystem (kode som ikke samsvarer med koden fra depotet bygges).
Eksempel på et angrep: Injisere en bakdør i Webmin ved å gjøre endringer i byggeinfrastrukturen, noe som resulterer i bruk av kodefiler som er forskjellige fra filene i depotet.
Foreslått beskyttelsesmetode: Kontrollere integriteten og identifisere kilden til koden på monteringsserveren.
- D. Kompromiss av monteringsplattformen.
Eksempel på et angrep: SolarWinds-angrepet, der installasjonen av en bakdør i SolarWinds Orion-produktet ble sikret under monteringsfasen.
Foreslått beskyttelsesmetode: implementering av avanserte sikkerhetstiltak for monteringsplattformen.
- E. Fremme av ondsinnet kode gjennom avhengigheter av lav kvalitet.
Et eksempel på et angrep: introduksjonen av en bakdør i det populære event-stream-biblioteket ved å legge til en ufarlig avhengighet og deretter inkludere ondsinnet kode i en av oppdateringene av denne avhengigheten (den ondsinnede endringen ble ikke reflektert i git-depotet, men var kun til stede i den ferdige MNP-pakken).
Foreslått beskyttelsesmetode: bruk rekursivt SLSA-krav til alle avhengigheter (i tilfelle av hendelsesstrøm, vil sjekken avsløre samlingen av kode som ikke samsvarer med innholdet i hovedlageret for Git).
- F. Opplasting av artefakter som ikke er opprettet i CI/CD-systemet.
Eksempel på et angrep: å legge til ondsinnet kode til CodeCov-skriptet, som gjorde det mulig for angripere å trekke ut informasjon lagret i kundemiljøer for kontinuerlige integreringssystem.
Foreslått beskyttelsesmetode: kontroll over kilden og integriteten til artefakter (i tilfellet med CodeCov, kan det avsløres at Bash Uploader-skriptet sendt fra codecov.io-nettstedet ikke samsvarer med koden fra prosjektdepotet).
- G. Kompromittering av pakkelageret.
Eksempel på et angrep: Forskere var i stand til å distribuere speil av noen populære pakkelager for å distribuere ondsinnede pakker gjennom dem.
Foreslått beskyttelsesmetode: Verifisering av at de distribuerte artefaktene er kompilert fra de deklarerte kildekodene.
- H. Forvirrer brukeren til å installere feil pakke.
Eksempel på et angrep: bruk av typosquatting (NPM, RubyGems, PyPI) for å plassere pakker i depoter som skriftlig ligner populære applikasjoner (for eksempel coffe-script i stedet for coffee-script).
For å blokkere de flaggede truslene tilbyr SLSA et sett med anbefalinger, samt verktøy for å automatisere opprettelsen av revisjonsmetadata. SLSA oppsummerer vanlige angrepsmetoder og introduserer konseptet sikkerhetslag. Hvert nivå pålegger visse infrastrukturkrav for å sikre integriteten til artefaktene som brukes i utviklingen. Jo høyere det støttede SLSA-nivået er, jo flere beskyttelser implementeres og jo bedre er infrastrukturen beskyttet mot vanlige angrep.
- SLSA 1 krever at byggeprosessen er helautomatisert og genererer metadata («herkomst») om hvordan artefakter bygges, inkludert informasjon om kilder, avhengigheter og byggeprosessen (et eksempel med metadatagenerator for revisjon er gitt for GitHub Actions). SLSA 1 inkluderer ikke elementer av beskyttelse mot ondsinnede modifikasjoner, men identifiserer ganske enkelt kode og gir metadata for sårbarhetshåndtering og risikoanalyse.
- SLSA 2 - utvider det første nivået ved å kreve bruk av versjonskontroll og monteringstjenester som genererer autentiserte metadata. Bruken av SLSA 2 lar deg spore opprinnelsen til koden og forhindrer uautoriserte endringer i koden i tilfelle av pålitelige byggetjenester.
- SLSA 3 - bekrefter at kildekoden og byggeplattformen oppfyller kravene til standarder som garanterer muligheten til å revidere koden og sikre integriteten til de oppgitte metadataene. Det forutsettes at revisor kan sertifisere plattformer mot kravene i standardene.
- SLSA 4 er det høyeste nivået, og supplerer de tidligere nivåene med følgende krav:
- Obligatorisk gjennomgang av alle endringer av to forskjellige utviklere.
- Alle byggetrinn, kode og avhengigheter må være fullstendig deklarert, alle avhengigheter må trekkes ut og verifiseres separat, og byggeprosessen må utføres offline.
- Ved å bruke en repeterbar byggeprosess kan du gjenta byggeprosessen selv og sikre at den kjørbare er bygget fra kildekoden som er oppgitt.
Kilde: opennet.ru