Codeondertekening – een handleiding voor managers

Codeondertekening voegt een cryptografische digitale handtekening toe aan software, waarmee wordt geverifieerd wie de software heeft gepubliceerd en wordt bevestigd dat deze sindsdien niet is gemanipuleerd. Dit is belangrijk omdat online softwaredistributie, van mobiele apps tot bedrijfsupdates en open-sourcepakketten, geen inherente authenticatie biedt: zonder ondertekening kan een gebruiker legitieme software niet onderscheiden van een gemanipuleerde kopie. De aanbevolen actie: sla ondertekeningssleutels op in een FIPS 140-2 Level 2 of hoger HSM (verplicht sinds juni 2023 volgens CA/Browser Forum), voorzie elke handtekening van een tijdstempel en beheer het ondertekeningsproces centraal in plaats van het aan individuele ontwikkelaars over te laten.

Kort antwoord: Wat is codeondertekening en waarom moeten managers het begrijpen?

Codeondertekening maakt gebruik van cryptografie met publieke sleutels om een ​​software-artefact te koppelen aan de identiteit van de uitgever en om een ​​fraudebestendig zegel te creëren dat elke wijziging na ondertekening detecteert. Het beantwoordt twee vragen die gebruikers en besturingssystemen anders niet kunnen beantwoorden: is deze software afkomstig van de persoon die het beweert te hebben gemaakt, en is deze gewijzigd sinds de release? Managers moeten dit begrijpen, omdat de gevolgen van een fout op dit gebied organisatorisch zijn: een gecompromitteerde ondertekeningssleutel maakt elke release die de organisatie ooit heeft ondertekend ongeldig, het niet intrekken van een gecompromitteerd certificaat betekent dat aanvallers malware kunnen blijven ondertekenen in de naam van de organisatie, en het IBM 2026 Cost of a Data Breach Report toonde aan dat de gemiddelde kosten van een datalek wereldwijd in 2026 $ 4.99 miljoen bedroegen. Codeondertekening is een van de directe technische beveiligingsmaatregelen die het specifieke type datalek voorkomt dat wordt veroorzaakt door gemanipuleerde of nagemaakte software.

Hoe is codeondertekening belangrijk geworden?

Drie samenlopende trends in softwaredistributie creëerden een omgeving waarin codeondertekening essentieel werd.

