Codeondertekening 101: uw softwareleveringsketen beveiligen

Elke keer dat u een software-update downloadt, een browserextensie installeert of een bedrijfsapplicatie uitvoert, vertrouwt u die software volledig. Maar hoe weet u eigenlijk zeker dat er niet mee is geknoeid – dat het daadwerkelijk van de leverancier komt die het beweert te hebben, en niet van een aanvaller? Het antwoord is... code ondertekening. 

Als leiders op het gebied van beveiliging hebben organisaties jarenlang geïnvesteerd in het versterken van applicatiebeveiliging, cloudbeheer en identiteitsbeheer. Maar een van de meest over het hoofd geziene vertrouwensankers in de softwarelevenscyclus is nog steeds codeondertekening. Veel organisaties kampen nog steeds met hetzelfde probleem: ze investeren fors in veilige ontwikkeling, maar laten het uiteindelijke releaseproces gefragmenteerd, handmatig en moeilijk te beheren.  

De toenemende frequentie van cyberaanvallen gericht op softwarekwetsbaarheden vereist robuuste mechanismen om de authenticiteit en veiligheid van softwarecode te waarborgen. Door codeondertekening te implementeren, kunnen ontwikkelaars vertrouwen wekken bij gebruikers en hen verzekeren dat de software die ze installeren legitiem en vrij van malware is. En naarmate de industrie volwassener wordt, ontstaan ​​er nieuwe praktijken, zoals keyless signing (waarbij kortstondige certificaten lang bestaande privésleutels vervangen, waardoor sleutelbeheer volledig overbodig wordt) en Software Stuklijst (SBOM) Integratie (die een machinaal leesbare inventarisatie biedt van elk onderdeel in een software-artefact) verandert de manier waarop een alomvattende ondertekeningsstrategie eruitziet. Om de cruciale rol ervan te begrijpen, is het essentieel om de complexe processen te onderzoeken, waaronder die met betrekking tot transparantie, geldigheid en beveiliging. 

Wat is codeondertekening en waarom is het belangrijk? 

In essentie is codeondertekening het proces waarbij een digitale handtekening voor software — of het nu gaat om een ​​uitvoerbaar bestand, een script, een driver, een firmware-image of een container. Deze handtekening dient twee essentiële doelen: 

1. authenticatie — Het bewijst wie de software heeft gemaakt of gepubliceerd. 
2. Integriteit — Het garandeert dat de code niet is gewijzigd sinds deze is ondertekend. 

Volgens hetzelfde CleanStart-rapport was in 2025 35% van de aanvallen op de toeleveringsketen afkomstig van gecompromitteerde softwareafhankelijkheden, 22% was gericht op CI/CD-pipelines en buildomgevingen, en 20% betrof besmette of niet-geverifieerde containerimages. Ze ontdekten ook dat software supply chain-aanvallen Het aantal incidenten is wereldwijd meer dan verdubbeld in 2025, met wereldwijde verliezen van $60 miljard en meer dan 70% van de organisaties die dat jaar minstens één beveiligingsincident in de toeleveringsketen melden. Wat deze cijfers bijzonder alarmerend maakt, is dat aanvallers zich niet langer richten op de perimeter, maar via het bouwproces zelf binnendringen.  

Wanneer je code ondertekent, is het belangrijk om te weten dat de handtekening alleen geldig is zolang het ondertekeningscertificaat geldig is. Software overleeft echter vaak de geldigheidsduur van het certificaat. Een betrouwbare tijdstempel, uitgegeven door een RFC 3161-compatibele Timestamp Authority (TSA) op het moment van ondertekening, koppelt de handtekening cryptografisch aan een specifiek tijdstip. Dit betekent dat de handtekening geldig blijft, zelfs nadat het ondertekeningscertificaat is verlopen, omdat de tijdstempel bewijst dat de ondertekening plaatsvond terwijl het certificaat nog actief was. Zonder tijdstempels zou je volledige ondertekende versie onbetrouwbaar kunnen worden zodra je certificaat verloopt. 

