Google har föreslagit SLSA för att skydda mot skadliga ändringar i utvecklingsprocessen

Google har introducerat ramverket SLSA (Supply-chain Levels for Software Artifacts), som sammanfattar den befintliga erfarenheten av att skydda utvecklingsinfrastruktur från attacker som sker under kodskrivning, testning, byggande och distribution av produkten.

Utvecklingsprocesser blir allt mer komplexa och beroende av externa verktyg, vilket skapar gynnsamma förutsättningar för attacker kopplade till kompromettering av själva utvecklingsprocessen (supply chain-attacker, som vanligtvis syftar till att införa skadliga ändringar under kodskrivning, byta ut distribuerade komponenter och beroenden).

Ramverket omfattar 8 typer av attacker relaterade till hot om införande av skadliga ändringar under kodutveckling, byggen, testning och distribution av produkten.

• A. Införande av ändringar i koden som innehåller bakdörrar eller dolda fel som leder till sårbarheter.

  Exempel på attack: "Hypocrite Commits" — ett försök att föra in patcher med sårbarheter i Linux-kärnan.

  Föreslagen skyddsåtgärd: oberoende granskning av varje ändring av två utvecklare.

• B. Kompromettering av plattformen för källkodshantering.

  Exempel på attack: införande av skadliga commits med en bakdörr i Git-repositoryt för PHP-projektet efter att utvecklarnas lösenord läckts.

  Föreslagen skyddsåtgärd: Förbättring av säkerheten på källkodsplattformen (i PHP-fallet skedde attacken via en sällan använd HTTPS-gränssnitt som tillät ändringar vid inloggning med lösenord utan att kontrollera SSH-nyckeln, medan osäkra MD5-användes för lösenordshashning).

• C. Införande av ändringar vid överföring av kod till byggsystemet eller kontinuerlig integration (kod som byggs överensstämmer inte med koden i repositoryt).

  Exempel på attack: införande av en bakdörr i Webmin genom att göra ändringar i bygginfrastrukturen, vilket ledde till användning av filer med kod som skiljde sig från filerna i repositoryt.

  Föreslagen skyddsåtgärd: Kontroll av integritet och identifiering av källan till koden som kommer till byggsystemet. servern.

• D. Kompromettering av byggplattformen.

  Exempel på attack: SolarWinds-attacken, där en bakdörr infördes i SolarWinds Orion-produkten under byggsteget.

  Föreslagen skyddsmetod: implementering av utökade säkerhetsåtgärder på byggplattformen.

• E. Spridning av skadlig kod genom dåliga beroenden.

  Exempel på attack: införande av en bakdörr i det populära biblioteket event-stream genom att lägga till en ofarlig beroende som i ett av uppdateringarna av detta beroende inkluderade skadlig kod (den skadliga ändringen återspeglades inte i git-repositoriet, utan fanns endast i den färdiga MNP-paketet).

  Föreslagen skyddsmetod: rekursiv tillämpning av SLSA-krav på alla beroenden (i fallet med event-stream skulle en kontroll ha avslöjat en kodsammanställning som inte överensstämde med innehållet i huvud-Git-repositoriet).

• F. Laddning av artefakter som inte skapats i CI/CD-systemet.

  Exempel på attack: tillägg av skadlig kod i CodeCov-skriptet, vilket gjorde det möjligt för angripare att hämta information som lagrades i kundernas kontinuerliga integrationssystemmiljöer.

  Föreslagen skyddsmetod: kontroll av källan och integriteten hos artefakter (i fallet med CodeCov kunde det ha avslöjats att det Bash Uploader-skript som levererades från codecov.io-webbplatsen inte stämde överens med koden från projektets repository).

• G. Kompromettering av paketrepository.

  Exempel på attack: forskare lyckades sätta upp speglar för några populära paketrepositoryer i syfte att sprida skadliga paket genom dem.

  Föreslagen skyddsmetod: kontroll av att spridda artefakter är byggda från deklarerade källkoder.

• H. Förvirring av användaren för att installera fel paket.

  Exempel på attack: användning av typkollapsning (NPM, RubyGems, PyPI) för att placera paket i repository som liknar namnen på populära applikationer (till exempel, coffe-script istället för coffee-script).

För att blockera de angivna hoten erbjuder SLSA en uppsättning rekommendationer samt verktyg för automatisering av skapande av metadata för revision. SLSA sammanfattar typiska angreppssätt och introducerar begreppet skyddsnivåer. Varje nivå ställer specifika krav på infrastrukturen, vilket garanterar integriteten hos de artefakter som används vid utveckling. Ju högre nivå av SLSA som stöds, desto fler skyddsåtgärder har implementerats och desto bättre är infrastrukturen skyddad mot typiska attacker.

• SLSA 1 — kräver att byggprocessen är helt automatiserad och genererar metadata („provenance“) om hur artefakterna samlades, inklusive information om källkoden, beroenden och byggprocessen (ett exempel på en metadata-generator för revision föreslås för GitHub Actions). SLSA 1 inkluderar inte skydd mot ondsinta ändringar, utan identifierar endast koden på enklast möjliga sätt och tillhandahåller metadata för hantering av sårbarheter och riskanalys.
• SLSA 2 — utvidgar den första nivån med kravet på användning av versionshanteringssystem och byggtjänster som genererar autentiserad metadata. Användningen av SLSA 2 gör det möjligt att spåra källan till koden och förhindrar obehöriga ändringar av koden, om pålitliga byggtjänster används.
• SLSA 3 — bekräftar att källkoden och byggplattformen uppfyller standardernas krav som säkerställer att koden kan revideras och att den tillhandahållna metadata är intakt. Det förutsätts att revisorer kan certifiera plattformar för att säkerställa att de uppfyller standardkraven.
• SLSA 4 — den högsta nivån som kompletterar de föregående nivåerna med följande krav:
  • Obligatorisk granskning av alla ändringar av två olika utvecklare.
  • Alla steg i byggprocessen, koden och beroenden måste deklareras fullständigt, alla beroenden måste extraheras och verifieras separat, och byggprocessen måste utföras utan nätverksåtkomst.
  • Användandet av en process för reproducerbar byggning — möjligheten att upprepa byggprocessen självständigt och försäkra sig om att den körbara filen är byggd från den angivna källkoden.
  
  
  Källa: opennet.ru