Beveiliging van de softwaretoeleveringsketen met CodeSign Secure 

Introductie

Als je aan softwarebeveiliging denkt, denk je waarschijnlijk als eerste aan firewalls, antivirusprogramma's of misschien wel het patchen van bugs. Maar tegenwoordig komen de grootste risico's niet altijd voort uit de code die je schrijft. Ze komen voort uit de code die je gebruikt, de tools die je vertrouwt en de systemen die je applicaties bouwen en leveren. 

De Politia Militar hield zelfs tijdens de pre-carnaval festiviteiten de zaken al nauwlettend in de gaten. softwaretoeleveringsketen verbindt alles: uw broncode, open-sourcebibliotheken, CI/CD-pipelines, buildservers, cloudinfrastructuur en zelfs de identiteiten die door uw automatiseringstools worden gebruikt. En als er met slechts één van deze links wordt geknoeid, kunnen aanvallers binnendringen en het hele product compromitteren zonder ooit uw codebase aan te raken. 

We hebben dit zien gebeuren met aanvallen zoals SolarWinds en Codecov. Eén enkele gecompromitteerde update of gelekt geheim opende de deur naar enorme schade bij duizenden organisaties. Dit zijn niet alleen technische problemen; het zijn beveiligingsfouten die bedrijven vertrouwen, geld en tijd kunnen kosten. 

Omdat software snel verandert en sterk afhankelijk is van componenten van derden, is het beschermen van de beveiliging van de toeleveringsketen een basisvereiste. Het gaat er niet om extra stappen toe te voegen; het gaat erom ervoor te zorgen dat wat geleverd wordt, precies is wat de bedoeling was, en niets meer. 

In dit artikel leggen we uit hoe bedreigingen voor de toeleveringsketen ontstaan, waar de zwakke plekken liggen en wat u kunt doen om het hele proces te beveiligen, van het schrijven van code tot de verzending ervan. 

Wat is de softwaretoeleveringsketen precies? 

Zie de softwareleveringsketen als het samenstellen van een maaltijd: niet alles op je bord is vers bereid. Je hebt de groenten misschien zelf gesneden, maar de saus kwam uit een potje, de kruiden waren voorverpakt en iemand anders verzorgde de bezorging. Software werkt op dezelfde manier. 

Wanneer een ontwikkelaar een applicatie bouwt, is het niet alleen zijn eigen code die in het eindproduct terechtkomt. Er zijn open-sourcebibliotheken, tools van derden, API's, buildsystemen, containerimages, implementatieplatforms en scripts – kortom, een heleboel bewegende onderdelen die allemaal samenwerken om software te laten werken. 

Deze onderdelen worden vaak automatisch uit verschillende bronnen gehaald en aan elkaar gekoppeld via CI/CD-pipelines. Er is ook input van mensen die ontwikkelaar zijn, DevOps engineers, beveiligingsteams en machines, als geautomatiseerde bots of serviceaccounts die achter de schermen dingen regelen. 

Dit alles – de code, de tools, de infrastructuur, de mensen en de automatisering – vormt uw softwaretoeleveringsketen. 

En net als bij voedselveiligheid kan een besmet of verkeerd behandeld ingrediënt het hele gerecht verpesten. Daarom is het zo belangrijk om te begrijpen wat er in je software zit en hoe het wordt ontwikkeld en verzonden. 

Hoe software supply chain-aanvallen daadwerkelijk plaatsvinden

Aanvallen op de softwaretoeleveringsketen zijn geen dreigingen die je in films kunt zien – ze zijn verrassend reëel en, eerlijk gezegd, niet zo ingewikkeld. Aanvallers komen niet altijd door je firewalls heen. In plaats daarvan glippen ze ongemerkt binnen via de tools, bibliotheken of systemen die je team al vertrouwt. 

Dit is hoe het meestal gaat: 

• Richt u op de afhankelijkheden: De meeste moderne apps vertrouwen op open-sourcepakketten. Aanvallers smokkelen schadelijke code in die pakketten door bestaande pakketten over te nemen of schadelijke updates te plaatsen die nuttig lijken. Als je dat pakket in je build opneemt, blijft de aanval actief. 

