We hebben alle formaten geteld die CodeSign Secure kan ondertekenen.

Vraag een release engineer hoeveel ondertekeningstools hun organisatie gebruikt en kijk hoe ze daadwerkelijk stoppen en op hun vingers tellen. Signtool voor het Windows-installatieprogramma. Jarsigner voor die ene Java-service waar niemand aan wil komen. Wat het mobiele team ook maar heeft ingesteld voor APK's. Een GPG-sleutel die iemand drie engineers geleden heeft aangemaakt voor de Debian-repository, en niemand weet precies wie die nog heeft. Dat is geen hypothetisch voorbeeld. Dat is de gemiddelde hoeveelheid ondertekeningstools bij elk bedrijf dat al meer dan twee jaar software levert voor meerdere platforms, en het is de reden waarom codeondertekening steeds weer terugkomt in incidentanalyses die niets met de code zelf te maken hebben.

Het punt dat dit nu urgent maakt in plaats van "ooit" is het volgende: het CA/Browser Forum heeft met stemming CSC-31 de maximale geldigheidsduur van publiekelijk vertrouwde codeondertekeningscertificaten teruggebracht van 39 maanden naar 460 dagen, met ingang van 1 maart 2026. Elke verspreide ondertekeningssleutel die een organisatie bezit, elke USB-token die ergens in een la ligt, elk certificaat waarvan niemand zich herinnert dat het is uitgegeven, moet nu ongeveer drie keer zo vaak worden gecontroleerd als achttien maanden geleden. Gefragmenteerde ondertekening was al geen goed idee voordat die stemming werd aangenomen. Het is nu een operationeel risico.

We willen daarom antwoord geven op de vraag die we in bijna elk evaluatiegesprek met CodeSign Secure voor een codeondertekeningsoplossing voor bedrijven krijgen: "Oké, maar dekt het onze stack wel echt?" Hieronder vindt u het eerlijke, specifieke antwoord, formaat per formaat, met voldoende technische details zodat u het kunt controleren aan de hand van uw eigen releasepipeline in plaats van ons op ons woord te geloven.

Definitie van een bedrijfsbrede codeondertekeningsoplossing: een gecentraliseerd platform dat privésleutels genereert en opslaat in hardware met HSM-ondersteuning, rolgebaseerde goedkeuring door meerdere personen afdwingt voor elk ondertekeningsverzoek en geldige handtekeningen produceert voor elk formaat dat een organisatie gebruikt, in plaats van dat elk team met zijn eigen lokale sleutels en tools moet ondertekenen.

Key Takeaways

• CodeSign Secure ondertekent meer dan 20 formaten, waaronder Windows, Apple, Java/Android, Linux, cloud-native, PKCS#11-wrapped en post-quantum, vanaf één FIPS 140-2 Level 3 HSM-ondersteund platform.
• Elk ondertekeningsverzoek is onderworpen aan één RBAC-model en één M-of-N-goedkeuringsworkflow, ongeacht het formaat.
• CA/Browser Forum-stemming CSC-31 verkort de geldigheidsduur van openbare codeondertekeningscertificaten van 39 maanden naar 460 dagen, met ingang van 1 maart 2026, waardoor de frequentie waarmee verspreide ondertekeningssleutels opnieuw moeten worden uitgegeven, verdrievoudigt.
• CodeSign Secure ondersteunt afneembare post-quantum handtekeningen (ML-DSA, LMS) naast klassieke RSA/ECDSA-ondertekening op hetzelfde document, waardoor de implementatie van PQC een aanvulling is en geen complete vervanging.
• Implementatiemogelijkheden omvatten on-premises, cloud- en hybride HSM-modellen; raadpleeg de secties 'Vereisten' en 'Bekende beperkingen' verderop voordat u een evaluatie uitvoert.

De korte versie

CodeSign Secure ondertekent meer dan 20 verschillende formaten vanaf één HSM-ondersteund platform: Windows-binaire bestanden en scripts (Signtool, JSign, PowerShell, Appx/MSIX, ClickOnce via Mage, NuGet, HLK/HCK-stuurprogrammaondertekening), Apple-binaire bestanden, Java- en Android-artefacten (jarsigner, JSign, APK), Linux- en open-sourcepakketten (OpenSSL, XML, GPG2, Debian, RPM), cloud-native artefacten (containers, OVA/OVF, firmware), reproduceerbare builds, PKCS#11-verpakte HSM-ondertekening en afneembare post-quantum-ondertekeningen (ML-DSA, LMS). Eén op rollen gebaseerd toegangsbeheermodel (RBAC) en één M-van-N-goedkeuringsworkflow beheren dit alles. Dat laatste is het eigenlijke punt, niet het aantal formaten. Een platform dat twintig formaten ondertekent via twintig verschillende vertrouwensgrenzen heeft het fragmentatieprobleem niet opgelost; het heeft het alleen een langere functielijst gegeven.

