Google introduceerde het SLSA-framework (Supply-chain Levels for Software Artifacts), dat de bestaande ervaring samenvat met het beschermen van de ontwikkelingsinfrastructuur tegen aanvallen die worden uitgevoerd in de fase van het schrijven van code, het testen, assembleren en distribueren van een product.
Ontwikkelingsprocessen worden steeds complexer en afhankelijker van tools van derden, wat gunstige omstandigheden schept voor de voortgang van aanvallen die niet gerelateerd zijn aan het identificeren en exploiteren van kwetsbaarheden in het eindproduct, maar aan het compromitteren van het ontwikkelingsproces zelf (supply chain-aanvallen, meestal gericht op het introduceren van kwaadaardige veranderingen in het proces van het schrijven van code, het vervangen van gedistribueerde componenten en afhankelijkheden).
Het raamwerk houdt rekening met 8 soorten aanvallen die verband houden met de dreiging van het aanbrengen van kwaadaardige wijzigingen in de fase van codeontwikkeling, assemblage, testen en distributie van het product.
- A. Inclusief wijzigingen in de broncode die backdoors of verborgen fouten bevatten die tot kwetsbaarheden leiden.
Voorbeeld van een aanval: “Hypocrite Commits” - een poging om patches met kwetsbaarheden in de Linux-kernel te promoten.
Voorgestelde beveiligingsmethode: onafhankelijke beoordeling van elke wijziging door twee ontwikkelaars.
- B. Compromis van het broncodecontroleplatform.
Voorbeeld van een aanval: injectie van kwaadaardige commits met een achterdeur in de Git-repository van een PHP-project nadat ontwikkelaarswachtwoorden waren gelekt.
Voorgestelde beveiligingsmethode: Verhoogde beveiliging van het codebeheerplatform (in het geval van PHP werd de aanval uitgevoerd via een weinig gebruikte HTTPS-interface, waardoor wijzigingen konden worden verzonden bij het inloggen met een wachtwoord zonder de SSH-sleutel te controleren, ondanks het feit dat onbetrouwbare MD5 werd gebruikt om wachtwoorden te hashen).
- C. Wijzigingen aanbrengen in de fase van het overbrengen van code naar het build- of continue integratiesysteem (er wordt code gebouwd die niet overeenkomt met de code uit de repository).
Voorbeeld van een aanval: het injecteren van een achterdeur in Webmin door wijzigingen aan te brengen in de build-infrastructuur, resulterend in het gebruik van codebestanden die verschillen van de bestanden in de repository.
Voorgestelde beveiligingsmethode: Controle van de integriteit en identificatie van de bron van de code op de assemblageserver.
- D. Compromis van het montageplatform.
Voorbeeld van een aanval: de SolarWinds-aanval, waarbij tijdens de montagefase werd gezorgd voor de installatie van een achterdeur in het SolarWinds Orion-product.
Voorgestelde beveiligingsmethode: implementatie van geavanceerde beveiligingsmaatregelen voor het montageplatform.
- E. Promotie van kwaadaardige code via afhankelijkheden van lage kwaliteit.
Een voorbeeld van een aanval: de introductie van een achterdeur in de populaire event-stream-bibliotheek door een onschadelijke afhankelijkheid toe te voegen en vervolgens kwaadaardige code op te nemen in een van de updates van deze afhankelijkheid (de kwaadaardige verandering werd niet weerspiegeld in de git-repository, maar werd alleen aanwezig in het voltooide MNP-pakket).
Voorgestelde beveiligingsmethode: pas SLSA-vereisten recursief toe op alle afhankelijkheden (in het geval van event-stream zou de controle de verzameling code onthullen die niet overeenkomt met de inhoud van de hoofdopslagplaats van Git).
- F. Het uploaden van artefacten die niet in het CI/CD-systeem zijn gemaakt.
Voorbeeld van een aanval: het toevoegen van kwaadaardige code aan het CodeCov-script, waardoor aanvallers informatie konden extraheren die was opgeslagen in de continue integratiesysteemomgevingen van klanten.
Voorgestelde beveiligingsmethode: controle over de bron en integriteit van artefacten (in het geval van CodeCov zou kunnen worden onthuld dat het Bash Uploader-script verzonden vanaf de codecov.io-website niet overeenkomt met de code uit de projectrepository).
- G. Compromis van de pakketrepository.
Voorbeeld van een aanval: Onderzoekers waren in staat spiegelservers van enkele populaire pakketrepository's in te zetten om kwaadaardige pakketten via deze te verspreiden.
Voorgestelde beveiligingsmethode: Verificatie dat de gedistribueerde artefacten zijn samengesteld op basis van de gedeclareerde broncodes.
- H. De gebruiker in verwarring brengen door het verkeerde pakket te installeren.
Voorbeeld van een aanval: het gebruik van typosquatting (NPM, RubyGems, PyPI) om pakketten in repository's te plaatsen die qua schrift vergelijkbaar zijn met populaire applicaties (bijvoorbeeld coffe-script in plaats van coffee-script).
Om de gemarkeerde bedreigingen te blokkeren, biedt SLSA een reeks aanbevelingen, evenals tools om het aanmaken van auditmetagegevens te automatiseren. SLSA vat veelgebruikte aanvalsmethoden samen en introduceert het concept van beveiligingslagen. Elk niveau legt bepaalde infrastructuurvereisten op om de integriteit van de artefacten die bij de ontwikkeling worden gebruikt, te garanderen. Hoe hoger het ondersteunde SLSA-niveau, hoe meer beveiligingen er worden geïmplementeerd en hoe beter de infrastructuur wordt beschermd tegen veelvoorkomende aanvallen.
- SLSA 1 vereist dat het bouwproces volledig geautomatiseerd is en metagegevens (“herkomst”) genereert over hoe artefacten worden gebouwd, inclusief informatie over bronnen, afhankelijkheden en het bouwproces (voor GitHub Actions is een voorbeeld van een metadatagenerator voor auditing beschikbaar). SLSA 1 bevat geen elementen van bescherming tegen kwaadwillige wijzigingen, maar identificeert eenvoudigweg code en biedt metagegevens voor kwetsbaarheidsbeheer en risicoanalyse.
- SLSA 2 - breidt het eerste niveau uit door het gebruik van versiebeheer en assemblagediensten te vereisen die geverifieerde metagegevens genereren. Door het gebruik van SLSA 2 kunt u de oorsprong van de code traceren en worden ongeautoriseerde wijzigingen aan de code voorkomen bij vertrouwde bouwservices.
- SLSA 3 - bevestigt dat de broncode en het bouwplatform voldoen aan de vereisten van standaarden die de mogelijkheid garanderen om de code te auditen en de integriteit van de verstrekte metagegevens te garanderen. Er wordt van uitgegaan dat auditors platforms kunnen certificeren op basis van de eisen van de standaarden.
- SLSA 4 is het hoogste niveau en vormt een aanvulling op de voorgaande niveaus met de volgende vereisten:
- Verplichte beoordeling van alle wijzigingen door twee verschillende ontwikkelaars.
- Alle bouwstappen, code en afhankelijkheden moeten volledig worden gedeclareerd, alle afhankelijkheden moeten afzonderlijk worden geëxtraheerd en geverifieerd, en het bouwproces moet offline worden uitgevoerd.
- Door een herhaalbaar bouwproces te gebruiken, kunt u het bouwproces zelf herhalen en ervoor zorgen dat het uitvoerbare bestand wordt opgebouwd op basis van de verstrekte broncode.
Bron: opennet.ru