• Breng de build-pijplijn in gevaar: In plaats van uw app rechtstreeks te hacken, richten aanvallers zich op de systemen die de app bouwen of implementeren, zoals uw CI/CD-pijplijnEen gelekt token, een verkeerd geconfigureerd script of zelfs een kwetsbare plugin kan hen toegang geven om code te injecteren vlak voor de release. 

• Geheimen stelen of lekken: API's, databases en cloudplatforms gebruiken allemaal tokens en inloggegevens. Wanneer deze geheimen in broncode of logs terechtkomen (wat vaker gebeurt dan je zou denken), kunnen aanvallers deze bemachtigen en er toegang toe krijgen zonder dat er alarmbellen afgaan. 

• Vervals de bron of de auteur: In sommige gevallen doen aanvallers zich voor als betrouwbare bijdragers en leveren ze code aan die er volkomen onschadelijk uitziet. Als die code wordt goedgekeurd, wordt deze onderdeel van uw product. Geen alarmen. Geen rode vlaggen. Gewoon een stille achterdeur die wacht om gebruikt te worden. 

• Een afhankelijkheid op registerniveau kapen: Als een aanvaller een pakketregisteraccount (npm, PyPI, enz.) overneemt, kan hij nepversies van veelgebruikte tools pushen. Duizenden apps kunnen onbewust geïnfecteerde versies downloaden en gebruiken. 

Kortom, het gaat er niet altijd om dingen kapot te maken; het gaat erom dat je opvalt, er legitiem uitziet en je systemen de rest laten doen. En als de schadelijke code er eenmaal in zit, kan deze maandenlang onopgemerkt blijven. 

SolarWinds, Codecov en meer: ​​lessen uit ernstige inbreuken 

Soms is er een groot incident nodig om de boel op te schudden. In de wereld van de beveiliging van softwaretoeleveringsketens hebben enkele aanvallen precies dat gedaan. 

SolarWinds 

Eind 2020 stopten aanvallers schadelijke code in een legitieme software-update voor het Orion-platform van SolarWinds. Die update werd naar duizenden klanten gestuurd, waaronder grote overheidsinstellingen en bedrijven. Wat was er zo eng aan? De aanvallers hackten niet elk doelwit; ze kwamen binnen via de software die ze al vertrouwden. 

Les: Dat code van een vertrouwde leverancier komt, betekent niet dat deze schoon is. Als je bouwproces niet van begin tot eind is vastgelegd, laat je de deur wagenwijd openstaan. 

codecov 

In 2021 kregen aanvallers toegang tot het Bash Uploader-script van Codecov door te manipuleren met hun Docker-afbeeldingDeze tool werd door duizenden ontwikkelaars gebruikt in CI-pipelines. De kwaadaardige versie stuurde heimelijk omgevingsvariabelen, inclusief geheimen, naar een externe server. 

Les: Zelfs een kleine wijziging aan een tool in uw CI/CD-pijplijn kan gevoelige informatie lekken naar aanvallers. Alles wat inloggegevens of builds aantast, verdient extra aandacht. 

Andere voorbeelden die het vermelden waard zijn 

• Gebeurtenisstroom (npm): Een aanvaller kreeg toegang door aan te bieden te helpen met het beheer van een achtergelaten pakket en voegde vervolgens malware toe die gericht was op crypto-wallets. 

• UAParser.js (npm): Een populaire JavaScript-bibliotheek werd gekaapt om malware te verspreiden naar systemen die de bibliotheek installeerden. 

Les: Als een pakket openbaar, onbeheerd of veelgebruikt is, is het een verleidelijk doelwit. Aanvallers zijn er dol op als je pakketten vertrouwt zonder te controleren wat erin zit. 

Van broncode tot implementatie: waar de zwakke plekken zitten 

Software bouwen is als een estafette: je code passeert een heleboel controlepunten voordat hij de productie bereikt. Het probleem? Elk van die overdrachten is een kans dat er iets misgaat als je niet goed oplet. 