Wil je eerst de volledige kaart zien voordat je de details bekijkt? Hier is hij.

Categorie	Ondersteunde formaten/tools	Bestandsextensies
Windows	Signtool (Authenticode), JSign, PowerShell-scripts, Appx/MSIX-pakketten, ClickOnce-manifesten (Mage/Mage UI), NuGet-pakketten, HLK/HCK-gecertificeerde stuurprogramma's	.exe, .dll, .sys, .msi, .cab, .ps1, .appx/.msix, .application, .nupkg
Appel	macOS-, iOS- en watchOS-applicaties	.app, .ipa
Java en Android	JAR-bestanden (jarsigner), platformonafhankelijke Authenticode via JSign, APK-pakketten	.jar, .apk
Linux en open source	OpenSSL-gebaseerde ondertekening, XML-digitale handtekeningen, GPG2, Debian-pakketten, RPM-pakketten	.rpm, .deb, .xml, .asc/.sig
Cloud-native en infrastructuur	Container-/OCI-images, OVA-/OVF-virtualisatiebestanden, firmware-images	N/A (inhoudsoverzicht), .ova/.ovf, firmware-binaries
Integriteit van de toeleveringsketen	Reproduceerbare builds	Niet van toepassing (build attestation, geen enkel bestandstype)
Post-kwantum	PQC afneembare handtekeningen (ML-DSA, LMS)	.sig (losgekoppeld)
Hardware-interoperabiliteit	PKCS#11 wrapper-ondertekening voor tools van derden en oudere tools	Niet van toepassing (op protocolniveau, niet bestandsspecifiek)

Laten we nu eens bekijken wat er precies achter elke regel schuilgaat, want "wij steunen X" betekent niets zonder de uitleg waarom het belangrijk is.

Windows: Waar de meeste ondertekeningsprogramma's ontstaan ​​en waar de meeste vastlopen

Als uw organisatie iets ondertekent, is dat vrijwel zeker begonnen met Windows, en meestal begint daar ook de wildgroei. Microsofts signtool.exe is de referentietool voor Authenticode-ondertekening, het schema dat Windows gebruikt om PE-bestanden te vertrouwen: .exe, .dll, .sys, .msi, .cab en catalogusbestanden. Het probleem is dat Signtool alleen op Windows draait, en zodra uw buildpipeline een Linux-container of een gemengde CI/CD-omgeving bevat, is dat geen klein ongemak meer, maar de reden waarom iemand een Windows VM in leven houdt om documenten te ondertekenen. JSign, een open-source, platformonafhankelijke Authenticode-tool geschreven in Java, is specifiek ontwikkeld om dit probleem op te lossen, en CodeSign Secure gebruikt het als een van zijn ondertekeningsengines, zodat Linux- en macOS-buildagents geldige Authenticode-handtekeningen kunnen genereren zonder ooit een VM op te starten. De privésleutel blijft gedurende het hele proces in een FIPS 140-2 Level 3 HSM, ongeacht of het verzoek via Signtool of via JSign binnenkomt.

PowerShell-scripts krijgen dezelfde behandeling. Als uw uitvoeringsbeleid een geldige Authenticode-handtekening vereist voor elk .ps1-bestand (en dat zou het moeten), ondertekent CodeSign Secure die scripts via de HSM en blijven ze verifieerbaar met een eenvoudige Get-AuthenticodeSignature-aanroep, zonder dat er ooit een ondertekeningssleutel op de machine terechtkomt waarop het script wordt uitgevoerd.

Dan is er nog de verpakkingslaag, waar de meeste Windows-ondertekeningsconfiguraties stilletjes opsplitsen in drie of vier afzonderlijke workflows: Appx- en MSIX-pakketten, die Windows niet installeert zonder een certificaatketen naar een vertrouwde root, ongeacht of je via de Store distribueert of sideloadt; ClickOnce, het zelf-updatende implementatiemodel voor .NET waarvan het vertrouwen gebaseerd is op ondertekende manifesten die gegenereerd zijn met Microsofts Mage- en Mage UI-tools (en waarvan de ondertekeningssleutels de vervelende gewoonte hebben om in de lokale certificaatopslag van een ontwikkelaar terecht te komen in plaats van ergens waar een beveiligingsteam ze kan inzien); en NuGet-pakketten, die Authenticode-ondertekening ondersteunen sinds NuGet 4.6 en eigenlijk een vertrouwde tijdstempel zouden moeten bevatten, zodat de handtekening langer meegaat dan het certificaat. CodeSign Secure behandelt alle drie op dezelfde manier als het binaire bestand zelf: één HSM, één auditspoor, geen uitzonderingen voor "het is maar een manifest".

