De integriteit van softwaretoeleveringsketens is de afgelopen jaren een belangrijk gespreksonderwerp geworden, waarbij aanvallen op softwaretoeleveringsketens de afgelopen twee jaar steeds vaker voorkomen. Het is voor ontwikkelaars absoluut noodzakelijk geworden om zorgvuldig externe software en producten te kiezen om in hun softwaresystemen op te nemen, en tegelijkertijd maatregelen te treffen om de integriteit van hun softwareartefacten te waarborgen.
Het proces van het bouwen en implementeren van software is behoorlijk ingewikkeld, met veel potentiële kwetsbaarheden in de hele keten. In plaats van te vertrouwen op specifieke oplossingen voor elke kwetsbaarheid, is het logischer dat ontwikkelaars een uitgebreider end-to-end raamwerk adopteren dat bedreigingen tijdens de ontwikkelingsfase kan helpen beperken.
Eén zo’n raamwerk is het Supply chain-niveaus voor softwareartefacten (SLSA). Dit raamwerk is een uitgebreide checklist van beveiligingscontroles en standaarden die de integriteit van softwarepakketten en infrastructuur garanderen.
De nieuw geïntroduceerde SLSA beveiligingsframework is een product van een samenwerking tussen OpenSSF, Google en andere belanghebbenden op het gebied van cyberbeveiliging. Het dient als een overeengekomen industriestandaard die door ontwikkelaars, bedrijven en ondernemingen kan worden overgenomen om hen te helpen weloverwogen keuzes te maken over de beveiliging van de software die ze bouwen of gebruiken en om de gehele levenscyclus van softwareontwikkeling te beveiligen.
Hoe SLSA helpt bij de verdediging tegen aanvallen op de supply chain van software
Het SLSA-beveiligingsframework is meer dan een reeks regels; het is een standaardframework dat potentieel de integriteit van de componenten van een softwareartefact kan versterken. Deze end-to-end-richtlijn fungeert als een reeks defensieve maatregelen die stapsgewijs manipulatie of enige vorm van ongeoorloofde wijziging aan de softwarepakketten waaruit een softwareproduct bestaat, voorkomen. Door het SLSA-framework te gebruiken, kunt u uw software beschermen tegen veelvoorkomende problemen aanvallen op de toeleveringsketen zoals het volgende:
PHP's kwaadaardige commit repository-aanvallen
In maart 2021 kondigde Nikita Popov aan dat kwaadwillende actoren probeerden de broncode van PHP aan te vallen door een achterdeur te creëren waarmee ze ongeautoriseerde toegang konden krijgen tot het codeplatform. Indien succesvol zou de aanval verwoestend zijn geweest, aangezien PHP ongeveer 80% van de websites op internet aanstuurt. Gelukkig werd de aanval op tijd opgemerkt, maar dit incident illustreert nog steeds hoe SLSA-controles dit soort aanvallen in de toekomst kunnen helpen voorkomen. Het volgen van SLSA-protocollen, zoals een beoordeling door twee personen en tweefactorauthenticatie, zou het broncodeplatform hebben beschermd en het een veel moeilijker doelwit voor aanvallers hebben gemaakt.
Schadelijke compilerschending van Apple
In 2015 downloadden softwareontwikkelaars die apps voor Apple-producten bouwden een versie van Xcode (een tool voor het schrijven van code voor Apple-apparaten) van een niet-geverifieerd hostingplatform. De versie van Xcode, bekend als XcodeGhost, was geïnfecteerd met kwaadaardige code die heimelijk werd overgedragen naar apps die ermee waren gebouwd. Het creëerde een achterdeur naar verschillende apps die het codebeoordelingsproces van Apple en de apps die in de app store werden aangeboden, omzeilden. Het SLSA-framework bevat build-gerelateerde beveiligingsprotocollen die een aanval als deze hadden kunnen voorkomen of bemoeilijken. Eén van die maatregelen is de hermetische bouwvereiste, die ontwikkelaars zou hebben gedwongen al hun bronnen aan te geven, inclusief de ingebouwde tool die ze gebruikten.
Schadelijke artefacten geüpload
Op 1 april 2021 ontdekte het Codecov-team aanvallen die gevolgen hadden voor zijn Bash-uploaders, waaronder Codecov GitHub Action, The Codecov CircleCI Orb en de Codecov Bitrise Step. De aanvaller kreeg ongeautoriseerde toegang door een HMAC-sleutel te extraheren die toegang bood tot het Google Cloud Storage-serviceaccount van een tussenlaag van een van Codecov's openbare Self-Hosted Docker-images. Met deze sleutel konden ze de Bash Uploader aanpassen om kwaadaardige codes rechtstreeks naar eindgebruikers te uploaden. Het SLSA-framework zou deze actie hebben opgevangen door te laten zien wanneer artefacten op een andere manier worden gebouwd dan de verwachte vorm in hun bronrepository.
Slechte afhankelijkheid van gebeurtenisstroom
In 2018 publiceerden hackers een kwaadaardig pakket flatmap-stream naar npm en dit werd later als afhankelijkheid toegevoegd aan het veelgebruikte event-stream-pakket van het platform. Na het toevoegen van de afhankelijkheid hebben de aanvallers deze bijgewerkt met kwaadaardig gedrag. Omdat de update niet overeenkwam met de code die naar GitHub was verzonden, zou het SLSA-framework de aanval hebben opgevangen en de vector hebben voorkomen. Het volgen van de herkomst van de kwaadaardige code zou hebben onthuld dat deze niet afkomstig was van GitHub of van de juiste bouwer. Hoe het ook zij, de aanval had voorkomen kunnen worden.
De vier beveiligingsniveaus van het SLSA Cybersecurity Framework
Het SLSA-framework is een incrementeel en bruikbaar protocol. Het bestaat uit vier niveaus, waarbij niveau 4 de ideale eindtoestand van een beveiligd systeem vertegenwoordigt. Artefacten op het hoogste niveau voldoen aan alle eisen om het vertrouwen van de consument te winnen dat er op geen enkele manier mee is geknoeid en dat al hun componenten terug te voeren zijn op hun bron. Artefacten op de lagere niveaus zijn artefacten die ook aanvullende mijlpalen hebben bereikt met specifieke integriteitsgaranties, afhankelijk van hun rang.
Niveau 1 – het leggen van de fundering
Je kunt niveau 1 van het SLSA-framework beschouwen als een soort basis voor het hele raamwerk om veilige software te creëren. In dit stadium moeten ontwikkelaars of organisaties die de SLSA adopteren twee dingen doen. Ten eerste moeten ze hun bouwproces volledig automatiseren. Dit kan op verschillende manieren worden gedaan, maar de conventionele manier om builds te automatiseren is door een makefile te gebruiken. GitHub Actions kunnen ook worden gebruikt om dezelfde resultaten te bereiken.
Het tweede deel van het behalen van SLSA Niveau 1 is het genereren van volledige herkomstdocumentatie. Dit zijn metadata die laten zien hoe een softwareartefact is gebouwd. Het moet het hele bouwproces beschrijven, alle afhankelijkheden en bronnen op het hoogste niveau die bij het bouwen ervan worden gebruikt.
Door het bouwproces op deze manier te scripten en de herkomst van een softwareartefact te tonen, wordt het voor consumenten gemakkelijker om weloverwogen beslissingen te nemen over het gebruik van een softwareproduct. Hoewel SLSA 1-verificatie niet betekent dat de software volledig beschermd is tegen manipulatie, maakt het het wel gemakkelijker om de componenten van de software te identificeren. Dit is de eerste fase in het beheersen van kwetsbaarheden.
Niveau 2 – Zorg ervoor dat uw bouwproces bestand is tegen manipulatie
Op niveau 2 van het SLSA-framework begint u met het nemen van maatregelen om ervoor te zorgen dat uw bouwproces zo fraudebestendig mogelijk is. Het behalen van niveau 2 van het SLSA-framework geeft de consument ook meer vertrouwen over de herkomst van de software.
Nogmaals, dit gebeurt in twee stappen, waarbij de eerste gebruik maakt van versiebeheer en de tweede waarbij een gehoste build-service wordt gebruikt om de herkomst te verifiëren. Voor de eerste stap wordt GitHub, GitLab of een andere soortgelijke service gebruikt om de code op te slaan en eventuele wijzigingen vast te leggen. Door eventuele versiewijzigingen op deze manier bij te houden, wordt het gemakkelijker om eventuele wijzigingen te begrijpen die tijdens het bouwen van het artefact op het artefact zijn aangebracht.
Hoewel niveau 2 herkomstdocumentatie vereist, net als niveau 1, is het verschil hier dat het softwareartefact moet worden geverifieerd door een gehoste bouwservice. De gehoste service fungeert als een vertrouwde derde partij die kan bevestigen dat het bouwproces dat wordt beschreven in het oorspronkelijke herkomstdocument accuraat is. GitHub Actions is een type hostingservice die een geverifieerde herkomst kan bieden.
Niveau 3: de beveiligingscontroles van SLSA
Op niveau 3 begint u met het implementeren van de specifieke beveiligingscontrole zoals benadrukt in het SLSA-framework. Om dit niveau te bereiken, moeten de bron- en bouwplatforms voor uw softwareartefacten voldoen aan specifieke normen die garanderen dat de bron controleerbaar is en dat de herkomst van de code kan worden vertrouwd. SLSA Level 3 biedt een veel sterkere garantie dat het artefact goed beschermd is tegen manipulatie en specifieke soorten bedreigingen.
Enkele van de specifieke vereisten van niveau 3 zijn onder meer:
- Broncode geverifieerde geschiedenis en retentie—Een geverifieerde geschiedenis van de broncode zorgt ervoor dat elke wijziging in de broncode van de software vergezeld gaat van een geverifieerde identiteit van de auteur, recensent of uploader die de wijziging heeft aangebracht, met specifieke tijdstempels van de wijziging. Ook deze wijzigingshistorie moet minimaal 18 maanden bewaard worden.
- Geïsoleerde constructies in kortstondige omgevingen—Om aan deze vereiste te voldoen, moeten de softwarebuilds worden geïmplementeerd in kortstondige omgevingen waar ze volledig onafhankelijk zijn van andere build-instances. Om dit te bereiken kunt u een service als GitHub Actions gebruiken, die een virtuele bouwmachine gebruikt om uw build op aanvraag te produceren.
- Bouwt als code—Deze criteria vereisen dat u uw buildbestanden als code behandelt. Dit betekent dat ze moeten worden opgeslagen in een versiebeheersysteem dat het mogelijk maakt om bouwprocessen opnieuw te creëren wanneer dat nodig is.
- Niet-falsifieerbare herkomst—Het doel van deze vereiste is om te voorkomen dat gebruikers knoeien met de herkomstdocumentatie die door de bouwservice is gegenereerd.
Niveau 4: Consumentenvertrouwen
Niveau 4 van het SLSA-framework is bedoeld om ervoor te zorgen dat er op geen enkele manier met de software is geknoeid. Alleen softwareartefacten die aan de volgende vereisten voldoen, kunnen niveau 4 van het raamwerk bereiken:
Beoordeling door twee personen van alle wijzigingen
Dit criterium vereist dat organisaties twee gekwalificeerde reviewers aanwijzen om alle voorgestelde wijzigingen in de softwarecode en componenten grondig te beoordelen. Dit beoordelingsproces door twee personen zorgt ervoor dat alleen vertrouwde en geverifieerde ontwikkelaars wijzigingen kunnen aanbrengen in softwareartefacten.
Een hermetisch en reproduceerbaar bouwproces
Er wordt gezegd dat een bouwproces hermetisch is wanneer alle invoer vooraf en buiten het bouwproces wordt gespecificeerd. Deze regel is van toepassing op de broncode en op alle compilers, bibliotheken en tools die bij de build worden gebruikt. Dit helpt de integriteit van alle import van derden te garanderen. De reproduceerbare bouwcriteria zijn geen verplichte vereiste, maar worden ook aanbevolen. De criteria vereisen dat het bouwproces dezelfde uitvoer produceert, ongeacht waar of wanneer het wordt uitgevoerd.
Technische vereisten om aan de SLSA-niveaus te voldoen
Het SLSA-framework stelt specifieke technische vereisten voor de verschillende niveaus. Deze vereisten zijn onderverdeeld in vijf hoofdcategorieën: bronvereisten, vereisten voor het bouwproces, algemene vereisten, vereisten voor de inhoud van de herkomst en vereisten voor het genereren van de herkomst. Elk van deze vereistencategorieën wordt hieronder belicht.
Bronvereisten
Hiermee worden eisen bedoeld die bedoeld zijn om de integriteit van uw broncode te waarborgen. Door deze sets protocollen te volgen, voorkomt u dat er met uw code wordt geknoeid en kwaadwillig wordt gewijzigd. Het zorgt er ook voor dat eventuele snode acties niet onopgemerkt blijven. De bronvereisten zijn vastgelegd in onderstaande tabel.
| Bronvereisten | Beschrijving | SLSA-niveau |
| Versiebeheer | Alle wijzigingen in de broncode moeten worden bijgehouden. | 2 |
| Geverifieerde geschiedenis | Er moet een uitgebreide geschiedenis worden vastgelegd met details over ‘wie’, ‘wat’ en ‘wanneer’ van elke versierevisie. | 3 |
| Voor onbepaalde tijd bewaard | Alle versiewijzigingen en geschiedenisinformatie moeten voor onbepaalde tijd worden bewaard en mogen niet worden verwijderd. | 4 |
| Tweepersoons beoordeeld | Twee vertrouwde en zeer geverifieerde mensen moeten elke versiewijziging autoriseren. | 4 |
Bouwvereisten
Het SLSA-framework benadrukt bouwvereisten die bedoeld zijn om de veiligheid van het bouwplatform te verbeteren en de integriteit van het bouwproces te behouden.
| Bouwvereisten | Beschrijving | SLSA-niveau |
| Gescripte constructie | Alle stappen van het bouwproces moeten volledig geautomatiseerd zijn. | 1 |
| Dienst opbouwen | Alle stappen van het bouwproces moeten worden uitgevoerd op een speciale bouwservice. | 2 |
| Kortstondige en geïsoleerde omgeving | Het bouwproces moet worden uitgevoerd in een kortstondige omgeving die speciaal voor de bouw is voorzien. De stappen moeten ook worden uitgevoerd in een geïsoleerde omgeving, vrij van andere build-instances.
|
3 |
| Parameterloos en hermetisch | Het bouwproces moet volledig afhankelijk zijn van het bouwscript in plaats van van gebruikersparameters. Alle transitieve bouwstappen moeten hermetisch zijn, wat betekent dat alle bronnen en afhankelijkheden volledig vooraf en buiten het bouwproces moeten worden aangegeven. | 4 |
Vereisten voor het genereren van herkomst
Deze vereisten zijn bedoeld om de bron van alle componenten van een software-asset te verifiëren. De vereisten voor het genereren van herkomst worden in de onderstaande tabel aangegeven.
| Vereisten voor het genereren van herkomst | Beschrijving | SLSA-niveau |
| Beschikbaar | De consument moet toegang hebben tot de herkomstinformatie in een aanvaardbaar formaat. | 1 |
| Verifieerbaar | De consument moet de authenticiteit van de verstrekte herkomstinformatie kunnen verifiëren. | 1 |
| Service-gegenereerd | Alle herkomstinformatie moet door de bouwservice worden gegenereerd.
|
2 |
| Niet-falsifieerbaar | Gebruikers kunnen herkomstgegevens niet vervalsen. | 3 |
| Volledige afhankelijkheden | De herkomstgegevens moeten alle afhankelijkheden omvatten die tijdens de bouwstappen worden gebruikt. | 4 |
Vereisten voor herkomstinhoud
De vereisten voor de herkomstinhoud verifiëren de identiteit en bron van alle artefacten, afhankelijkheden en bouwbeperkingen die in het bouwproces zijn gebruikt. Ze worden gemarkeerd in de onderstaande tabel.
| Vereisten voor herkomstinhoud | Beschrijving | SLSA-niveau |
| Identificeert artefact, bouwer, bron en toegangspunt. | ● Identificeert het uitvoerartefact
● Identificeert de build-entiteit ● Identificeert de bron via een onveranderlijke referentie ● Identificeert de opdracht die het buildscript heeft aangeroepen |
1 |
| Bevat alle buildparameters | Alle buildparameters moeten worden geïdentificeerd.
|
3 |
| Inclusief transitieve afhankelijkheden en reproduceerbare informatie | ● Omvat alle transitieve afhankelijkheden
● Als de build reproduceerbaar is, moet alle informatie worden verstrekt die nodig is om deze te reproduceren
|
4 |
| Inclusief metagegevens | Alle metadata moeten worden opgenomen om onderzoek te vergemakkelijken. | 0 |
Algemene vereisten
De algemene vereisten zijn van toepassing op softwareartefacten op SLSA-niveau 4. Van elk vertrouwd artefact wordt verwacht dat het aan deze vereisten voldoet. Ze omvatten basisbeveiligingsvereisten en logboeken waarin alle fysieke en externe toegang gedetailleerd wordt beschreven. De algemene vereisten bepalen ook een klein aantal platformbeheerders die de bepalingen in de SLSA-documentatie kunnen overschrijven.