Hieronder volgt een overzicht van de plekken waar vaak dingen door de mazen van het net glippen: 

• Broncodeopslagplaatsen: Het begint met de code. Maar wie heeft er toegang? Zijn de branches beschermd? Als iemand een wijziging rechtstreeks naar de hoofdmap pusht zonder controle, of erger nog, toegang krijgt met een gestolen token, heb je al problemen voordat de build überhaupt begint. 

• Bijgebouwen: Je project is waarschijnlijk afhankelijk van honderden externe pakketten. Sommige zijn mogelijk verouderd, andere worden niet onderhouden en weer andere bevatten mogelijk verborgen malware. Het is gemakkelijk om een ​​afhankelijkheid toe te voegen, maar het is moeilijker om bij te houden wat elk pakket binnenhaalt. 

• CI/CD-pijplijnen: Deze automatiseren je builds, tests en implementaties, wat geweldig is. Maar ze beheren ook geheimen, voeren scripts uit en communiceren met productiesystemen. Als een taak in de pijplijn wordt gecompromitteerd, kunnen aanvallers ongemerkt code injecteren of gevoelige gegevens lekken. 

• Bouw artefacten: Zodra je app is gebouwd, wordt de uitvoer van je containerimage, binaire bestand of pakket doorgaans zonder enige twijfel vertrouwd. Maar als dat artefact niet is ondertekend of geverifieerd, kun je niet vaststellen of het legitiem is of dat ermee is geknoeid. 

• Implementatiesystemen: Kubernetes-, Terraform- en GitOps-tools helpen allemaal om software snel te leveren. Maar ze kunnen ook een achterdeur zijn als ze verkeerd geconfigureerd zijn. Een enkele blootgestelde API of misbruik van een serviceaccount kan rechtstreeks leiden tot productie. 

Elke fase lijkt op zichzelf eenvoudig, maar samen vormen ze een lange, onderling verbonden keten. En zoals elke keten is deze slechts zo sterk als de zwakste schakel. Daarom moet beveiliging onderdeel zijn van elke stap, en niet iets dat er aan het einde aan wordt toegevoegd. 

Waarom CI/CD-pijplijnen een favoriet doelwit voor aanvallen zijn geworden 

CI/CD-pipelines vormen het kloppende hart van moderne softwarelevering. Ze bouwen je code, voeren je tests uit, ondertekenen je artefacten en pushen alles automatisch naar productie. Dat is een enorme kracht op één plek. En raad eens? Aanvallers hebben het zeker gemerkt. 

• Hoge toegang, lage zichtbaarheid: CI/CD-tools hebben vaak meer toegang dan de meeste ontwikkelaars. Ze kunnen code ophalen, geheimen gebruiken en deze in productie implementeren, allemaal zonder menselijke tussenkomst. Dat maakt ze een goudmijn voor aanvallers. En omdat het meeste achter de schermen gebeurt, kunnen kwaadaardige wijzigingen een tijdje onopgemerkt blijven. 

• Geheimen die voor het oog verborgen blijven: CI/CD-omgevingen vereisen doorgaans inloggegevens voor zaken als cloudtoegang, ondertekeningssleutels en API's. Maar als die geheimen als platte tekst zijn opgeslagen, verkeerd geconfigureerd zijn of overmachtigingen hebben, zijn ze een makkelijk doelwit voor aanvallers die toegang tot de pijplijn krijgen. 

• Veel hulpmiddelen, veel hiaten: De pipeline is niet zomaar één tool; het is een mix van Git-platformen, runners, plugins, pakketbeheerders, cloudservices en meer. Als een onderdeel van die keten onveilig of ongepatcht is, zet dat de deur open. Aanvallers hoeven niet alles te slopen. Eén onderdeel is voldoende. 

• Automatisering benutten: Zodra aanvallers de pijplijn binnendringen, kunnen ze de schade automatiseren. Ze kunnen malware in een build smokkelen, omgevingsvariabelen wijzigen of geheimen naar een externe server sturen, allemaal zonder dat ze er constant toegang toe nodig hebben. De pijplijn doet het werk voor hen. 