En dan is er nog het formaat dat hardwareleveranciers stiekem angst inboezemt: HLK/HCK-stuurprogrammaondertekening. Om een ​​stuurprogramma te certificeren via de Windows Hardware Lab Kit (de opvolger van de oudere Hardware Certification Kit) moeten ondertekende pakketten worden ingediend bij Microsofts Windows Hardware Development Center. Kernel-modusstuurprogramma's op 64-bits Windows worden simpelweg niet geladen zonder een handtekening van een certificaat dat voldoet aan Microsofts huidige EV- of hardware-ondersteunde sleutelvereisten. Een afgewezen HLK-inzending vanwege een technische fout in de ondertekening kost een hardwareteam kostbare tijd. CodeSign Secure ondersteunt ondertekening op basis van deze vereisten, wat het verschil maakt tussen een inzending die de beoordeling doorstaat en een die wordt teruggestuurd met een bericht dat niemand wil lezen.

Apple: één ecosysteem, één strenger reglement.

Apple hanteert op dit vlak strengere regels dan Windows. Codesign en Gatekeeper verwachten dat elk macOS-, iOS- en watchOS-bestand een handtekening van een Apple Developer-certificaat bevat. macOS voegt daar nog een tweede controle aan toe via notarisatie voordat Gatekeeper een gebruiker toestaat de app te openen zonder een waarschuwingsvenster. De meest voorkomende oorzaak van problemen is niet een ontbrekende handtekening, maar een Apple Developer ID die in de sleutelbos van een individuele ontwikkelaar staat in plaats van op een plek waar een team deze kan beheren of intrekken. CodeSign Secure ondertekent macOS-, iOS- en watchOS-apps via de standaard Apple-procedure, terwijl de certificaten in dezelfde HSM-beveiligde kluis worden bewaard als alle andere platformsleutels. Hierdoor is "de persoon die eigenaar is van het Apple-ondertekeningscertificaat" niet langer een single point of failure die aan één laptop is gekoppeld.

Java en Android: De stack waarvan iedereen ervan uitgaat dat iemand anders hem ondertekent

Elk bedrijf heeft minstens één interne Java-service die al sinds de tijd van een JVM, waarvan het huidige team zich nauwelijks meer herinnert, stilletjes draait. Jarsigner, meegeleverd met de JDK, ondertekent de JAR-bestanden waar deze services van afhankelijk zijn, zodat een JVM (of een gebruiker) kan bevestigen dat het archief niet is gemanipuleerd en, indien het manifest dit vereist, wie het daadwerkelijk heeft gepubliceerd. CodeSign Secure ondertekent JAR-bestanden via de normale gecentraliseerde workflow, wat vooral belangrijk is omdat JAR-ondertekeningssleutels precies het soort referenties zijn dat eenmalig wordt ingesteld, vervolgens vergeten en nooit wordt geroteerd. JSign duikt hier ook weer op, waardoor CI/CD -runners op Linux en macOS Windows-signatures kunnen aanvragen zonder een speciale Windows-ondertekeningshost voor die ene pipelinefase.

Android is een verhaal apart. Elke APK moet worden ondertekend vóór installatie, en het schema is vier keer geëvolueerd: v1 (rechtstreeks overgenomen van Java's JAR-ondertekening), v2 en v3 (schema's voor ondertekening van het hele bestand die Android introduceerde in versie 7.0 en 9, specifiek om de hiaten in v1 te dichten, waarbij de handtekening wordt gekoppeld aan de exacte inhoud van de APK in plaats van alleen aan het manifest), en v4 (een streaming-schema dat samen met v2/v3 wordt gebruikt voor incrementele app-updates). CodeSign Secure ondertekent al deze schema's via APKSigner, via de PKCS#11 -wrapper op Linux-, Windows- en macOS-buildagents, zodat een mobiele release voldoet aan de huidige Google Play-vereisten zonder een aparte, onbeheerde tool voor mobiele ondertekening die losstaat van de rest.

Linux en open source: het ecosysteem met de meeste ondertekeningsconventies, maar niet met de minste.

Als iemand je vertelt dat Linux-ondertekening "gewoon GPG" is, dan heeft diegene geen kennis van RPM, Debian en ondertekening op repositoryniveau als drie wezenlijk verschillende conventies. Op RPM gebaseerde distributies ondertekenen met rpm –addsign (of rpmsign), waarbij een GPG-sleutel direct in de pakketheader wordt ingesloten. Op Debian gebaseerde pakketten worden ondertekend met tools zoals dpkg-sig of tijdens de build via debsign. En de metadata van APT-repositories, het Release-bestand zelf, wordt apart ondertekend, zodat een pakketbeheerder een volledige repository kan vertrouwen in plaats van pakketten één voor één te verifiëren. Drie conventies betekenen meestal drie GPG-sleutelringen verspreid over de buildinfrastructuur, elk met een eigen idee over wie bevoegd is om ze te gebruiken. CodeSign Secure centraliseert ze alle drie onder één sleutelbeheerlaag.