Ten eerste groeide het aantal bedrijven dat software ontwikkelde en uitbracht enorm, versneld door de smartphone-revolutie en de behoefte van elke organisatie aan eigen applicaties. Ten tweede verving internetdistributie fysieke media (cd's, dvd's) als het belangrijkste distributiemechanisme voor software, waardoor grootschalige, vrijwel onmiddellijke distributie tegen verwaarloosbare kosten mogelijk werd, maar de fysieke traceerbaarheid die gebruikers enig vertrouwen gaf in de authenticiteit van software, verdween. Ten derde groeide het aantal onafhankelijke softwareleveranciers (ISV's) dat softwareapplicaties ontwikkelde gestaag, waarbij sommige onderzoeksrapporten een vertienvoudiging in het afgelopen decennium aangaven.

Het gevolg is dat software nu van uitgever naar gebruiker reist via kanalen waar iedereen de software kan onderscheppen, wijzigen en opnieuw verspreiden. Codeondertekening lost dit probleem op door cryptografisch bewijs te leveren van zowel de identiteit van de uitgever als de integriteit van de software, op het moment van downloaden en installeren, zonder dat gebruikers het distributiekanaal zelf hoeven te vertrouwen.

De dimensie van de toeleveringsketen heeft dit nog urgenter gemaakt: het State of the Software Supply Chain Report 2026 van Sonatype identificeerde meer dan 454,600 nieuwe kwaadaardige open-sourcepakketten in 2025, een stijging van 75% ten opzichte van het jaar ervoor. De betrokkenheid van derden bij datalekken verdubbelde in één jaar tijd van 15% naar 30%, volgens het Verizon Data Breach Investigations Report 2025. Codeondertekening is de controle die downstreamgebruikers in staat stelt te verifiëren dat een pakket daadwerkelijk ongewijzigd afkomstig is van de beweerde uitgever, en dat is precies de vertrouwensrelatie die aanvallers in de toeleveringsketen misbruiken.

Hoe codeondertekening werkt

De code in codeondertekening kan verwijzen naar uitvoerbare bestanden, archieven, stuurprogramma's, firmware, bibliotheken, pakketten en in principe alle software die bedoeld is voor publicatie en distributie. Om te begrijpen hoe codeondertekening werkt, is het handig om een ​​basiskennis te hebben van Public Key Infrastructure (PKI) , de verzameling rollen, beleidsregels, hardware, software en procedures die worden gebruikt voor het creëren, beheren, distribueren, gebruiken, opslaan en intrekken van digitale certificaten.

Codeondertekening heeft twee hoofddoelen: eigendom van de code (bewijzen dat de software afkomstig is van de rechtmatige uitgever) en integriteit van de code (bewijzen dat de code niet is gemanipuleerd). Het vierstappenproces dat beide doelen bereikt, is als volgt:

1. Sleutelgeneratie: Er wordt een privésleutel en een bijbehorend publiek sleutelpaar gegenereerd. De privésleutel moet worden opgeslagen in een HSM (zie het gedeelte over sleutelbeheer hieronder) en mag nooit in bruikbare vorm worden geëxporteerd.
2. Codeondertekeningscertificaat: een codeondertekeningscertificaat aanvragen bij een vertrouwde partij Certificate Authority (CA)Het certificaat bevat de identiteit van de organisatie, de publieke sleutel, de geldigheidsperiode en de digitale handtekening van de certificeringsinstantie (CA). Sinds juni 2023 vereisen publiekelijk vertrouwde codeondertekeningscertificaten dat de privésleutel is opgeslagen in hardware die voldoet aan FIPS 140-2 niveau 2 of hoger.
3. hashen: Het software-artefact wordt door een hashfunctie gehaald die een hashwaarde met een vaste lengte produceert die de inhoud van het artefact vertegenwoordigt. Elke wijziging aan het artefact, zelfs een enkele bit, produceert een volledig andere hashwaarde. SHA-256 is de huidige minimale standaard; SHA-1 en MD5 zijn verouderd en mogen niet worden gebruikt.
4. Ondertekening: De hashwaarde wordt versleuteld met de privésleutel, waardoor een digitale handtekening ontstaat. Deze handtekening, samen met het codeondertekeningscertificaat, wordt meegeleverd met het softwarepakket voor distributie. De originele software zelf wordt niet versleuteld; alleen de kleine hash wordt ondertekend, wat het proces snel en efficiënt maakt.

Gids voor het selecteren van algoritmen en protocollen

Bestanddeel	Aanbevolen	Minimaal acceptabel	Verouderd/vermijden	Notes
Hash-algoritme	SHA-256 of SHA-384	SHA-256	SHA-1, MD5	SHA-1 is door NIST afgekeurd en wordt door de meeste platformen afgewezen; MD5 kent bekende botsingsaanvallen.
Ondertekeningsalgoritme	RSA-3072 of ECDSA P-256	RSA-2048 (verloopt volgens NIST IR 8547 na 2030)	RSA-1024, DSA-1024	ECDSA P-256 biedt een vergelijkbare beveiliging als RSA-3072, maar met kleinere sleutel- en handtekeninggroottes.
Sleutelopslag	FIPS 140-2 Niveau 2 of Niveau 3 HSM	FIPS 140-2 Niveau 2 (verplicht volgens CA/B Forum sinds juni 2023)	Software-sleutelarchieven, privésleutels van bestandssystemen	CA/Browser Forum schrijft hardwareopslag voor voor alle publiekelijk vertrouwde codeondertekeningscertificaten.
Tijdstempel	RFC 3161-tijdstempel van een vertrouwde TSA	RFC 3161 tijdstempel	Geen tijdstempel	Zonder tijdstempel vervalt de geldigheid van de handtekening wanneer het certificaat verloopt.
Post-kwantum (planningshorizon)	ML-DSA (FIPS 204) voor een nieuwe, duurzame infrastructuur voor digitale handtekeningen.	Huidige ECDSA/RSA in afwachting van PQC-overgang	Alleen RSA-2048 voor nieuwe infrastructuur (kwetsbaar voor kwantumaanvallen na 2030)	NIST IR 8547 stelt voor om klassieke asymmetrische algoritmen na 2030 uit te faseren.

Wat gebeurt er als de software wordt gedownload?

Wanneer een gebruiker ondertekende software downloadt, vindt het verificatieproces automatisch plaats in de browser of het besturingssysteem:

1. De browser of het besturingssysteem controleert of het codeondertekeningscertificaat afkomstig is van een vertrouwde certificeringsinstantie (CA-rootcertificaten zijn standaard geïnstalleerd in browsers en besturingssystemen). Als het certificaat niet afkomstig is van een vertrouwde CA, geeft het besturingssysteem een ​​waarschuwing weer en kan de installatie worden geblokkeerd.
2. De publieke sleutel wordt uit het certificaat gehaald en gebruikt om de digitale handtekening te decoderen, waardoor de oorspronkelijke hashwaarde wordt hersteld.
3. De gedownloade software (exclusief certificaat en handtekening) wordt opnieuw gehasht met hetzelfde algoritme.
4. De twee hashwaarden worden vergeleken. Als ze overeenkomen, is de software authentiek en ongewijzigd. Als ze niet overeenkomen (omdat een aanvaller de software na ondertekening heeft aangepast), waarschuwt het besturingssysteem de gebruiker en weigert het de installatie.

Best practices voor codeondertekening

1. Bewaar privésleutels in een HSM: the HSM Export van privésleutels voor cryptografie is niet toegestaan. Volgens de eisen van het CA/Browser Forum van juni 2023 is een FIPS 140-2 Level 2 (of hoger) gecertificeerde HSM nu verplicht voor elk publiek vertrouwd codeondertekeningscertificaat.
2. Beperk de toegang tot privésleutels: Alleen personeel of geautomatiseerde systemen met een specifieke, gedocumenteerde noodzaak mogen een ondertekeningsprocedure starten. Elke ondertekening moet een auditlogboekvermelding genereren met daarin wie of wat de procedure heeft gestart, wanneer deze plaatsvond en welk document is ondertekend.
3. Altijd een tijdstempel toevoegen aan ondertekende code: Een RFC 3161-tijdstempel van een vertrouwde tijdstempelautoriteit (TSA) koppelt de ondertekening aan een specifiek tijdstip. Hierdoor blijft de handtekening verifieerbaar, zelfs nadat het ondertekeningscertificaat is verlopen of ingetrokken, zolang het certificaat geldig was op het moment van ondertekening.
4. Gebruik aparte sleutels per productlijn: Het gebruik van één sleutel voor alle producten betekent dat een inbreuk op die sleutel het vertrouwen in de ondertekening van elk product dat de organisatie ooit heeft uitgebracht, tenietdoet. Aparte sleutels per productlijn, en idealiter per belangrijke release, beperken de impact van een sleutelinbreuk.
5. Centraliseer het beheer van digitale handtekeningen: Ad-hoc ondertekening door individuele ontwikkelaars met behulp van lokaal opgeslagen sleutels biedt geen inzicht, controleerbaarheid of handhaving van beleid. Een gecentraliseerd ondertekeningsplatform zorgt voor consistent beleid voor alle producten en teams en biedt het benodigde controletraject voor naleving en incidentonderzoek.

Codeondertekening voor beveiliging van de softwaretoeleveringsketen

Wanneer een privésleutel wordt gecompromitteerd, verliest het certificaat zijn betrouwbaarheid, waardoor de authenticiteit en integriteit van alle software die met die sleutel is ondertekend, wordt aangetast. Het risico voor de toeleveringsketen dat hiermee gepaard gaat, is aanzienlijk: het State of the Software Supply Chain Report 2026 van Sonatype identificeerde meer dan 454,600 nieuwe kwaadaardige open-sourcepakketten in 2025 (een stijging van 75% ten opzichte van het jaar ervoor), en de betrokkenheid van derden bij datalekken verdubbelde van 15% naar 30% volgens het Verizon DBIR 2025.

Voor de beveiliging van de toeleveringsketen zijn naast de basisondertekening nog twee andere controles essentieel:

1. Controleer de code voordat u ondertekent: Organisaties zouden het ondertekenen moeten integreren in hun processen. CI / CD-pijpleidingen Met goedkeuringspoorten die voorkomen dat kwaadwillende of niet-goedgekeurde code de ondertekeningsstap bereikt. Na ondertekening moeten de artefacten worden geverifieerd aan de hand van de handtekening voordat ze worden gedistribueerd. Alle ondertekeningsgebeurtenissen moeten worden vastgelegd voor latere controle.
2. Trek gecompromitteerde certificaten onmiddellijk in: Als er een vermoeden bestaat dat een privésleutel is gecompromitteerd, moet de uitgevende certificeringsinstantie (CA) het certificaat onmiddellijk intrekken. Intrekking communiceert aan alle partijen die op het certificaat vertrouwen dat het niet langer te vertrouwen is. Vertraagde intrekking betekent dat aanvallers malware kunnen blijven ondertekenen in de naam van de organisatie, terwijl het certificaat geldig blijft.

Codeondertekening in cloud-native en CI/CD-omgevingen

Codeondertekening is cruciaal bij cloud-native implementaties. Containerimages, applicatiebinaries en Kubernetes-implementatiemanifesten vereisen allemaal ondertekening om een ​​betrouwbare artefactketen te creëren van build tot implementatie. In cloud-native omgevingen is ondertekening geïntegreerd met CI/CD-pipelines, zodat elk artefact dat door de pipeline wordt geproduceerd, automatisch wordt ondertekend tijdens de buildfase, in plaats van als een handmatige stap na de build.

Een nieuwer patroon is keyless signing, populair gemaakt door het open-source Sigstore-project. In plaats van dat een manager langlopende certificaten voor elke pipeline aanmaakt en vernieuwt, geeft keyless signing op het moment van ondertekening een kortstondig certificaat uit dat is gekoppeld aan een OIDC-identiteit (OpenID Connect), zoals een CI/CD-workloadidentiteit, waarna de privésleutel volledig wordt verwijderd. De handtekening en een openbaar register worden vastgelegd in een transparantieledger, in plaats van te vertrouwen op een certificaat dat over maanden of jaren moet worden bijgehouden, vernieuwd en ingetrokken.

Traditionele PKI-gebaseerde ondertekening versus sleutelloze (Sigstore-achtige) ondertekening

Aspect	Traditionele PKI-gebaseerde ondertekening	Handtekening zonder sleutel (Sigstore-stijl)
Sleutellevensduur	Ze hebben een lange levensduur (doorgaans 1-3 jaar) en moeten actief beheerd worden.	Tijdelijk; uitgegeven per ondertekeningsmoment en daarna weggegooid.
Sleutelopslag	HSM of hardwaretoken (verplicht sinds juni 2023)	Geen permanente privésleutel om op te slaan
Identiteitsbinding	Organisatie-identiteit geverifieerd door een certificeringsinstantie bij uitgifte.	Werkbelasting/OIDC-identiteit geverifieerd tijdens ondertekening.
herroeping	Handmatige procedure voor intrekking van de CA indien de beveiliging is gecompromitteerd.	Niet van toepassing; een gecompromitteerde tijdelijke sleutel verloopt vrijwel direct.
Best voor	Verzonden desktopsoftware, stuurprogramma's en installatieprogramma's vereisen een langdurige handtekening.	CI/CD-pipelines, containerimages, cloud-native artefacten worden frequent ondertekend.

De meeste bedrijven hanteren beide modellen: traditionele certificaten voor verzonden, langlevende binaire bestanden, en sleutelloze of kortstondige ondertekening voor veelvuldig gebruikte artefacten die door CI/CD-pipelines gaan.

Implementatievoorbeelden

Windows-desktopapplicatie-release: de ontwikkelaar dient een build in bij de ondertekeningspipeline. CodeSign Secure hasht het uitvoerbare bestand, stuurt de hash naar de HSM voor RSA-3072-ondertekening, haalt de ondertekende hash op, voegt een RFC 3161-tijdstempel van de TSA toe en bundelt het certificaat, de handtekening en het tijdstempel met het distributiebestand. Het hele proces vindt plaats binnen de pipeline zonder dat de privésleutel de HSM ooit verlaat. Wanneer gebruikers het installatieprogramma downloaden, controleert Windows SmartScreen de certificaatketen aan de hand van vertrouwde rootcertificaten en bevestigt dat de hash overeenkomt voordat de installatie wordt toegestaan.

Ondertekening van containerimages in een Kubernetes-omgeving: nadat een containerimage is gebouwd en naar de registry is gepusht, roept de CI/CD-pipeline CodeSign Secure aan om de image digest te ondertekenen met de ECDSA P-256-sleutel van de organisatie, die is opgeslagen in de HSM. De ondertekende image digest en het certificaat worden samen met de image in de registry opgeslagen. Kubernetes admission controllers (zoals OPA Gatekeeper of Kyverno) zijn geconfigureerd om de handtekening te verifiëren voordat een container in productie mag worden genomen. Images die niet met de sleutel van de organisatie zijn ondertekend, worden geweigerd.

Open-source pakketrelease met sleutelloze ondertekening (Sigstore): de GitHub Actions-releaseworkflow van de pakketbeheerder activeert de cosign-tool van Sigstore, die een kortstondig certificaat aanvraagt ​​bij de Fulcio CA van Sigstore, gekoppeld aan de GitHub Actions OIDC-identiteit van de releaseworkflow. Het pakket wordt ondertekend met de tijdelijke sleutel, de privésleutel wordt direct verwijderd en de handtekening wordt vastgelegd in het Rekor-transparantielogboek van Sigstore. Gebruikers verderop in het pakket gebruiken cosign verify om de handtekening te controleren aan de hand van het Rekor-logboek, waarmee wordt bevestigd dat het pakket is ondertekend door de legitieme releaseworkflow op de betreffende commit.

Hoe CodeSign Secure managers helpt dit risico te beheersen

Managers hoeven de cryptografie niet zelf uit te voeren, maar ze hebben wel een platform nodig dat de bovenstaande best practices afdwingt zonder dat individuele ontwikkelaars deze hoeven te onthouden. CodeSign Secure van Encryption Consulting doet dit door elk artefact binnen een HSM te ondertekenen, zodat privésleutels de hardware nooit verlaten, door op rollen gebaseerde toegangscontrole toe te passen zodat alleen geautoriseerde gebruikers een ondertekeningsactie kunnen uitvoeren, en door elke ondertekeningsactie te loggen voor het auditspoor dat de bovenstaande best practices vereisen.

CodeSign Secure maakt ook gebruik van client-side hashing, waardoor het te ondertekenen bestand de omgeving van de klant nooit onbeveiligd verlaat. Bovendien wordt elke handtekening voorzien van een tijdstempel om te voorkomen dat softwarehandtekeningen verlopen wanneer het certificaat dat ook doet. Voor teams die zowel binaire bestanden als CI/CD-pipelines beheren, biedt CodeSign Secure één gecentraliseerd platform dat zowel traditionele HSM-ondertekening als integratie met moderne pipeline-ondertekeningsworkflows omvat, in plaats van een afzonderlijk handmatig proces voor elk artefacttype.

Beperkingen van codeondertekening

• Codeondertekening verifieert de integriteit en identiteit, niet de correctheid: Een ondertekend artefact bewijst dat het ongewijzigd afkomstig is van de beweerde uitgever. Het bewijst echter niet dat de code vrij is van kwetsbaarheden, achterdeuren of kwaadaardige logica die aanwezig was vóór de ondertekening. Een ontwikkelaar kan kwaadaardige code die hij zelf heeft geschreven ondertekenen. Codeondertekening en applicatiebeveiligingstesten richten zich op verschillende bedreigingscategorieën.
• Het cruciale compromis is catastrofaal en moeilijk in te dammen: Als een privésleutel voor ondertekening wordt gecompromitteerd, is elk artefact dat ooit met die sleutel is ondertekend verdacht. Intrekking communiceert wantrouwen naar de partijen die erop vertrouwen, maar artefacten die al op gebruikerssystemen zijn geïnstalleerd, blijven ondertekend. Dit verklaart waarom sleutelbeheer, HSM-opslag en toegang met minimale bevoegdheden tot ondertekeningsbewerkingen zo belangrijk zijn.
• De controle op intrekking van contracten vertoont hiaten: Certificaatintrekking werkt alleen als de vertrouwende partijen de intrekkingsstatus daadwerkelijk controleren. OCSP-stapling en CRL-distributie verbeteren de dekking, maar sommige platforms en omgevingen voeren geen betrouwbare controle op intrekking uit. Dit betekent dat een ingetrokken certificaat mogelijk nog steeds wordt geaccepteerd in omgevingen die geen controle op intrekking uitvoeren.
• Sleutelloos ondertekenen is afhankelijk van de infrastructuur voor transparantielogboeken: Sleutelloos ondertekenen met Sigstore verplaatst het vertrouwen naar het Rekor-transparantielogboek en de Fulcio CA. Dit zijn nieuwe infrastructuurcomponenten met hun eigen beschikbaarheids- en vertrouwensvereisten. Organisaties die sleutelloos ondertekenen voor kritieke documenten implementeren, moeten deze afhankelijkheden begrijpen.

Conclusie

Codeondertekening is een essentieel onderdeel van de softwareontwikkelingscyclus, en het landschap eromheen is de afgelopen jaren aanzienlijk veranderd. Opslag op hardware-opslagsystemen (HSM's) is nu verplicht, en niet optioneel, voor publiekelijk vertrouwde certificaten. Het aanvalsoppervlak in de toeleveringsketen is dramatisch toegenomen. En nieuwe ondertekeningsmodellen, waaronder sleutelloze ondertekening en pijplijn-geïntegreerde ondertekening, veranderen de manier waarop organisaties op grote schaal omgaan met de betrouwbaarheid van software-artefacten.

Voor managers zijn de belangrijkste beslissingen van organisatorische aard: wie beheert de ondertekeningssleutels, welke toegangscontroles worden toegepast op ondertekeningsgebeurtenissen, hoe wordt ondertekening gecontroleerd en hoe reageert de organisatie wanneer een sleutel wordt gecompromitteerd? Dit zijn zowel governance- als technische beslissingen en vereisen dezelfde nauwgezetheid als elk ander geprivilegieerd systeem binnen de organisatie. Wilt u uw huidige codeondertekeningsstatus beoordelen of ondertekening integreren in uw CI/CD-pipelines met HSM-ondersteunde sleutelbescherming? Neem dan contact op met Encryption Consulting om te bespreken hoe u kunt beginnen.

Veelgestelde Vragen / FAQ

Wat zijn de twee belangrijkste doelstellingen van codeondertekening?

Code-eigendom, wat bewijst dat de software afkomstig is van de geclaimde uitgever, en code-integriteit, wat bewijst dat de software niet is gewijzigd sinds de ondertekening. Al het andere in een code-ondertekeningsproces dient een van deze twee doelstellingen.

Wat zijn de vier stappen in het codeondertekeningsproces?

Sleutelgeneratie, het verkrijgen van een codeondertekeningscertificaat van een certificeringsinstantie, het hashen van de code en het ondertekenen van die hash met de privésleutel. De ondertekende hash en het certificaat worden vervolgens met het softwarepakket meegestuurd.

Waarom moeten privésleutels voor codeondertekening in een HSM worden opgeslagen?

Een hardwarebeveiligingsmodule voorkomt dat de privésleutel ooit in een bruikbare vorm kan worden geëxporteerd, wat precies is wat een aanvaller nodig heeft om kwaadaardige code overtuigend te ondertekenen. Sinds 1 juni 2023 heeft het CA/Browser Forum hardwarematige sleutelopslag verplicht gesteld voor elk publiekelijk vertrouwd codeondertekeningscertificaat.

Wat gebeurt er als de privésleutel van een codeondertekeningscertificaat wordt gecompromitteerd?

Het certificaat verliest volledig zijn betrouwbaarheid. Alle software die ooit met die sleutel is ondertekend, wordt verdacht. Daarom moet de certificeringsinstantie het gecompromitteerde certificaat onmiddellijk intrekken en raden beveiligingsteams aan om ondertekeningssleutels te rouleren in plaats van één sleutel voor meerdere productlijnen te hergebruiken.

Wat zijn de gemiddelde kosten van een datalek, en waarom is dat belangrijk voor codeondertekening?

De gemiddelde wereldwijde kosten van een datalek bereikten in 2026 $4.99 miljoen, een stijging van 12% ten opzichte van het jaar ervoor, volgens het IBM-rapport '2026 Cost of a Data Breach'. Codeondertekening is een van de directe maatregelen om dit specifieke type datalek, veroorzaakt door gemanipuleerde of nagemaakte software, te voorkomen.

Waarom is codeondertekening met name belangrijk voor de beveiliging van de softwareleveringsketen?

Sonatype identificeerde in 2025 meer dan 454,600 nieuwe kwaadaardige open-sourcepakketten, een stijging van 75% ten opzichte van het jaar ervoor, en de betrokkenheid van derden bij datalekken verdubbelde tot 30% volgens het Verizon 2025 DBIR-rapport. Codeondertekening stelt gebruikers in staat te verifiëren dat een pakket ongewijzigd afkomstig is van de beweerde uitgever, en dat is precies het vertrouwensprobleem in de toeleveringsketen dat aanvallers misbruiken.

Wat is het verschil tussen traditionele PKI-gebaseerde codeondertekening en sleutelloze ondertekening?

Bij traditionele ondertekening wordt een certificaat met een lange geldigheidsduur opgeslagen in een HSM, dat via de CA wordt vernieuwd en ingetrokken. Bij sleutelloze ondertekening wordt een tijdelijk certificaat, gekoppeld aan een workload-identiteit, uitgegeven op het moment van ondertekening en wordt de sleutel direct verwijderd. Hierdoor wordt het beheer van sleutels op lange termijn ingeruild voor uitgifte per gebeurtenis via een transparantielogboek.

Is tijdstempeling van belang als mijn codeondertekeningscertificaat verloopt?

Ja. Zonder tijdstempel vervalt de geldigheid van een handtekening samen met het certificaat. Een RFC 3161-tijdstempel zorgt ervoor dat ondertekende code ook na het vervallen van het oorspronkelijke certificaat nog als authentiek kan worden geverifieerd, zolang het certificaat maar geldig was op het moment van ondertekening.

Hoe past codeondertekening in CI/CD- en cloud-native omgevingen?

Codeondertekening is direct in de pipeline geïntegreerd in plaats van handmatig als laatste stap te worden toegepast. Containerimages en binaire bestanden worden automatisch ondertekend tijdens het bouwproces. Veel cloud-native teams combineren traditionele, door HSM ondersteunde ondertekening voor binaire bestanden met een lange levensduur met sleutelloze of kortstondige ondertekening voor pipeline-artefacten die frequent worden gebruikt.

Hoe helpt CodeSign Secure managers bij het beheersen van risico's met betrekking tot codeondertekening?

Het ondertekent elk artefact binnen een HSM, zodat sleutels de hardware nooit verlaten, dwingt op rollen gebaseerde toegangscontrole af voor wie een ondertekeningsgebeurtenis kan activeren, voorziet elke handtekening van een tijdstempel en registreert elke actie voor controledoeleinden, waardoor de best practices in deze handleiding worden omgezet in afgedwongen platformgedrag.