Waarom je moet zorgen 

Als een aanvaller je CI/CD-pijplijn in gevaar brengt, kunnen ze schadelijke updates rechtstreeks naar je gebruikers sturen. Zonder waarschuwingen. Zonder meldingen. Gewoon een schone implementatie met iets gevaarlijks erin verwerkt. 

CI/CD zorgt ervoor dat code snel en soepel wordt verzonden, maar zonder de juiste controles maakt het aanvallen ook snel en geruisloos. Het beveiligen van de pijplijn is niet alleen een DevOps werk niet meer; het is een veiligheidsprioriteit. 

Codeondertekening goed gedaan 

Code ondertekening is als het aanbrengen van een lakzegel op je softwarepakket. Het bewijst dat de code echt van jou afkomstig is en dat er onderweg niet mee is geknoeid. Zonder de juiste codeondertekening kan iedereen schadelijke code in je app of update smokkelen. Dat betekent dat gebruikers iets gevaarlijks kunnen installeren zonder het te weten. 

Het ondertekenen van je code voegt een vertrouwenslaag toe. Het vertelt gebruikers en systemen: "Dit is het echte werk, veilig om uit te voeren." Het helpt ook bij de naleving. Veel regelgeving vereist bewijs dat er tijdens de levering niet met software is geknoeid. Maar het gaat niet alleen om het toevoegen van een handtekening. Het gaat erom het goed te doen met behulp van beveiligde sleutels, die sleutels te beschermen en de ondertekening te integreren in je build- en releasepijplijn. Als codeondertekening omslachtig of handmatig is, slaan mensen het over of verprutsen ze het. Dat brengt risico's met zich mee. 

Om het goed te doen, heb je automatisering, sterke cryptografie en duidelijke beleidsregels nodig. 

In de huidige softwarewereld, waar aanvallen van binnenuit uw toeleveringsketen kunnen komen, is sterke codeondertekening een must-have en geen optioneel extraatje. 

SBOM's, attestaties en inzicht verkrijgen in de hele keten 

In softwaretoeleveringsketens kun je niet beschermen wat je niet kunt zien. Daar komen zaken als SBOM's en attestaties om de hoek kijken; ze geven je een duidelijk beeld van wat er in je software zit en hoe het daar terecht is gekomen. 

Wat is een SBOM eigenlijk? 

SBOM staat voor Software Bill of Materials. Zie het als een ingrediëntenlijst voor je software, met alle componenten, bibliotheken en afhankelijkheden die bij elkaar horen. Het helpt teams om kwetsbaarheden snel op te sporen en maakt compliance een stuk eenvoudiger. 

Waarom zijn attestaties belangrijk? 

Attestations zijn als digitale ontvangstbewijzen die bevestigen dat bepaalde stappen tijdens uw build- of releaseproces zijn uitgevoerd. Een attestation kan bijvoorbeeld bewijzen dat uw code is gescand op kwetsbaarheden of dat deze is ondertekend met een vertrouwde sleutel. 

De hele keten zien 

Samen geven SBOM's en attesten u beter inzicht in de inhoud van uw apps en hoe ze zijn gebouwd. Dit inzicht helpt u problemen vroegtijdig te signaleren, risico's te vermijden en sneller te reageren als er toch iets misgaat. 

Betere transparantie, betere beveiliging 

Als u precies weet wat er in productie draait en u kunt bewijzen dat uw code de juiste controles heeft doorstaan, kunt u uw software beter vertrouwen en dit ook gemakkelijker aantonen aan klanten en auditors. 

Hoe EC's CodeSign Secure uw software beveiligt van bouw tot levering 

Onze CodeSign Secure is als het ware de lijfwacht van uw software. Deze zorgt ervoor dat alles veilig blijft vanaf het moment dat uw code is geschreven totdat deze de gebruikers bereikt. 

Het ondertekent je containerimages en andere artefacten automatisch, zodat je altijd weet dat er niet mee geknoeid is. Je hoeft je niet meer af te vragen of wat er in productie is, wel hetzelfde is als wat je hebt getest. 