Twee andere Linux-gerelateerde formaten maken dit compleet. OpenSSL-ondertekening dekt de gevallen die verpakkingstools niet dekken: ruwe hashes, aangepaste datastructuren, willekeurige bestanden die een losgekoppelde handtekening vereisen en niet in een standaard pakketformaat passen. CodeSign Secure ondersteunt OpenSSL-gebaseerde ondertekening (dgst-sign en CMS-workflows), zodat deze artefacten niet terugvallen op "wie er toevallig een lokaal sleutelbestand bij de hand heeft". En XML-digitale handtekeningen, het door W3C gestandaardiseerde XML-DSig-formaat dat ten grondslag ligt aan SAML-assertions, SOAP-berichten en een aanzienlijk deel van de gereguleerde documentuitwisseling, worden volgens dezelfde specificatie ondertekend wanneer een compliance- of B2B-integratievereiste dit specifiek vereist.

Cloud-native en infrastructuur: waar ondertekeningsstrategieën het jongst zijn en het meest waarschijnlijk worden overgeslagen.

Dit is de categorie waarvoor de meeste traditionele digitale handtekeningtools nooit ontworpen zijn, en dat is te merken.

Containerimagesignering voegt een cryptografische handtekening toe aan een image, zodat iedereen die de image downloadt kan controleren wie deze heeft gepubliceerd en kan bevestigen dat deze niet is gewijzigd. Het ecosysteem is grotendeels geconvergeerd naar twee benaderingen: Sigstore's Cosign, dat zelfbeheerde sleutels ondersteunt (inclusief HSM-ondersteunde sleutels) of sleutelloze ondertekening via kortstondige certificaten en een openbaar transparantielogboek, en Notation, gebouwd op de CNCF Notary v2-specificatie, die gebruikmaakt van op PKI gebaseerde vertrouwensbeleidsregels en die door Microsoft AKS en Amazon EKS wordt aanbevolen voor enterprise Kubernetes. Beide methoden koppelen de handtekening aan de content digest van de image in plaats van aan een wijzigbare tag, wat de reden is dat manipulatie überhaupt detecteerbaar is. CodeSign Secure ondertekent volgens deze huidige standaarden, niet volgens het Docker Content Trust-model dat Docker zelf al heeft afgekeurd voor officiële images.

Het ondertekenen van OVA- en OVF- bestanden heeft dezelfde functie voor virtuele machine-appliances, de standaard verpakkingsformaten van VMware en de bredere open virtualisatiespecificatie van de Distributed Management Task Force. Hierdoor kan een team de integriteit van een VM-appliance controleren voordat deze in productie wordt genomen.

Het ondertekenen van firmware is belangrijker dan al het andere, omdat firmware zich onder het besturingssysteem bevindt. Een gecompromitteerde firmware-image overleeft een herinstallatie van het besturingssysteem en omzeilt de meeste endpoint-beveiligingstools. Ondertekende firmware, gecontroleerd aan de hand van een beveiligde opstartketen, is de controle die voorkomt dat een gemodificeerde image überhaupt wordt geladen. Het is precies het soort duurzame sleutel met een grote impactradius dat nooit in een buildscript of een lokale tool van een leverancier thuishoort. CodeSign Secure ondertekent firmware via dezelfde HSM als alle andere producten in deze lijst, zonder uitzonderingen.

Reproduceerbare builds: bewijzen dat het binaire bestand daadwerkelijk overeenkomt met de broncode

Een reproduceerbare build betekent dat het compileren van dezelfde broncode met dezelfde instructies exact hetzelfde binaire bestand oplevert, bit voor bit, ongeacht wie het bouwt of wanneer. Deze eigenschap stelt iemand buiten uw organisatie in staat om onafhankelijk een release te bouwen en te bevestigen dat wat u hebt uitgebracht daadwerkelijk overeenkomt met wat u hebt gepubliceerd. Dit is momenteel een van de sterkste verdedigingsmechanismen tegen een gecompromitteerde build-pipeline. CodeSign Secure ondersteunt ondertekeningsworkflows die zijn gebouwd rond reproduceerbare build-praktijken, zodat de handtekening op een release-artefact is gekoppeld aan een buildproces dat kan worden gecontroleerd, en niet alleen kan worden vertrouwd omdat de leverancier dat zegt. Zie 'Versterking van de beveiliging van de toeleveringsketen met SLSA Level 3 en codeondertekening' voor meer informatie over hoe dit verband houdt met bredere attestatie van de toeleveringsketen.

Een nieuwe aanwinst na Quantum: de aanwinst waar de meeste teams nog niet aan denken.

