Bedreigingen in de supply chain

Aanvallers publiceren kwaadaardige pakketten met namen die op populaire namen lijken, in de hoop op een fatale typefout.

• Typosquatting — reqeusts in plaats van requests
• Combosquatting — python-requests doet de echte naam na
• Afhankelijkheidsverwarring — een openbaar pakket publiceren met dezelfde naam als je interne privé-pakket, zodat een verkeerd geconfigureerde oplosser de versie van de aanvaller ophaalt

Bescherm jezelf door een vertrouwd intern register vast te zetten en privé-pakketten met een scope of naamruimte te gebruiken.

Een legitiem en breed vertrouwd pakket kan kwaadaardig worden wanneer het account van de beheerder wordt overgenomen of een kwaadwillende bijdrager publicatierechten krijgt.

Recente incidenten uit de praktijk laten zien dat aanvallers via phishing inloggegevens van beheerders buitmaken en daarna een besmette patchversie publiceren die tijdens de installatie tokens steelt.

• Verplicht 2FA op alle accounts die publiceren
• Geef de voorkeur aan pakketten met publicatietokens met een scope en beveiligde uitgaven
• Let op onverwachte nieuwe beheerders bij kritieke afhankelijkheden

In veel ecosystemen wordt tijdens de installatie code uitgevoerd, nog voordat je toepassing zelf draait. Met npm install kan een postinstall-hook worden uitgevoerd die omgevingsvariabelen of SSH-sleutels steelt.

Schakel willekeurige installatiescripts uit in CI en controleer elk pakket dat ze nodig heeft:

De bouwomgeving zelf is een waardevol doelwit. Als een aanvaller een compiler, CI-uitvoeringsimage of bouwplug-in besmet, krijgt elk artefact dat daarmee wordt geproduceerd een achterdeur, zelfs wanneer je broncode schoon is.

Een klassiek voorbeeld is een met een trojan besmet update-mechanisme dat malware ondertekent met een legitieme code-ondertekeningssleutel, zodat slachtoffers die als authentiek accepteren.

• Behandel de bouwinfrastructuur als een productieomgeving en beveilig die volledig
• Gebruik tijdelijke, reproduceerbare bouwuitvoerders
• Houd ondertekeningssleutels gescheiden van de bouwserver

Een vergrendelingsbestand legt exacte versies en hashes van de inhoud vast, zodat het opnieuw oplossen van afhankelijkheden niet ongemerkt een ander artefact kan invoegen. Leg het altijd vast in versiebeheer en laat CI het controleren in plaats van afhankelijkheden vrijelijk opnieuw op te lossen.

Het integriteitsveld bevat een hash. Als het gedownloade tar-archief daar niet mee overeenkomt, mislukt de installatie.

Versies met bekende kwetsbaarheden, bijgehouden als CVE's, vormen de meest voorkomende zwakke plek in de toeleveringsketen. Hulpmiddelen voor analyse van softwaresamenstelling (SCA) vergelijken je opgeloste afhankelijkheden met kwetsbaarheidsdatabases.

Voer scans uit in CI en laat het bouwen mislukken bij kritieke bevindingen:

Zwevende versiebereiken (^1.2.0) laten nieuwe uitgaven automatisch binnenkomen. Dat is handig, maar stelt je bloot aan een kwaadaardige patch.

• Zet vast op exacte versies en beoordeel upgrades bewust
• Zet vast met een digest voor containerimages, niet met veranderlijke tags zoals latest
• Neem kritieke afhankelijkheden op in je eigen codeopslag of spiegel, zodat het verwijderen ervan door de upstreambron je niet kan hinderen of besmetten

Het beveiligen van de toeleveringsketen is voortdurend werk, geen eenmalige scan. Je moet weten wat je uitlevert, waar het vandaan komt en wanneer het kwetsbaar wordt.

• Genereer voor elke uitgave een SBOM (volgende les)
• Leg de bouwherkomst vast, zodat je kunt aantonen hoe een artefact is geproduceerd
• Abonneer je op beveiligingsadviezen, zodat een nieuw bekendgemaakte CVE leidt tot een nieuwe beoordeling van al uitgeleverde bouwresultaten

Breng elke fase in kaart waarin niet-vertrouwde invoer binnenkomt: machines van ontwikkelaars, broncodebeheer, registers voor afhankelijkheden, het bouwsysteem, artefactopslag en het updatekanaal. Elk daarvan is een mogelijk injectiepunt.

Vraag bij elke fase: wie kan hier schrijven, wat zouden ze bij een overname kunnen doen en hoe zou ik dat detecteren? Zo ontstaat een geprioriteerde lijst met beheersmaatregelen in plaats van een algemene controlelijst.

Je hebt geleerd waarom afhankelijkheden aanvalsoppervlakken vormen en hoe je die blootstelling kunt beperken.

• Omkering van vertrouwen betekent dat je beveiliging afhankelijk is van derden die je niet beheert
• Belangrijke bedreigingen zijn typosquatting, afhankelijkheidsverwarring, overname van beheerdersaccounts, kwaadaardige installatiescripts en gecompromitteerde bouwtools
• Belangrijke verdedigingen zijn vergrendelingsbestanden met integriteitshashes, SCA-scans, exacte versies vastzetten met een digest, 2FA voor uitgevers en doorlopende bewaking

Vervolgens inventariseer je precies wat je software bevat met een SBOM.