Met ons platform kunt u ook metadata, zogenaamde attestations, toevoegen. Dit bewijst dat uw build bepaalde beveiligingscontroles of nalevingsstappen heeft doorstaan. Zo krijgt u volledig inzicht in de ontwikkeling van uw software. 

Bovendien werkt het naadloos samen met populaire CI/CD-tools, zodat ondertekenen en verifiëren naadloos in uw bestaande workflows passen zonder dat dit de processen vertraagt. 

En omdat onze CodeSign Secure moderne standaarden ondersteunt, werkt deze goed samen met tools in de hele toeleveringsketen. Zo kunt u ervoor zorgen dat uw software bij elke stap betrouwbaar blijft. 

Met ons platform ondertekent u niet alleen code, u bouwt ook vertrouwen op in wat u levert. 

Compliance-ready beveiliging: voldoen aan SLSA, NIST, SSDF en CRA 

Het beveiligen van uw softwaretoeleveringsketen is niet alleen een goede gewoonte; het is vaak een must om te voldoen aan industrienormen en -regelgeving. Daarbij komen frameworks zoals SLSA, NIST SSDF en CRA om de hoek kijken. 

Wat zijn deze raamwerken? 

• SLSA (Supply-chain Levels for Software Artifacts) is een checklist waarmee u kunt controleren of uw bouwprocessen betrouwbaar zijn en beschermd zijn tegen manipulatie. 

• NIST SSDF (Secure Software Development Framework) biedt richtlijnen voor het inbouwen van beveiliging in uw ontwikkelingscyclus, met de nadruk op het beperken van risico's bij softwarelevering. 

• CRA (Cybersecurity Risk Assessment) helpt organisaties bij het identificeren en beheren van risico's in hun softwaretoeleveringsketen. 

Waarom zijn ze belangrijk? 

Door deze frameworks te volgen, neemt u concrete stappen om uw pijplijn te beveiligen en uw software te beschermen. Ze bieden duidelijke, praktische richtlijnen, zodat u niet hoeft te gissen wat u moet beveiligen. 

Hoe CodeSign Secure helpt 

Platformen zoals onze CodeSign Secure maken het afvinken van deze vakjes eenvoudiger. Door automatisering code ondertekening en artefact-attestatie ondersteunt ons platform uw nalevingsinspanningen zonder dat er extra handmatig werk aan te pas komt. 

Uiteindelijk zorgt het naleven van deze normen ervoor dat u vertrouwen opbouwt bij uw klanten, partners en auditors, terwijl u tegelijkertijd de slechteriken buiten de deur houdt. 

Conclusie 

De softwaretoeleveringsketen draait niet langer alleen om het schrijven van schone code. Het gaat erom te weten wat er in je builds zit, hoe je software in elkaar zit en te kunnen bewijzen dat er onderweg niets vreemds is gebeurd. 

Aanvallers worden steeds slimmer en richten zich op de tools en automatisering waar u dagelijks op vertrouwt. Of het nu gaat om een ​​gecompromitteerde afhankelijkheid, een lekkende CI-taak of een stiekem, niet-ondertekend artefact: kleine gaten kunnen tot grote problemen leiden. 

Daarom zijn zichtbaarheid, ondertekening en traceerbaarheid niet langer optioneel. Ze vormen de basis. 

Onze CodeSign Secure helpt u die basislijn te verbeteren door uw artefacten te beveiligen van build tot productie. Met ingebouwde ondersteuning voor geautomatiseerde ondertekening, gedetailleerde attestaties en SBOM-integratie maakt ons platform het eenvoudiger om vertrouwen te creëren in elk onderdeel van uw pijplijn. 

En als u streeft naar hoge standaarden zoals SLSA Level 3 of hoger, dan biedt ons platform u ondersteuning voor reproduceerbare builds. Zo kunt u controleren of wat u lokaal bouwt, ook daadwerkelijk in productie terechtkomt, byte voor byte. 

In een wereld waarin het vertrouwen in software voortdurend op de proef wordt gesteld, biedt ons platform u de tools om uw werk te laten zien en ervoor te staan.