Hier is een ongemakkelijke waarheid: elke RSA- en ECDSA-handtekening die vandaag de dag wordt gebruikt voor codeondertekening, is precies het soort handtekening dat een voldoende krachtige kwantumcomputer zou kraken. NIST heeft dit niet bij de theorie gelaten. FIPS 204 (ML-DSA, de Module-Lattice-Based Digital Signature Standard) en FIPS 205 (SLH-DSA, de Stateless Hash-Based Digital Signature Standard) werden in augustus 2024 afgerond, samen met de stateful hash-gebaseerde LMS- en XMSS-schema's die zijn gespecificeerd in NIST SP 800-208. CodeSign Secure ondersteunt PQC-ondertekening met ML-DSA en LMS, wat betekent dat een post-kwantumhandtekening naast, of in plaats van, een klassieke RSA/ECDSA-handtekening op hetzelfde artefact kan staan. Niemand hoeft zijn bestaande ondertekeningsschema te verwijderen om hiermee te beginnen. Dat is de hele waarde van "afkoppelbaar": crypto-flexibiliteit die je vandaag al in een pipeline kunt inbouwen in plaats van later in een crisissituatie. Dit sluit ook aan op een grotere vraag die de meeste teams nog niet hebben beantwoord: welke ondertekeningsalgoritmes worden er nu eigenlijk in hun omgeving gebruikt? Dat is meer een gesprek over CBOM Secure dan over codeondertekening, maar beide beginnen bij dezelfde inventaris.

PKCS#11: Ervoor zorgen dat verouderde tools geen excuus worden

Een groot deel van de bestaande tools voor digitale handtekeningen, met name de oudere versies, is rechtstreeks geschreven voor PKCS#11, de standaard cryptografische API die de meeste HSM's en smart tokens gebruiken. In plaats van het probleem van elke ontwikkelaar op te leggen om al die tools te vervangen, presenteert CodeSign Secure zichzelf als een PKCS#11-provider. Hierdoor blijven bestaande scripts en tools van derden die directe toegang tot de hardware verwachten, gewoon werken zoals ze bedoeld zijn. Het verschil zit hem in wat er achter die interface gebeurt: elke digitale handtekening wordt nog steeds via de gecentraliseerde beleids-, logboek- en goedkeuringslaag van CodeSign Secure geleid, in plaats van rechtstreeks met de hardware te communiceren zonder toezicht.

In de praktijk is de PKCS#11-wrapper de basis waarop de eigen ondertekeningsengines van CodeSign Secure draaien, en deze werkt op alle belangrijke buildplatformen:

• APK-ondertekening — Linux, Windows en macOS
• Ondertekening op basis van OpenSSL — Linux en Windows
• XML-digitale handtekeningen — Linux en macOS
• Ondertekening via JSign — Linux, Windows en macOS
• Ondertekening van JAR-bestanden met Jarsigner — Linux, Windows en macOS
• GPG2-, Debian- en RPM-pakketondertekening — Linux

Hoe CodeSign Secure is ontworpen

Als je de bovenstaande details per formaat weglaat, is de architectuur voor elk formaat hetzelfde: een hardwarematige vertrouwensbasis, een reeks ondertekeningsengines die de eigen tools van elk formaat ondersteunen, en een beleidslaag die elke aanvraag moet doorlopen voordat een sleutelbewerking kan plaatsvinden.

• Hardware root of trust: Privésleutels worden gegenereerd en bewaard in een FIPS 140-2 Level 3 HSM, die on-premises, in de cloud of als een combinatie van beide is geïmplementeerd. Het sleutelmateriaal zelf verlaat dus nooit de gevalideerde hardware, ongeacht het formaat.
• Formaatspecifieke ondertekeningsengines: Signtool en JSign voor Authenticode, jarsigner en APKSigner voor Java/Android, codesign voor Apple, en Cosign/Notation-aligned signing voor containers, die elk de HSM aanroepen in plaats van een lokale sleutelkopie te bewaren.
• PKCS#11 interoperabiliteitslaag: Een PKCS#11-providerinterface zorgt ervoor dat bestaande scripts en tools van derden die directe toegang tot de hardware verwachten, ongewijzigd kunnen blijven werken, terwijl elke aanroep nog steeds via de onderliggende beleidslaag verloopt.
• Gecentraliseerde beleids- en goedkeuringslaag: RBAC en M-of-N-workflows voor meerdere goedkeurders staan ​​vóór elke ondertekeningsengine, zodat één gecompromitteerde build-referentie op zichzelf geen vertrouwde handtekening kan genereren.
• Integratiepunten: CI/CD-pipeline-plugins, een API/CLI en de bovenstaande PKCS#11-interface dekken de manieren waarop buildsystemen doorgaans een handtekening aanvragen; controleer de exacte ondersteunde CI/CD-platforms en besturingssysteemversies voor uw omgeving aan de hand van de actuele implementatiedocumentatie van CodeSign Secure voordat u een architectuur definitief vastlegt.