Een ander belangrijk concept is dat als een ondertekeningssleutel wordt gecompromitteerd, het bijbehorende certificaat onmiddellijk moet worden ingetrokken. Certificaatintrekkingslijsten (CRL's) zijn periodiek gepubliceerde lijsten met ingetrokken certificaten. Online Certificaat Status Protocol (OCSP) Biedt realtime controles op intrekking per certificaat. Besturingssystemen en beveiligingstools raadplegen deze mechanismen om te verifiëren of een certificaat niet is ingetrokken voordat een handtekening wordt vertrouwd. Een robuust codeondertekeningsprogramma moet een getest intrekkingsplan bevatten — niet alleen de mogelijkheid om in te trekken, maar ook een gedocumenteerd proces voor het intrekken, opnieuw ondertekenen en snel herdistribueren van de betreffende artefacten. 

Platformspecifieke controles voegen een extra laag van vertrouwensvalidatie toe. Op Windows evalueert SmartScreen de reputatie van ondertekende uitvoerbare bestanden. Software met een EV-ondertekening en een gevestigde reputatie omzeilt de waarschuwing 'Onbekende uitgever', die gebruikers kan afschrikken en het vertrouwen kan ondermijnen. Op macOS controleert Gatekeeper of applicaties zijn ondertekend met een door Apple uitgegeven ontwikkelaars-ID-certificaat en of ze de notariële verificatie hebben doorstaan ​​– Apple's geautomatiseerde malware-scan. Op Linux verifiëren pakketbeheerders zoals apt en dnf de GPG-handtekeningen van pakketten vóór installatie. Inzicht in deze platformspecifieke controles helpt beveiligingsteams bij het ontwerpen van workflows voor softwareondertekening die leiden tot een probleemloze en betrouwbare softwarelevering. 

Zonder codeondertekening hebben gebruikers en systemen geen betrouwbare manier om legitieme software te onderscheiden van kwaadaardige namaaksoftware. Het is echter belangrijk te begrijpen dat codeondertekening geen garantie biedt dat software veilig, onschadelijk of vrij van kwetsbaarheden is. Een geldige handtekening bewijst de integriteit en herkomst, niet de kwaliteit of intentie. Als een ondertekeningssleutel is gecompromitteerd, of als gebrekkige code wordt ondertekend door een legitieme uitgever, kan de handtekening alsnog succesvol worden gevalideerd. Voor besluitvormers is dit onderscheid essentieel: codeondertekening is een noodzakelijke controle, maar moet hand in hand gaan met veilige ontwikkeling, het versterken van de pipeline, toegangscontrole en monitoring. 

Begin 2025 werden cybercriminelen betrapt op het misbruiken van Microsofts Trusted Signing-service om malware te ondertekenen met kortstondige certificaten van drie dagen. Hierdoor leken kwaadaardige payloads volledig betrouwbaar en werden traditionele beveiligingsmaatregelen omzeild. De certificaten waren technisch geldig en correct geverifieerd; het probleem lag niet bij de infrastructuur, maar bij het feit dat aanvallers er toegang toe hadden gekregen. Dit illustreert treffend de kernbeperking van codeondertekening: een geldige handtekening bewijst dat iemand met ondertekeningsrechten de software heeft gemaakt, niet dat de software veilig is. De infrastructuur voor ondertekening moet worden versterkt, de toegang strikt worden gecontroleerd en afwijkende ondertekeningsactiviteiten moeten vrijwel in realtime worden gedetecteerd, want wanneer het ondertekeningsproces wordt gecompromitteerd, wordt de handtekening het krachtigste wapen van de aanvaller. 

De Cryptografische Stichting 

Om codeondertekening echt te begrijpen, heb je een basiskennis nodig van... Publieke Sleutel Infrastructuur (PKI) en asymmetrische cryptografie. 

Asymmetrische sleutelparen 

Elke identiteit voor codeondertekening is gebaseerd op een sleutelpaar: 

• A private key — geheim gehouden door de software-uitgever. Dit wordt gebruikt om en je merk te creëren  de handtekening. 
• A public keys — openlijk gedeeld. Dit wordt gebruikt om controleren de handtekening. 

De wiskundige relatie tussen deze twee sleutels is eenrichtingsverkeer: je kunt ondertekenen met de privésleutel en verifiëren met de publieke sleutel, maar je kunt de privésleutel niet afleiden uit de publieke sleutel. De keuze van het algoritme is van groot belang. De drie algoritmen die tegenwoordig het meest worden gebruikt voor het ondertekenen van codes zijn: 

RSA (Rivest-Shamir-Adleman) — Het meest gangbare algoritme, dat doorgaans wordt gebruikt met 2048-bits of 4096-bits sleutels. RSA Het wordt universeel ondersteund door besturingssystemen en tools, maar door de grotere sleutelgrootte is het trager dan moderne alternatieven met een vergelijkbaar beveiligingsniveau. 

ECDSA (Elliptic Curve Digital Signature Algorithm) — Maakt gebruik van wiskunde met elliptische krommen om een ​​vergelijkbare beveiliging als RSA te bereiken met aanzienlijk kleinere sleutelgroottes. Een 256-bits sleutel. ECDSA De ECDSA-sleutel (P-256) biedt ongeveer dezelfde beveiliging als een 3072-bits RSA-sleutel, met snellere generatie en verificatie van handtekeningen. ECDSA wordt steeds vaker gebruikt in prestatiegevoelige omgevingen met beperkte resources. 

EdDSA (Edwards-curve Digital Signature Algorithm) — De nieuwste van de drie, gebaseerd op gedraaide Edwards-curven (meestal Ed25519). EdDSA biedt uitstekende prestaties, sterke beveiligingseigenschappen en is bestand tegen bepaalde side-channel-aanvallen die ECDSA-implementaties kunnen treffen.  

Het ondertekeningsproces  

1. hashen: De software-uitgever voert de code door een cryptografische hashfunctie – minimaal SHA-256, aangezien SHA-1 cryptografisch onbruikbaar is en door de industrie wordt afgekeurd. NIST Sinds 2011 (en sinds 2016 verboden voor codeondertekening door grote certificeringsinstanties). SHA-256 produceert een "vingerafdruk" van de code met een vaste lengte, een zogenaamde digest. Zelfs een enkele gewijzigde bit in de code levert een volledig andere hash op. 
2. De hash ondertekenen: De uitgever versleutelt de hash met behulp van zijn privésleutel. Deze versleutelde hash is de digitale handtekening. 
3. De handtekening toevoegen: De handtekening, samen met die van de uitgever. certificaat (die de publieke sleutel bevat) wordt meegeleverd met de software. 

Het verificatieproces 

Wanneer een gebruiker de software downloadt en uitvoert, zorgt het besturingssysteem of de beveiligingssoftware ervoor dat: 

1. Haalt de handtekening en het certificaat uit het bestand. 
2. Valideert de certificaatketen door te controleren of het certificaat is uitgegeven door een vertrouwde CA, of het niet is verlopen en of het niet is ingetrokken (via CRL of OCSP). 
3. Valideert de tijdstempel, d.w.z. bevestigt dat de handtekening is geplaatst terwijl het certificaat actief was, waardoor de handtekening geldig blijft, zelfs na het verlopen van het certificaat. 
4. Gebruikt de publieke sleutel in het certificaat om de handtekening te decoderen en de oorspronkelijke hash te herstellen. 
5. Berekent onafhankelijk de hashwaarde van de gedownloade software. 
6. De twee hashes worden vergeleken. Als ze overeenkomen, is de software intact en afkomstig van de beweerde uitgever. Zo niet, dan mislukt de verificatie! De software is gemanipuleerd. 

De rol van certificeringsinstanties (CA's) 

Het is nu van cruciaal belang om te weten en te begrijpen wat een kwaadwillende ervan weerhoudt om simpelweg een eigen sleutelpaar te creëren en zich voor te doen als Microsoft of Adobe. 

Dit is waar Certificeringsautoriteiten (CA's) Kom binnen. Een CA (Certificate Authority) is een vertrouwde derde partij (zoals DigiCert, Sectigo of GlobalSign) die codeondertekeningscertificaten uitgeeft, maar alleen nadat de identiteit van de aanvrager is geverifieerd. De handtekening van de CA op het certificaat geeft het legitimiteit. Maar de vertrouwensinfrastructuur gaat veel verder dan een enkele CA. 

Hiërarchie van root-CA versus intermediaire CA 

Het PKI Het vertrouwensmodel is hiërarchisch. Aan de top staat de Root CA – een sterk beveiligde, vaak offline entiteit waarvan het certificaat zelfondertekend is en waarvan de publieke sleutel rechtstreeks in besturingssystemen en browsers is ingebed door leveranciers zoals Microsoft, Apple en Mozilla. Omdat het compromitteren van een Root CA catastrofaal zou zijn, worden de privésleutels van de root CA bewaard in geïsoleerde HSM's (Hardware Security Modules) en zelden gebruikt voor directe certificaatuitgifte. 

In plaats daarvan geven Root CA's certificaten uit aan Intermediate CA's (ook wel Subordinate CA's genoemd), die online zijn en de dagelijkse taak uitvoeren van het uitgeven van codeondertekeningscertificaten aan uitgevers. Dit creëert een vertrouwensketen: Root CA → Intermediate CA → Certificaat van de uitgever. Bij het verifiëren van een handtekening doorloopt het systeem deze keten en verifieert de handtekening van elk certificaat ten opzichte van het bovenliggende certificaat, helemaal terug naar een vertrouwde root. 

Vertrouwenswinkels 

Je besturingssysteem wordt geleverd met een vooraf geïnstalleerde vertrouwensopslag — een zorgvuldig samengestelde lijst van vertrouwde root-CA-certificaten. Windows beheert het Microsoft Trusted Root Certificate Program, macOS en iOS beheren de vertrouwensopslag van Apple en Linux-distributies vertrouwen op het ca-certificates-pakket (vaak afkomstig van het programma van Mozilla). Browsers zoals Chrome en Firefox kunnen hun eigen vertrouwensopslag hebben, onafhankelijk van het besturingssysteem. Wanneer een codeondertekeningscertificaat terug te voeren is op een root in de vertrouwensopslag, wordt de handtekening als vertrouwd beschouwd. Als de keten niet kan worden gevalideerd tot een vertrouwde root, wordt de handtekening afgewezen. 

Extended Validation (EV) Code Signing-certificaten 

Niet alle codeondertekeningscertificaten zijn gelijk. Standaard OV-certificaten (Organization Validation) vereisen dat de certificeringsinstantie (CA) verifieert dat de organisatie van de aanvrager wettelijk bestaat, maar deze verificatie is relatief eenvoudig. EV-certificaten (Extended Validation) vereisen een aanzienlijk strenger proces: 

• Verificatie van het juridisch bestaan ​​— de organisatie moet een geregistreerde rechtspersoon zijn die in goede staat van dienst verkeert binnen het betreffende rechtsgebied. 

• Fysiek adres en operationele aanwezigheid — de CA verifieert de fysieke locatie en operationele aanwezigheid van de organisatie. 

• Identiteit van de certificaataanvrager — de persoon die het certificaat aanvraagt, moet worden geverifieerd als een bevoegd vertegenwoordiger van de organisatie. 

• Telefoonverificatie — de CA neemt via een onafhankelijk geverifieerd telefoonnummer contact op met de organisatie om het verzoek te bevestigen. 

• Screening op witwaspraktijken en sancties — de organisatie en haar leidinggevenden worden gecontroleerd aan de hand van overheids- en regelgevingslijsten. 

Het resultaat is een certificaat met een veel sterkere identiteitsgarantie. Op Windows bouwt EV-ondertekende software direct een SmartScreen-reputatie op – waardoor de waarschuwing 'Onbekende uitgever' wordt omzeild – omdat Microsoft meer vertrouwen heeft in de geverifieerde identiteit achter het certificaat. EV-certificaten vereisen ook dat privésleutels worden opgeslagen in een hardwarebeveiligingsmodule (HSM)Dit verhoogt de drempel voor sleuteldiefstal aanzienlijk in vergelijking met OV-certificaten, die in software kunnen worden opgeslagen. 

Zelfondertekende certificaten Certificaten die intern zijn gegenereerd, zonder certificeringsinstantie (CA), zijn prima geschikt voor interne testomgevingen waar u beide kanten van de vertrouwensketen beheert. Maar ze mogen nooit worden gebruikt voor publiekelijk verspreide software. Er is geen vertrouwensketen; eindgebruikerssystemen zullen ze niet als legitiem herkennen en ze bieden geen garantie voor de identiteit van de uitgever. 

De softwaretoeleveringsketen 

Tot nu toe hebben we het gehad over het ondertekenen van één enkel softwareonderdeel. Maar moderne softwareontwikkeling is veel complexer. Uw product bevat waarschijnlijk: 

• Open-source bibliotheken en pakketten (npm, PyPI, Maven, NuGet, enz.) 
• SDK's en componenten van derden 
• CI/CD-pipeline-artefacten 
• Containerafbeeldingen 
• Infrastructuur-als-code scripts 
• Firmware en stuurprogramma's 
• Software Stuklijst (SBOM) 
• Containerimages en Docker-artefacten 

Elk van deze elementen vormt een potentieel toegangspunt voor een supply chain-aanval, en ondertekeningsstrategieën moeten ze allemaal dekken, niet alleen de uiteindelijke uitvoerbare bestanden. Containerimages moeten worden ondertekend met tools zoals CoSign en geverifieerd tijdens de implementatie. Het ondertekenen van artefacten voor build-outputs (JAR's, wheels) zorgt ervoor dat wat uit het buildsysteem komt overeenkomt met wat er is gebouwd. SBOM-ondertekening voegt een extra laag van attestatie toe aan de inventaris zelf, waardoor downstream-gebruikers niet alleen de software, maar ook de volledige lijst met componenten ervan kunnen verifiëren. 

• Complexiteit van ecosystemen

  Het open-source ecosysteem staat meer dan ooit onder de loep, en terecht. De enorme afhankelijkheid van pakketten van derden creëert een gigantisch aanvalsoppervlak. De meeste bedrijfsapplicaties gebruiken honderden of duizenden transitieve afhankelijkheden (pakketten die afhankelijk zijn van andere pakketten), waarvan vele worden onderhouden door individuen met beperkte middelen op het gebied van beveiliging.

  De kwartaalindex van Sonatype voor open-source malware registreerde een onophoudelijke toename gedurende 2025: in het eerste kwartaal werden bijna 18,000 nieuwe kwaadaardige pakketten ontdekt, in het derde kwartaal 34,319, een stijging van 140% ten opzichte van het tweede kwartaal, en in het vierde kwartaal van 2025 had Sonatype maar liefst 394,877 nieuwe open-source malwarepakketten in één kwartaal geïdentificeerd, grotendeels als gevolg van geautomatiseerde, zelfreplicerende campagnes. Het cumulatieve totaal aantal door Sonatype geïdentificeerde kwaadaardige pakketten sinds 2019 is de 877,000 gepasseerd.

• Escalatie van bedreigingen

  Nog verontrustender is dat 56% van de malware die in het eerste kwartaal van 2025 werd ontdekt, was ontworpen voor data-exfiltratie, met name gericht op ontwikkelaarsreferenties, CI/CD-geheimen en cloud-API-sleutels die op voorspelbare locaties op ontwikkelaarscomputers zijn opgeslagen. Deze gegevens vormen, eenmaal buitgemaakt, de sleutel tot het compromitteren van een complete ondertekeningspipeline. Een aanvaller met toegang tot een CI/CD-geheim of ontwikkelaarsreferentie kan potentieel kwaadaardige code in het buildproces injecteren, deze ondertekenen met een legitieme sleutel en verspreiden via officiële kanalen, allemaal zonder ooit de perimeter van de doelorganisatie te hoeven aanraken.

Een alomvattende strategie voor codeondertekening moet daarom de hele keten bestrijken, van de open-sourcepakketten die u gebruikt tot de artefacten die u produceert en distribueert. 

Het SLSA-raamwerk 

Het Supply Chain Levels for Software Artifacts (SLSA)-framework, ontwikkeld door Google, biedt een gelaagd model voor het evalueren en verbeteren van de integriteit van de toeleveringsketen. Het loopt van niveau 1 (basisdocumentatie) tot niveau 4 (de strengste controles). Codeondertekening is een cruciaal onderdeel voor het behalen van hogere SLSA-niveaus. Hieronder leggen we uit wat elk niveau in de praktijk betekent: 

SLSA Niveau 1Het bouwproces is gedocumenteerd en gescript. Broninformatie en metadata over hoe de artefacten zijn gebouwd zijn beschikbaar, maar niet geverifieerd. Dit zorgt voor een basisniveau van traceerbaarheid. 

SLSA Niveau 2De build wordt uitgevoerd op een gehoste buildservice (niet zomaar op de laptop van een ontwikkelaar) en de broncode wordt door de buildservice ondertekend. Dit betekent dat een aanvaller de buildservice zou moeten compromitteren, en niet alleen de computer van een ontwikkelaar, om de herkomst te vervalsen. 

SLSA Niveau 3De buildservice biedt sterkere isolatiegaranties en de originele data bevat informatie over de buildomgeving. De broncode moet afkomstig zijn van een versiebeheersysteem en de build moet beveiligd en beschermd zijn. 

SLSA Niveau 4: Vereist een beoordeling door twee personen van alle wijzigingen, met een reproduceerbare build en uitgebreide informatie over de broncode. Op dit niveau is de gehele keten van broncode tot artefact fraudebestendig en controleerbaar. 

Een van de belangrijkste en meest uitdagende aspecten van moderne codeondertekening is de integratie ervan in geautomatiseerde build-pipelines. Dit is waar veel organisaties struikelen. Volgens een onderzoek uit 2025 monitort minder dan 50% van de bedrijven momenteel meer dan 50% van hun uitgebreide softwareleveringsketen. Dit betekent dat aanvallers routinematig opereren in blinde vlekken waarvan organisaties het bestaan ​​niet eens weten. 

Veelvoorkomende valkuilen zijn: 

• Het opslaan van privésleutels in omgevingsvariabelen of configuratiebestanden. — Dit is een cruciale fout. Privésleutels die in platte tekst zijn opgeslagen in een CI/CD-omgeving, zijn slechts één verkeerd geconfigureerde toegangscontrole verwijderd van een totale inbreuk.  
• Het delen van ondertekeningsgegevens tussen teams — Als alle teams binnen uw organisatie dezelfde ondertekeningssleutel gebruiken, kan één gecompromitteerd ontwikkelaarsaccount leiden tot releases die op een kwaadwillige manier zijn ondertekend. 
• Ondertekenen op het verkeerde moment — Te vroeg ondertekenen in het proces betekent dat je ongeteste code ondertekent. Te laat ondertekenen kan hiaten veroorzaken waardoor niet-ondertekende codefragmenten tussen systemen kunnen circuleren. 
• Geen strategie voor sleutelrotatie — Ondertekeningssleutels moeten periodiek worden vernieuwd (minimaal jaarlijks en direct na een vermoedelijke inbreuk). Veel organisaties zetten een infrastructuur voor ondertekening op, maar controleren deze vervolgens nooit meer, waardoor sleutels die jaren oud en mogelijk kwetsbaar zijn, achterblijven. 
• Geen functiescheiding — Scheiding van taken zorgt ervoor dat een gecompromitteerd ontwikkelaarsaccount niet eenzijdig kwaadaardige code kan ondertekenen en publiceren. De ontwikkelaar die de code schrijft, mag bijvoorbeeld niet dezelfde persoon zijn die de code ondertekent en publiceert zonder dat een andere ontwikkelaar deze heeft gecontroleerd. 
• Gebrek aan handhaving van het ondertekeningsbeleid — Zonder afgedwongen beleid wordt ondertekenen ad hoc. Teams kunnen ondertekenen met de verkeerde certificaten, het toevoegen van tijdstempels overslaan of in de verkeerde bouwfase ondertekenen. Gecentraliseerde ondertekeningsplatformen zoals ons CodeSign Secure-platform handhaven beleid programmatisch en stellen gebruikers in staat hun ondertekeningsprocessen en -omgevingen te beheren. 
• Geen correlatie met auditlogboeken — Ondertekeningsgebeurtenissen moeten worden gelogd en die logs moeten worden gekoppeld aan gebeurtenissen in het buildsysteem. Een onverwachte ondertekeningsgebeurtenis buiten een normale buildpipeline is een sterk signaal van een beveiligingslek. 

Nu vraagt ​​u zich misschien af: "Waarom zouden CISO's, DevSecOps-leiders en beveiligingsmanagers zich druk maken over het implementeren van codeondertekening in hun pipelines?" De moderne softwareleveringsketen reikt veel verder dan alleen broncode. Het omvat buildsystemen, CI/CD-pipelines, artifactrepositories, pakketbeheerders, updatekanalen, certificaten en de infrastructuur die wordt gebruikt om software aan klanten en medewerkers te leveren. Juist deze reikwijdte is de reden waarom codeondertekening een belangrijk aandachtspunt is geworden in grote regelgevende en beleidskaders:  

• NIST SSDF (SP 800-218)Het Secure Software Development Framework vereist expliciet dat de integriteit van softwarecomponenten wordt geverifieerd, dat ondertekeningssleutels worden beschermd en dat er processen worden geïmplementeerd om manipulatie in de build-pipeline te detecteren. Dit komt direct overeen met codeondertekening als beveiligingsmaatregel. 
• CISA Secure by DesignDe richtlijnen van CISA sporen softwarefabrikanten aan om verantwoordelijkheid te nemen voor de beveiligingsresultaten, waaronder het waarborgen dat software die aan klanten wordt geleverd, kan worden geverifieerd als authentiek en ongewijzigd. Code ondertekening is een essentieel mechanisme voor deze verifieerbare levering. 
• Uitvoeringsbesluit 14028 (Verbetering van de cyberbeveiliging van het land)De in mei 2021 ondertekende Executive Order 14028 verplichtte federale instanties en hun softwareleveranciers om te voldoen aan specifieke beveiligingsvereisten voor de softwareleveringsketen, waaronder het genereren van SBOM's (Software Supply Chain Memorandum), veilige ontwikkelomgevingen en verificatie van de integriteit van artefacten. Deze order maakte beveiliging van de toeleveringsketen en codeondertekening feitelijk een compliance-vereiste voor elke organisatie die zaken doet met de Amerikaanse federale overheid. 

Wanneer aanvallers de applicatie niet direct kunnen kraken, richten ze zich vaak op het proces dat de applicatie produceert of distribueert. Daarom is codeondertekening een strategische maatregel, geen tactische bijzaak. Het biedt platformen, beveiligingstools en eindgebruikers een manier om te controleren of software afkomstig is van de beoogde uitgever en na de release niet is gewijzigd. In managementtermen helpt codeondertekening het risico op gemanipuleerde software, kwaadaardige updates en een gebrek aan vertrouwen in het releaseproces te verminderen. Het ondersteunt zowel de beveiliging als de operationele betrouwbaarheid. 

Bij het implementeren van codeondertekening in de toeleveringsketen moeten organisaties en teams de onderstaande checklist volgen om hun omgeving veilig te houden: 

• Gebruik EV-certificaten voor alle software die in productie wordt genomen en openbaar wordt verspreid.
• Voorzie elk ondertekend document altijd van een tijdstempel met behulp van een betrouwbare TSA-service.
• Bewaar privésleutels in een HSM. — nooit in bestanden, omgevingsvariabelen of op ontwikkelmachines.
• Integreer het ondertekenen in de CI/CD-pipeline op het juiste moment. (na de test, vóór de release).
• Implementeer op rollen gebaseerde toegang. — niet iedereen heeft tekenbevoegdheid nodig.
• Registreer elke ondertekeningsgebeurtenis en controleer op afwijkingen.
• Houd de vervaldatum van certificaten bij en automatiseer herinneringen voor verlenging. na 90, 60 en 30 dagen.
• Zorg voor een intrekkingsplan. — precies weten hoe je een sleutel moet intrekken en opnieuw ondertekenen als deze is gecompromitteerd.
• Draai de toetsen regelmatig — minimaal jaarlijks, en onmiddellijk na elk vermoedelijk beveiligingslek of elke personeelswijziging.
• Gebruik aparte ondertekeningssleutels per omgeving. — De sleutels voor ontwikkel-, test- en productieomgevingen moeten verschillend zijn, om de impact van een beveiligingslek te beperken.
• Gebruik waar mogelijk kortstondige ondertekeningscertificaten. — met name voor sleutelloze ondertekeningsworkflows die het beheer van langdurige sleutels volledig overbodig maken.

CodeSign Secure van Encryption Consulting 

CodeSign Secure is een gecentraliseerd, veilig en schaalbaar codeondertekeningsplatform dat is ontwikkeld om organisaties te helpen code met vertrouwen te ondertekenen zonder concessies te doen aan beveiliging of snelheid. Het is ontworpen voor moderne DevOps-omgevingen en integreert met populaire CI / CD-pijpleidingen zoals Azure DevOps, Jenkins en GitLab, terwijl strikte toegangscontroles en goedkeuringsworkflows worden afgedwongen om het ondertekeningsproces schoon en conform de regelgeving te houden. 

BELANGRIJKSTE KENMERKEN

• Sleutelbeveiliging met HSM-ondersteuning

  CodeSign Secure maakt gebruik van een FIPS 140-2 Level 3 HSM voor veilige sleutelopslag, waardoor privésleutels altijd beschermd zijn. Het platform integreert met diverse Hardwarebeveiligingsmoduleswaaronder Entrust nCipher, Thales Luna, Utimaco en Securosys, waardoor cryptografische sleutels altijd worden opgeslagen in een fraudebestendig, veilig hardwareapparaat, of u nu de voorkeur geeft aan hardware op locatie of HSM's in de cloud.

• Beleidsgestuurde toegangscontrole

  Het toegangscontrolesysteem van CodeSign Secure integreert met Microsoft Active Directory en Keycloak om gebruikers te registreren en centraal beheer van hun inloggegevens en machtigingen mogelijk te maken. Het platform biedt een gedetailleerd op rollen gebaseerd toegangscontrolesysteem (RBAC) met aanpasbare workflows voor nauwkeurige controle over codeondertekeningsprocessen, waardoor ongeautoriseerde toegang wordt voorkomen en beveiligingsrisico's worden geminimaliseerd.

  Ondertekeningsbeleid wordt programmatisch op platformniveau afgedwongen, wat betekent dat geen enkel artefact kan worden ondertekend tenzij het voldoet aan alle vooraf gedefinieerde criteria: het juiste certificaattype, de juiste ondertekeningsfase en de vereiste goedkeuringen. Scheiding van taken wordt afgedwongen door middel van goedkeuringsworkflows in meerdere stappen: een ontwikkelaar kan een ondertekeningsverzoek indienen, maar releasemanagers of beveiligingsfunctionarissen moeten dit goedkeuren voordat de handtekening wordt geplaatst. Dit elimineert het risico dat een enkel gecompromitteerd account eenzijdig software ondertekent en vrijgeeft zonder toezicht. Bovendien registreren auditsporen en logboeken elke goedkeuring, afwijzing en ondertekening, waardoor beveiligingsteams het bewijsmateriaal hebben dat ze nodig hebben voor compliance-rapportage en incidentonderzoek.

• Naadloze CI/CD-integratie

  Het platform voert beveiligingscontroles en integriteitsvalidatie uit bij releases om te voorkomen dat niet-ondertekende artefacten in productie terechtkomen. Daarnaast biedt het gecentraliseerde tracking met directe waarschuwingen voor ongeautoriseerde ondertekeningspogingen. CodeSign Secure is ontworpen om snelle ontwikkelcycli en continue integratie/continue implementatie (CI/CD)-processen te ondersteunen, waaronder Azure DevOps, Jenkins, GitLab en meer.

• Brede format- en platformondersteuning

  De oplossing ondersteunt het ondertekenen van diverse formaten, waaronder .exe, .dll, .jar, .apk, .dmg, Docker-containers, firmwarebestanden en meer. Hierdoor kunnen alle softwareartefacten veilig worden ondertekend op meerdere besturingssystemen, zoals Windows, Linux en macOS. De oplossing integreert naadloos met onze eigen PKCS11 Wrapper en vele tools van derden voor het ondertekenen van software, zoals Signtool, Jarsigner, JSign en vele andere.

• Hashing en veilige tijdstempeling aan de clientzijde

  Het platform maakt gebruik van client-side hashing, wat betekent dat de code-hash op uw computer wordt gegenereerd met behulp van een aangepaste Key Storage Provider (KSP) die naadloos samenwerkt met Microsofts Cryptography Next Generation (CNG)-framework. Samen met veilige tijdstempels garandeert dit de integriteit en de levensduur van digitale handtekeningen, zelfs na het verlopen van het certificaat.

• Uitgebreide audittrails

  Het platform biedt realtime inzicht in alles code-ondertekening Het biedt activiteiten voor beveiliging en compliance, waaronder het bijhouden van gedetailleerde gebeurtenislogboeken en auditsporen om belangrijk gebruik te volgen, incidenten te onderzoeken en te voldoen aan compliance-vereisten. Daarnaast biedt het plug-inintegratie met diverse SIEM-tools zoals Grafana, Loki en Splunk via OpenTelemetry.

• Flexibele implementatiemodellen

  Organisaties kunnen gebruikmaken van een volledig beheerde, in de cloud gehoste oplossing met ingebouwde HSM-beveiliging die alle functies via API-toegang biedt, of CodeSign Secure on-premises implementeren met behulp van fysieke servers, waarbij privésleutels veilig worden beheerd in cloud-HSM's, on-premises HSM's of beide voor maximale flexibiliteit.

• Ondersteuning voor post-kwantumcryptografie (PQC)

  CodeSign Secure ondersteunt Post-kwantumcryptografie Het systeem maakt gebruik van ML-DSA (Multivariate Lattice Digital Signature Algorithm) en LMS (Leighton-Micali Signatures), twee door NIST erkende, kwantumresistente ondertekeningsschema's, rechtstreeks op de HSM zelf. Door dit proces over te dragen aan een PQC-ondersteunde HSM, worden de benodigde cryptografische sleutels nooit aan het systeem blootgesteld en blijven ze fysiek opgesloten in een beveiligde omgeving.

  Voor organisaties die geleidelijk willen overstappen, ondersteunt CodeSign Secure ook dubbele ondertekeningsschema's, bijvoorbeeld het gebruik van een klassieke RSA- of ECDSA-ondertekening met een ML-DSA- of LMS-ondertekening voor verschillende ondertekeningsvereisten. Met Dual Signing Setup kunnen verschillende softwareprogramma's worden ondertekend door zowel klassieke als kwantumcompatibele verificatiesystemen, afhankelijk van de vereisten, en is een overgang naar een latere fase na de kwantumovergang mogelijk.

Of u nu een groeiend bedrijf bent, een grote onderneming of actief bent in sterk gereguleerde sectoren zoals de auto-industrie, de gezondheidszorg of de fintech-sector, CodeSign Secure is ontworpen om aan uw specifieke behoeften te voldoen. Als u tientallen ondertekeningsaccounts beheert binnen gedistribueerde teams, snelle CI/CD-pipelines uitvoert of werkt onder strikte compliance-eisen, dan is CodeSign Secure ontwikkeld met uw specifieke uitdagingen in gedachten. 

Conclusie 

Codeondertekening lijkt misschien een smalle, technische kwestie, iets wat je eenmalig configureert en vervolgens vergeet. Maar zoals de dreigingsgegevens voor 2025 en 2026 pijnlijk duidelijk maken, is het een van de meest cruciale beveiligingsmaatregelen in je arsenaal. Aanvallen op de supply chain van software meer dan verdubbeld in 2025. Aanvallers staan ​​niet langer voor de deur te wachten; ze zitten ingebed in de pakketten die uw ontwikkelaars elke ochtend downloaden, de CI/CD-taken die uw pipelines automatisch uitvoeren en de build-artefacten die uw teams blindelings vertrouwen. Cybersecurity Ventures voorspelt dat de wereldwijde jaarlijkse kosten van deze aanvallen in 2031 $138 miljard zullen bedragen. De vraag is of uw codeondertekeningsbeleid hierop is voorbereid. 

Of u nu uw eerste PKI opzet, codeondertekening integreert in een complexe multi-cloud CI/CD-omgeving, of probeert te voldoen aan frameworks zoals SLSA of NIST, Encryption Consulting staat voor u klaar, of het nu gaat om advies, migratie of integratie. De softwareleveringsketen is slechts zo sterk als de zwakste schakel. Zorg ervoor dat codeondertekening niet de zwakste schakel in uw keten is.