Beveiligingsmaatregelen achter elke handtekening

De lijst met formaten is minder belangrijk dan wat eronder gebeurt. Elke ondertekeningsgebeurtenis, ongeacht welk van de meer dan 20 bovenstaande formaten deze activeert, doorloopt dezelfde reeks controles:

• Sleutelbewaring: Privésleutels worden gegenereerd en blijven binnen een FIPS 140-2 Level 3 HSM; geen enkele ondertekeningsengine krijgt een lokale kopie van de sleutel.
• Rolgebaseerde toegangscontrole: Wie een handtekening kan aanvragen, in welk formaat en onder welk certificaat, wordt per rol bepaald en niet per individuele kwalificatie.
• M-of-N-goedkeuring: Bij risicovollere ondertekeningshandelingen (zoals het indienen van een nieuwe HLK-driver, een firmware-image of een productiecontainer) kan goedkeuring van een vastgesteld quorum van goedkeurders vereist zijn in plaats van de goedkeuring van één enkele ontwikkelaar.
• Gecentraliseerd, onveranderlijk auditspoor: Elke ondertekeningsgebeurtenis, ongeacht het formaat, komt in één logboek terecht. Dit is een controlemechanisme dat bij de meeste gefragmenteerde ondertekeningssystemen volledig ontbreekt, in tegenstelling tot één logboek per tool (of helemaal geen logboek).

Wat u nodig hebt voordat u een bedrijfsbrede codeondertekeningsoplossing implementeert

Geen van bovenstaande oplossingen werkt zonder eerst een aantal zaken op orde te hebben. Voordat u een gecentraliseerd platform voor digitale handtekeningen evalueert of implementeert, moet u ervoor zorgen dat u het volgende hebt:

• Een HSM die voldoet aan FIPS 140-2 niveau 3 (on-premises, in de cloud of via HSM-as-a-Service als u er nog geen gebruikt).
• Ontwikkel agents of CI/CD-runners voor elk platform waarvoor u ondertekent (Windows, Linux, macOS) die toegang hebben tot de API, CI/CD-plug-in of PKCS#11-interface van het ondertekeningsplatform.
• Certificaten uitgegeven door een certificeringsinstantie (CA) die geschikt is voor elk gebruiksscenario: een publiekelijk vertrouwde CA voor Authenticode- en Apple Developer-ondertekening, en, waar het beleid dit toestaat, een interne CA voor interne Java-, XML- of pakketrepository-ondertekening.
• Een identiteitsbron (bestaande directory of IdP) om benoemde goedkeurders te koppelen aan de RBAC- en M-of-N-goedkeuringsworkflow.
• Voor het ondertekenen van containers is specifiek een register nodig dat OCI-handtekeningkoppeling ondersteunt, zodat Cosign- of Notation-stijl handtekeningen aan de image digest kunnen worden gekoppeld.

De exact ondersteunde besturingssysteemversies, CI/CD-platformen en netwerkvereisten variëren per implementatiemodel; controleer de actuele lijst aan de hand van de implementatiedocumentatie van CodeSign Secure of met uw evaluatiecontactpersoon in plaats van alleen op basis van dit bericht aannames te doen.

Bekende beperkingen

Een eerlijke lijst van dekkingsgebieden omvat niet alleen wat het wél doet, maar ook wat centralisatie van contracten níét doet:

• Het centraliseren van de sleutel neemt de noodzaak voor platformspecifieke tools voor het voorbereiden van het artefact niet weg. De toolchain van Xcode voor het indienen van Apple-notarisatie, de verpakkingstools van de Windows Hardware Lab Kit voor drivercertificering en vergelijkbare tools draaien nog steeds op de buildagent; CodeSign Secure verzorgt de vertrouwde sleutelbewerking, niet de verpakkingsstap.
• Een on-premises implementatie vereist nog steeds dat de organisatie een HSM levert of aansluit die voldoet aan FIPS 140-2 Level 3 (of deze afneemt als HSM-as-a-Service); CodeSign Secure is een ondertekenings- en beleidslaag, geen vervanging voor de HSM zelf.
• De PKCS#11-wrapper is hierboven gedocumenteerd voor zes specifieke workflows (APK, OpenSSL, XML, JSign, jarsigner en GPG2/Debian/RPM-ondertekening); voor een oudere tool die niet in deze lijst staat, dient u eerst rechtstreeks contact op te nemen met het team van CodeSign Secure voordat u ervan uitgaat dat deze wordt ondersteund.
• Met de afneembare PQC-ondertekening wordt naast de klassieke handtekening een tweede handtekening toegevoegd; de RSA/ECDSA-handtekening die uw bestaande clients nog steeds gebruiken voor verificatie, wordt hiermee niet verwijderd of vervangen. Beschouw het daarom als een extra cryptografische flexibiliteit, niet als een volledige migratie.

Dit is het gedeelte dat we je daadwerkelijk zouden vertellen tijdens een telefoongesprek.

Het aantal formaten dat een ondertekeningsplatform ondersteunt, is niet het interessante cijfer. We zeggen dit in bijna elk evaluatiegesprek, en het verbaast mensen die minder ervaring hebben met dit vakgebied meer dan je zou denken. Het interessante cijfer is hoeveel ondertekeningssleutels van een organisatie zich momenteel buiten één centraal, door HSM ondersteund controlepaneel bevinden, elk met een eigen toegangslijst, een eigen auditlogboek (of het volledig ontbreken daarvan) en een eigen vernieuwingskalender die door niemand centraal wordt bijgehouden.

Dat aantal is nu een stuk duurder om te negeren. Met de nieuwe maximale geldigheidsduur van 460 dagen moet elk van die verspreide sleutels ongeveer drie keer zo vaak opnieuw worden uitgegeven en geïmplementeerd als vóór maart 2026. Een handmatige, per tool te gebruiken ondertekeningsworkflow die achttien maanden geleden slechts irritant was, kost nu elk kwartaal aanzienlijke ontwikkeltijd. Dit is vooral problematisch voor iedereen die nog steeds fysieke USB-tokens verstuurt voor ondertekening in plaats van ze via een netwerk- of cloud-HSM te routeren.

De oplossing is dus niet om de tool te kiezen met de langste functielijst op de website. Het gaat erom dat elk ondertekeningsformaat dat een organisatie daadwerkelijk gebruikt, achter één HSM, één RBAC-model en één M-van-N-goedkeuringsworkflow zit. Op die manier kan een gecompromitteerde buildserver of een via phishing verkregen ontwikkelaarsaccount geen vertrouwde handtekening genereren, ongeacht welk van de meer dan twintig bovengenoemde formaten wordt geprobeerd.

Evaluatiechecklist voor een bedrijfsbrede codeondertekeningsoplossing

Gebruik de volgende vragen in de aangegeven volgorde bij het vergelijken van een gecentraliseerd platform voor digitale handtekeningen met uw eigen lijst van formaten en tools:

1. Wordt elk formaat dat u daadwerkelijk verzendt via één HSM-ondersteunde vertrouwensbasis geleid, of verbergt het aantal formaten een aparte sleutelopslag per tool?
2. Worden RBAC en M-of-N-goedkeuring op alle formaten toegepast, of alleen op de paar formaten die als eerste door de IT-afdeling zijn ingesteld?
3. Kun je op aanvraag een auditlogboek opvragen voor één specifieke ondertekeningsgebeurtenis, ongeacht het formaat, zonder de logboeken van een tweede of derde tool te hoeven raadplegen?
4. Ondersteunt het platform momenteel afneembare post-quantum-ondertekening, of staat dat nog op de planning?
5. Sluit het implementatiemodel (on-premises, cloud of hybride) aan op uw HSM-eigendoms- en data-residentievereisten?
6. Voor elke tool waarop uw teams vertrouwen en die directe PKCS#11-hardwaretoegang vereist, publiceert de leverancier dan precies welke workflows momenteel worden ondersteund, in plaats van een algemene bewering als "PKCS#11-compatibel"?

Onafhankelijke validatie

Neem de lijst met formaten op deze pagina niet als enige bewijs. Controleer deze ook met bronnen buiten Encryption Consulting:

• ABI Research heeft CodeSign Secure in zijn onafhankelijke marktbeoordeling uitgeroepen tot een van de marktleiders op het gebied van codeondertekening; zie ABI Research benoemt CodeSign Secure tot een van de marktleiders op het gebied van codeondertekening..
• De wijziging in de geldigheid van certificaten die de urgentie van dit bericht verklaart, is rechtstreeks gedocumenteerd door de normeringsinstantie: CA/Browser Forum Stembiljet CSC-31: Maximale geldigheidsbeperking.
• De hierboven genoemde post-kwantumsignatuurstandaarden, FIPS 204 (ML-DSA) en FIPS 205 (SLH-DSA), worden rechtstreeks door NIST gepubliceerd en zijn niet via een omweg samengevat.
• De eigen beveiligingsstandaarden van Encryption Consulting (ISO/IEC 27001:2022, SOC 2, PCI DSS) zijn gedocumenteerd op de website. Vertrouwenscentrum, onafhankelijk van de beweringen van een enkel product.

Als je het tot hier hebt gehaald...

Meer dan twintig formaten is geen ijdelheidsmaatstaf; het is gewoon een eerlijke weerspiegeling van de vele verschillende manieren waarop een moderne softwareorganisatie daadwerkelijk producten levert: code, scripts, pakketten, containers, firmware en nu ook post-quantum handtekeningen, vaak vanuit dezelfde releasepipeline. De teams die hierdoor de dupe worden, zijn niet de teams die geen ondertekeningstool hebben. Het zijn de teams die er zes gebruiken, elk met een sleutel ergens waar niemand kijkt, terwijl de levensduur van certificaten juist drie keer zo kort is geworden.

Als uw eigen digitale handtekeningen al meer dan twee of drie van de bovenstaande formaten omvatten, is dat meestal het punt waarop consolidatie naar één door HSM ondersteund platform geen project voor de toekomst meer is, maar de factor die een routineuze release kan voorkomen of een zeer slechte week kan betekenen.

Ontdek hoe CodeSign Secure al deze workflows centraliseert: verken het CodeSign Secure-platform.

Veelgestelde Vragen / FAQ

Vereist CodeSign Secure een andere HSM voor elk ondertekeningsformaat?

Nee. Elk formaat dat CodeSign Secure ondersteunt, van Authenticode tot containerimages en PQC-afneembare handtekeningen, draait via dezelfde gecentraliseerde HSM-infrastructuur, die on-premises, in de cloud of als hybride oplossing kan worden geïmplementeerd. Hierdoor beheert een organisatie één hardwarematige vertrouwensbasis in plaats van één per tool.

Kan CodeSign Secure zowel klassieke (RSA/ECDSA) als post-kwantum handtekeningen op hetzelfde object plaatsen?

Ja. CodeSign Secure ondersteunt afneembare PQC-handtekeningen met behulp van ML-DSA en LMS naast klassieke ondertekening, zodat een post-quantum handtekening aan een release kan worden toegevoegd zonder de klassieke handtekening te verwijderen waar clients nog steeds van afhankelijk zijn voor verificatie.

Waarom is er voor het ondertekenen van HLK/HCK-stuurprogramma's een aparte workflow nodig in plaats van de standaard Authenticode-ondertekening?

Voor inzendingen voor de Windows Hardware Lab Kit gelden eigen certificerings- en indieningsvereisten, gekoppeld aan het Windows Hardware Dev Center van Microsoft. Kernelmodusstuurprogramma's op 64-bits Windows worden niet geladen zonder een handtekening die aan deze specifieke vereisten voldoet. Daarom moet de ondertekeningsprocedure overeenkomen met het certificeringsproces voor stuurprogramma's van Microsoft, in plaats van met de algemene Authenticode-regels.

Wordt Docker Content Trust nog steeds ondersteund als methode om containers te ondertekenen?

Docker heeft Content Trust voor officiële images afgeschaft en de huidige praktijk is overgestapt op Sigstore Cosign of Notation (Notary v2), die beide handtekeningen koppelen aan de inhoudssamenvatting van een image. CodeSign Secure ondertekent volgens deze huidige standaarden in plaats van het afgeschafte model.

Wat is er veranderd aan de geldigheidsduur van codeondertekeningscertificaten in 2026?

Volgens CA/Browser Forum Ballot CSC-31 is de maximale geldigheidsduur van publiekelijk vertrouwde codeondertekeningscertificaten verlaagd van 39 maanden naar 460 dagen, met ingang van 1 maart 2026. Dit verhoogt de frequentie waarmee certificaten opnieuw moeten worden uitgegeven aanzienlijk, met name voor organisaties die nog steeds afhankelijk zijn van fysieke hardwaretokens in plaats van gecentraliseerde HSM-ondertekening.

Wat heb ik nodig voordat ik een bedrijfsbrede codeondertekeningsoplossing zoals CodeSign Secure implementeer?

Minimaal heb je een FIPS 140-2 Level 3 HSM nodig (on-premises, in de cloud of als een service), build agents of CI/CD-runners voor elk platform waarvoor je ondertekent, de juiste certificaten voor elk gebruiksscenario en een identiteitsbron om goedkeurders te koppelen aan de RBAC- en M-of-N-workflow. De exacte ondersteunde besturingssysteemversies en CI/CD-integraties moeten worden gecontroleerd aan de hand van de actuele implementatiedocumentatie.

Maakt het centraliseren van codeondertekening de behoefte aan platformspecifieke ondertekeningstools overbodig?

Nee. Tools zoals de toolchain van Xcode voor Apple-notarisatie of de verpakkingstools van de Windows Hardware Lab Kit voor drivercertificering worden nog steeds uitgevoerd op de buildagent om het artefact voor te bereiden. CodeSign Secure wijzigt de locatie van de privésleutel en de manier waarop het ondertekeningsverzoek wordt geautoriseerd, niet de platformspecifieke verpakkingsstap zelf.