Volwassenheid van codeondertekening blootgelegd: uitdagingen en inzichten

Vraag de meeste ontwikkelteams of ze code ondertekenen, en het antwoord is ja. Vraag echter of ze een gecentraliseerd ondertekeningsbeleid hebben, een gedocumenteerde procedure voor sleutelbeheer, een auditlogboek van elke ondertekeningsgebeurtenis en een geautomatiseerd proces voor het verlengen van certificaten voordat ze verlopen, en het antwoord wordt een stuk complexer.

De kloof tussen "we ondertekenen code" en "we hebben een volwaardig codeondertekeningsprogramma" is groter dan de meeste organisaties beseffen. En in 2026 is die kloof belangrijker dan ooit. Aanvallen op de toeleveringsketen bereiken recordhoogtes en volgens het Verizon Data Breach Investigations Report 2026, waarin meer dan 22,000 bevestigde datalekken in 145 landen werden geanalyseerd, blijkt dat betrokkenheid van derden nu verantwoordelijk is voor 48% van alle datalekken, een stijging van 60% ten opzichte van het voorgaande jaar.

CA/Browser Forum Ballot CSC-31 heeft de geldigheidsduur van codeondertekeningscertificaten verkort van 39 maanden naar 460 dagen, met ingang van 1 maart 2026. NIST publiceerde in december 2025 een eerste openbare conceptversie van SSDF Versie 1.2 (SP 800-218 Revisie 1), waarmee de lat hoger wordt gelegd voor wat aantoonbaar veilige softwareontwikkeling inhoudt. En toezichthouders in diverse sectoren verschuiven van richtlijnen naar handhaving.

We gaan een praktisch model voor de volwassenheid van codeondertekening bekijken: vier fasen die beschrijven hoe organisaties evolueren van gefragmenteerde, ad-hoc ondertekeningspraktijken naar volledig geautomatiseerde, beleidsgestuurde en toekomstbestendige programma's. Waar uw organisatie zich ook bevindt, inzicht in uw huidige situatie en hoe de volgende fase eruitziet, is het startpunt om die fase te bereiken.

Volwassenheid van codeondertekening, gedefinieerd: de mate waarin door HSM ondersteunde sleutelbewaring, RBAC met functiescheiding, goedkeuringspoorten, geplande sleutelrotatie, onveranderlijke auditlogboeken, geteste intrekking, verplichte tijdstempeling en geïsoleerde bouwomgevingen worden afgedwongen door de infrastructuur in plaats van door beleidsdocumenten die mensen geacht worden te volgen, gemeten over vier fasen van ad-hoc tot geoptimaliseerd.

Key Takeaways

• 3CX (2023) is het duidelijkste bewijs dat volwassenheid, en niet cryptografie, doorgaans de oorzaak van de problemen is: zowel de handtekening als het certificaat waren authentiek, en de inbreuk vond plaats omdat er geen controlemechanisme was dat een aanvaller die toegang kreeg tot de ontwikkelomgeving ervan weerhield een ondertekeningsoperatie te activeren.
• Een beleid dat technisch gezien niet wordt gehandhaafd, is geen controlemechanisme; de ​​kloof tussen "we hebben een ondertekeningsbeleid" en "onze infrastructuur maakt het onmogelijk om het beleid te omzeilen" is de volledige afstand tussen fase 2 en fase 3.
• Sleutelrotatie, voorbereiding op intrekking en isolatie van builds ontbreken vaak, zelfs bij verder volwassen programma's; zie "Niet overslaanbare controles" hieronder voor de specifieke vereisten.
• Deze pagina vormt het diagnostisch kader: hoe staat uw programma ervoor en wat is de volgende stap? Voor een overzichtelijke, fase-onafhankelijke checklist van individuele werkwijzen, zie Best practices voor codeondertekening in de SDLC.
• Een volwassenheidsscore is een diagnostisch hulpmiddel, geen veiligheidsgarantie; zie "Beperkingen" hieronder voordat u een resultaat van Fase 3 of 4 als voldoende bewijs van veiligheid beschouwt.

Waarom de volwassenheid van codeondertekening belangrijker is dan ooit tevoren

Codeondertekening bestaat om één fundamentele reden: softwaregebruikers en -platformen een manier bieden om te verifiëren dat een binair bestand is geproduceerd door een bekende, vertrouwde partij en niet is gewijzigd sinds de ondertekening. Wanneer het correct werkt, is het het belangrijkste mechanisme waarmee de identiteit van software wordt vastgesteld en de integriteit ervan wordt gewaarborgd.

Als het mislukt, bijvoorbeeld doordat een ondertekeningssleutel wordt gestolen, een certificaat zonder toestemming wordt gebruikt of een ondertekeningshandeling buiten elk governancekader plaatsvindt, kunnen de gevolgen ernstig en verstrekkend zijn.

Laten we eens kijken naar een van de meest significante aanvallen op de toeleveringsketen in de recente geschiedenis om precies te zien wat er gebeurt als codeondertekening wordt misbruikt:

3CX (2023): De aan Noord-Korea gelieerde Lazarus Group voerde een cascade-aanval uit op de toeleveringsketen, waarbij een gecompromitteerd financieel softwarepakket leidde tot de compromittering van de ontwikkelomgeving van 3CX. De 3CX-desktopapplicatie, die door ongeveer 600,000 organisaties werd gebruikt, werd vervolgens ondertekend met een legitiem certificaat van 3CX zelf en als routine-update naar klanten verzonden. Noch de handtekening, noch het certificaat was frauduleus. Het ondertekende document zelf was echter kwaadaardig.

Deze aanval biedt een belangrijke les: een geldige handtekening op kwaadwillende code is geen falen van de beveiligingsmaatregelen op cryptografisch niveau, maar een falen van de governance en de processen. Noch de sleutel, noch het certificaat werd gestolen of vervalst. Het ondertekeningsproces bevatte simpelweg geen controles die een aanvaller, die al toegang had tot de ontwikkelomgeving, ervan zouden hebben weerhouden een ondertekeningsoperatie te starten.

Wat is een Code Signing Maturity Model?

Een volwassenheidsmodel is een raamwerk dat beschrijft hoe een capaciteit zich ontwikkelt van een initiële, informele toepassing tot een volledig geoptimaliseerde werking. Het Capability Maturity Model (CMM), oorspronkelijk ontwikkeld door het Software Engineering Institute van Carnegie Mellon, legde het fundamentele patroon vast dat vereist dat organisaties door gedefinieerde fasen heen gaan, waarbij elke fase een hoger niveau van procesdiscipline, herhaalbaarheid en veerkracht vertegenwoordigt.

Hieronder vindt u alle criteria die van belang zijn voor de volwassenheid van codeondertekening:

Afmeting	Wat het omvat
Sleutelbeheer	Hoe worden privésleutels voor digitale handtekeningen gegenereerd, opgeslagen, beveiligd en geroteerd?
Access Controle	Wie mag tekenen, wat mogen ze tekenen en welk toezicht is er op die toegang?
Beleid en bestuur	Of het ondertekeningsbeleid is vastgelegd, gehandhaafd en gecontroleerd.
Certificaatbeheer	Hoe certificaten binnen de organisatie worden bijgehouden, verlengd en ingetrokken.
Pijplijnintegratie	Of het nu gaat om het integreren van de ondertekening in CI/CD-workflows of om handmatige uitvoering.
Audit en monitoring	Of elke ondertekeningsgebeurtenis wordt geregistreerd, beoordeeld en of afwijkende gebeurtenissen worden gemeld.
Reactie op incidenten	Of de organisatie nu een plan heeft voor gecompromitteerde sleutels of ongeautoriseerde ondertekening.
Toekomstige gereedheid	Of het programma rekening houdt met post-kwantumcryptografie en evoluerende standaarden.

Controles die u niet mag overslaan: Rotatie, intrekking, functiescheiding en gebouwisolatie.

Zelfs in programma's die er verder volwassen uitzien, worden vier beveiligingsmaatregelen overgeslagen, omdat ze pas verschijnen wanneer er iets nodig is. Door ze expliciet te benoemen in plaats van ze onder te brengen in 'sleutelbeheer' of 'toegangscontrole', worden ze gemakkelijker te controleren.

Toetsrotatie

Het opslaan van een sleutel in een HSM geeft antwoord op de vraag waar de sleutel zich bevindt, niet hoe lang deze daar ongewijzigd blijft. Een volwaardig programma definieert een rotatieschema per sleutel, gekoppeld aan de verlenging van certificaten binnen de huidige geldigheidsperiode van minimaal 460 dagen, en behandelt rotatie als een routinematige, geautomatiseerde gebeurtenis in plaats van iets dat alleen wordt geactiveerd door een vermoedelijke inbreuk. Als uw programma alleen kan antwoorden op de vraag "wanneer is deze specifieke ondertekeningssleutel voor het laatst geroteerd?" door te controleren wanneer het certificaat toevallig is verlopen, wordt rotatie in feite niet beheerd als een eigen controlemechanisme.

Voorbereiding op intrekking

Een gedocumenteerd incidentresponsplan is niet hetzelfde als een getest plan. Klaar zijn voor intrekking betekent dat je vóór een incident precies weet welke artefacten een bepaald certificaat heeft ondertekend, dat je die lijst binnen een uur kunt overleggen zodra een inbreuk wordt vermoed, en dat je al hebt bevestigd dat het intrekken van het certificaat geen distributiekanaal stilletjes verstoort dat de intrekkingsstatus niet controleert. Zie voor de specifieke details over intrekking, de implicaties voor tijdstempels en het opnieuw ondertekenen na een inbreuk het document " Een framework voor firmwareondertekening opzetten voor CRA-naleving ".

Scheiding van verantwoordelijkheden

RBAC beantwoordt de vraag wie mag tekenen; scheiding van taken beantwoordt de vraag of één enkele identiteit zowel een ondertekeningsverzoek kan indienen als deze kan goedkeuren. Een programma kan een gedetailleerde RBAC hebben en toch niet voldoen aan de eisen van de scheiding van taken als de rol van een hoofdontwikkelaar beide machtigingen omvat. De technische controle is eenvoudig: kan één account, die alleen handelt, een artefact laten ondertekenen zonder tussenkomst van een tweede identiteit? Zo ja, dan is dat een tekortkoming in fase 2 waarvoor tools van fase 3 nodig zijn.

Bouw isolatie

Dit is de controle die de buildomgeving van 3CX miste, en het is de controle die de meeste zelfevaluaties van de volwassenheidsgraad overslaan omdat deze zich vóór de ondertekeningsoperatie zelf bevindt. Buildisolatie betekent dat de omgeving die het artefact produceert tijdelijk en eenmalig is, en geen permanente buildserver die door één gecompromitteerde run voor elke volgende build kan worden besmet. Het is een controle op de buildpipeline, niet op het ondertekeningsplatform, en dat is precies waarom het gemakkelijk over het hoofd wordt gezien bij een volwassenheidsbeoordeling die zich richt op ondertekening. Zie ' Strengthening Supply Chain Security with SLSA Level 3 and Code Signing' voor meer informatie over hoe SLSA Level 3 deze vereiste formaliseert.

De vier fasen van volwassenheid van codeondertekening

Fase 1: Ad hoc — Ondertekenen zonder structuur

De eerste fase is waar bij de meeste organisaties codeondertekening weliswaar plaatsvindt, maar niet wordt beheerd als een degelijk, specifiek systeem. Dit omvat:

• Een of meerdere ontwikkelaars beheren het codeondertekeningscertificaat en de privésleutel, die vaak zijn opgeslagen op een lokale computer, een USB-stick of als een bestand op een gedeelde buildserver.
• Er bestaat geen formeel beleid waarin is vastgelegd wie bevoegd is om te tekenen, wat er getekend mag worden of onder welke voorwaarden het tekenen moet plaatsvinden.
• De vervaldatum van certificaten wordt informeel bijgehouden, afhankelijk van of een ontwikkelaar eraan denkt (of niet), en de verlenging gebeurt reactief, vaak naar aanleiding van een mislukte ondertekening in plaats van proactief beheer.
• Als je gevraagd wordt "wat heb je afgelopen kwartaal ondertekend?", dan zou het antwoord handmatig zoeken in de buildlogs vereisen, als die logs en audit trails al bestaan.
• Het ondertekenen is een handmatige stap die door een ontwikkelaar wordt uitgevoerd wanneer het tijd is om een ​​release voor te bereiden en is niet geïntegreerd in een geautomatiseerd proces.
• Er is geen plan voor wat er gebeurt als het certificaat wordt gecompromitteerd of als de ontwikkelaar die de ondertekeningssleutel beheert de organisatie verlaat.

In dit stadium is de infrastructuur voor het ondertekenen van documenten in feite onbeschermd. Privésleutels op softwarematig toegankelijke locaties zijn kwetsbaar voor elke aanvaller die toegang krijgt tot het werkstation van de ontwikkelaar of de buildserver. Er is geen functiescheiding; dezelfde persoon die code schrijft, kan deze ondertekenen zonder onafhankelijke controle. Er is geen inzicht in de ondertekeningsgebeurtenissen, waardoor ongeautoriseerde ondertekening onopgemerkt blijft. En omdat er geen gedocumenteerd beleid is, valt er niets te controleren.

Dit is de omgeving die aanvallers hebben misbruikt bij de aanvallen op SolarWinds en 3CX. Het ging niet om geavanceerde zero-day-aanvallen op de cryptografische algoritmen, maar om onbeveiligde toegang tot de ondertekeningsstap in een niet-gecontroleerde buildomgeving.

Fase 2: Gedefinieerd — Beleid bestaat, maar er blijven lacunes bestaan

Organisaties in fase 2 hebben erkend dat ad-hoc codeondertekening een risico vormt en hebben stappen ondernomen om dit te formaliseren. Er is een beleidsdocument en sleutels worden veiliger opgeslagen. De werkwijzen worden echter niet consequent gehandhaafd en er blijven lacunes bestaan, met name op het gebied van automatisering, auditdekking en certificaatlevenscyclusbeheer. Deze fase omvat het volgende:

• Er bestaat een schriftelijk beleid voor het ondertekenen van code, waarin de vereisten voor sleutelopslag, wie bevoegd is om te ondertekenen en hoe certificaten beheerd moeten worden, worden beschreven. De naleving van dit beleid is echter inconsistent, omdat het meer wordt afgedwongen door bewustwording en conventies dan door technische controles.
• Privésleutels zijn van de ontwikkelaarscomputers verwijderd. Sleutels kunnen worden opgeslagen op USB-hardwaretokens die voldoen aan FIPS 140-2 Level 2, wat voldoet aan de vereisten. CA / Browser Forum Dit voldoet aan de eisen, maar brengt logistieke uitdagingen met zich mee, met name onder de nieuwe geldigheidsperiode van 460 dagen voor certificaten, waarbij tokens ongeveer elke 15 maanden vervangen moeten worden.
• Er is een vorm van toegangscontrole waarbij niet iedereen kan ondertekenen en bepaalde certificaten zijn bestemd voor specifieke omgevingen (ontwikkeling versus productie). Deze controle is echter niet gedetailleerd genoeg en wordt niet op technisch niveau afgedwongen; ontwikkelaars moeten zich aan de gedocumenteerde procedures houden.
• Een inventaris van certificaten bestaat weliswaar in een of andere vorm, zoals een spreadsheet, een gedeelde agendaherinnering of een ticket in een projectmanagementsysteem, maar deze wordt handmatig bijgehouden en kan daardoor verouderd raken.
• Voor sommige producten is het ondertekenen mogelijk gedeeltelijk geïntegreerd in de build-pipelines, maar voor andere producten, met name oudere producten of producten die door kleinere teams worden beheerd, blijven handmatige ondertekeningsstappen nodig.
• Er bestaat weliswaar enige vorm van auditlogging waarbij ondertekeningsgebeurtenissen in buildlogs kunnen worden vastgelegd, maar deze gegevens worden niet gecentraliseerd, niet actief gemonitord en niet gebruikt om afwijkingen op te sporen.

Het grootste risico in fase 2 is de kloof tussen beleid en praktijk. Beleid dat technisch gezien niet wordt gehandhaafd, is in feite geen echte controle. Wanneer een beleid zegt dat "sleutels niet op de werkstations van ontwikkelaars mogen worden opgeslagen", maar niets een ontwikkelaar ervan weerhoudt om een ​​sleutelbestand voor het gemak naar zijn laptop te kopiëren, biedt het beleid een vals gevoel van veiligheid. Evenzo is een toegangscontrolemodel dat afhankelijk is van mensen die gedocumenteerde procedures volgen, kwetsbaar voor zowel interne dreigingen als externe inbreuken.

Fase 3: Beheerd — Gecentraliseerd, gecontroleerd en geaudit

In fase 3 is codeondertekening geëvolueerd van een gedocumenteerd beleid naar een technisch afgedwongen, centraal beheerde discipline. De controles zijn niet alleen op papier vastgelegd; ze zijn geïmplementeerd in de infrastructuur en systemen. Toegang wordt geregeld door RBAC (Role-Based Access Control) dat is geconfigureerd en afgedwongen in een ondertekeningsplatform met sleutels in HSM's (Hardware Security Modules) in plaats van tokens. Het beschikt bovendien over een uitgebreid en actief gemonitord auditspoor.

• Privé-ondertekeningssleutels worden intern gegenereerd en verlaten het platform nooit. FIPS 140-2 Level 3-gecertificeerd. HardwarebeveiligingsmodulesDe fysieke of cloud-HSM wordt beheerd door het beveiligingsteam en niet door individuele ontwikkelaars. Sleutelexport is technisch gezien uitgeschakeld op HSM-beleidsniveau.
• Een gecentraliseerd platform voor digitale handtekeningen zorgt voor op rollen gebaseerde toegangscontrole, waarbij toegewezen rollen met gedefinieerde machtigingen bepalen wie een ondertekeningsverzoek kan indienen, wie dit moet goedkeuren en welke documenten met welk certificaat kunnen worden ondertekend.  
• Het beheer van de levenscyclus van codeondertekeningscertificaten is systematisch, met een inventaris van alle ondertekeningscertificaten, inclusief vervaldatums, toegewezen eigenaren en bijbehorende producten en pipelines. Deze informatie wordt bijgehouden in een beheersysteem, niet in een spreadsheet. Vernieuwingswaarschuwingen worden automatisch en ruim van tevoren geactiveerd.
• Het ondertekenen is geïntegreerd in CI/CD-pipelines voor alle productieartefacten en is een gecontroleerde, door beleid afgedwongen fase in de releasepipeline, geen handmatige stap die door een ontwikkelaar wordt geïnitieerd. RFC 3161-tijdstempels worden consistent toegepast op alle ondertekeningsbewerkingen.
• Elke ondertekeningsgebeurtenis genereert een onveranderlijke auditlogboekvermelding met de hash van het artefact, het gebruikte certificaat, de tijdstempel, de aanvragende identiteit en de goedkeuringsketen. De logboeken worden gecentraliseerd, actief gecontroleerd en afwijkende ondertekeningsgebeurtenissen genereren realtime waarschuwingen.
• Er is een gedocumenteerd incidentresponsplan voor het geval van een inbreuk op de ondertekeningssleutels. Dit plan beschrijft welke sleutels via softwaremechanismen kunnen worden ingetrokken en vervangen, welke hardwarevervanging vereisen en hoe het communicatie- en herstelproces eruitziet.

In fase 3 is de infrastructuur voor digitale handtekeningen daadwerkelijk moeilijk te misbruiken. Een aanvaller die een ontwikkelaarsaccount hackt, kan worden geblokkeerd en kan geen handtekeningen meer zetten. Een interne dreiging die probeert een ongeautoriseerd document te ondertekenen, genereert een waarschuwing voor een afwijking. Een certificaat dat bijna verloopt, activeert een geautomatiseerde verlengingsprocedure in plaats van stilletjes te verlopen en een productiestoring te veroorzaken. Dankzij een goede auditlog kunnen alle historische handtekeninggebeurtenissen worden bekeken, getraceerd en onderzocht.

Fase 4: Geoptimaliseerd — Geautomatiseerd, veerkrachtig en toekomstbestendig

Organisaties op dit niveau hebben niet alleen strenge controles geïmplementeerd, maar ook een digitaal ondertekeningsprogramma ontwikkeld dat continu wordt verbeterd, proactief inspeelt op veranderingen in de sector en is ontworpen om bestand te blijven tegen toekomstige ontwikkelingen, waaronder de migratie naar post-kwantumcryptografie en de voortdurende evolutie van de regelgeving.

• De infrastructuur voor digitale handtekeningen is volledig geautomatiseerd. Het vinden, verlengen, uitrollen en intrekken van certificaten wordt door geïntegreerde systemen afgehandeld zonder handmatige tussenkomst.
• De organisatie heeft crypto-flexibiliteit geïmplementeerd in haar infrastructuur voor digitale handtekeningen. Algoritme- en sleutelgrootte-migraties kunnen worden uitgevoerd voor alle certificaten zonder dat individuele pipeline-updates of handmatige herconfiguratie nodig zijn.
• Post-kwantumcryptografie Ondertekening is in productie of in een actieve pilotfase voor artefacten met een lange levenscyclus. NIST heeft algoritmen zoals ML-DSA (FIPS204), SLH-DSA (FIPS205), en LMS (NIST SP 800-208) als goedgekeurde post-kwantumsignatuuralgoritmen.  
• Het programma voor codeondertekening maakt deel uit van het bredere beveiligingskader van de toeleveringsketen van de organisatie en is geïntegreerd met de generatie van software-stuklijsten (SBOM), het traceren van de herkomst van binaire bestanden en processen voor kwetsbaarheidsbeheer.
• De organisatie voert regelmatig vijandige tests uit op haar ondertekeningsinfrastructuur, zoals red team-oefeningen waarbij geprobeerd wordt RBAC-controles te omzeilen, ongeautoriseerde ondertekeningsacties te introduceren of sleutelmateriaal te extraheren, om te valideren dat de controles naar behoren functioneren onder realistische aanvalsomstandigheden.
• De belangrijkste reactieplannen bij een inbreuk worden geoefend, met gedocumenteerde hersteltijdsdoelstellingen voor elke categorie ondertekeningssleutels en certificaten.

In fase 4 beschermt het ondertekeningsprogramma niet alleen tegen bekende aanvalspatronen, maar is het ook architectonisch bestand tegen toekomstige aanvallen. De post-kwantumtransitie, die voor de meeste organisaties eind jaren 2020 aanzienlijke infrastructuurwerkzaamheden zal vergen, is al in volle gang. Wettelijke wijzigingen die aantoonbaar bewijs van naleving vereisen, zoals NIST SSDF-attestatie, auditlogboeken voor federale softwarecontracten en sectorspecifieke vereisten, kunnen worden voldaan met operationele gegevens in plaats van dat achteraf documentatie nodig is.

Zelfevaluatiescorekaart

Beoordeel elke dimensie aan de hand van de fase die het beste aansluit bij de huidige praktijk, niet de fase waarnaar u streeft. Wees specifiek: "we hebben RBAC" telt alleen als Fase 3 als het technisch wordt gehandhaafd en de scheiding van taken omvat, niet alleen als het is gedocumenteerd.

Afmeting	Fase 1 (Ad Hoc)	Fase 2 (gedefinieerd)	Fase 3 (Beheerd)	Fase 4 (Geoptimaliseerd)
Sleutelbewaring	Lokale computer of gedeeld bestand	Hardwaretoken, individueel bewaard.	HSM, exporteren uitgeschakeld	HSM met geautomatiseerde rotatie en crypto-agility
Toegangscontrole	Geen beperkingen	Informeel, op procedures gebaseerd	Technisch afgedwongen RBAC	RBAC plus geoefende test voor functiescheiding
herroeping	Geen plan	Gedocumenteerd maar niet getest	Getest plan, mapping van artefact naar certificaat bestaat	Geoefend met vastgestelde hersteltijddoelen.
Bouw isolatie	Permanente, gedeelde buildserver	Permanente server, enige beveiliging tegen toegang.	Per build afzonderlijk geïsoleerd en handmatig geverifieerd.	Standaard tijdelijk, SLSA-uitgelijnd
Controlespoor	Geen of informele bouwlogboeken	Er bestaan ​​logbestanden, maar ze zijn niet gecentraliseerd.	Gecentraliseerd, onveranderlijk, actief gecontroleerd	Geïntegreerd met SIEM en waarschuwingen voor afwijkingen.

Hoe voer je de beoordeling uit?

1. Beoordeel elke dimensie in de bovenstaande tabel afzonderlijk; de meeste organisaties bevinden zich op verschillende niveaus op verschillende dimensies, wat normaal is en meer informatie geeft dan één algemene score.
2. Identificeer de laagst scorende dimensie, niet het gemiddelde; een programma van fase 3 met een voorbereiding op intrekking op fase 1-niveau heeft een risico op een incident in fase 1.
3. Controleer elke score aan de hand van een externe deadline die de urgentie ervan bepaalt: de geldigheidsperiode van 460 dagen voor certificaten is van invloed op de score voor belangrijke aspecten zoals bewaring en rotatie; de ​​aankomende NIST SSDF-attestatievereisten zijn van invloed op de score voor audit trails en beleid.
4. Stel een routekaart op die eerst de laagst scorende dimensie aanpakt, niet de gemakkelijkste; een snelle overwinning op een dimensie die al in fase 3 zat, vermindert je werkelijke risico niet.

Beperkingen

Een volwassenheidsscore is een zelfbeoordeling, geen auditbevinding, en de nauwkeurigheid ervan hangt af van de eerlijkheid van degenen die de score geven; een technische controlebeoordeling of een red-team oefening (onderdeel van fase 4 zelf) brengt lacunes aan het licht die een zelfbeoordeling over het hoofd ziet. Het bereiken van fase 3 of 4 maakt een organisatie ook niet immuun voor inbreuken, maar maakt specifieke, bekende faalmodi (gedeelde sleutels, niet-afgedwongen RBAC, niet-gecontroleerde ondertekening) veel moeilijker te exploiteren, terwijl nieuwe of onverwachte aanvalstechnieken mogelijk blijven, ongeacht de fase.

Hoe kan CodeSign Secure van Encryption Consulting u helpen?

CodeSign Secure is het gecentraliseerde, op beleid gebaseerde platform voor codeondertekening van Encryption Consulting. Het is ontworpen om organisaties in elke fase van hun ontwikkelingstraject te ondersteunen en biedt de infrastructuur en controles die nodig zijn om fase 3 te bereiken en de geavanceerde mogelijkheden die vereist zijn om fase 4 te realiseren.

CodeSign Secure biedt organisaties die overstappen van ad-hoc of gedeeltelijk gedefinieerde ondertekeningspraktijken een directe manier om de fundamentele controles te implementeren die kenmerkend zijn voor Fase 3:

HSM-ondersteund sleutelbeheer: Privé-ondertekeningssleutels worden intern gegenereerd en verlaten nooit de FIPS 140-2 Level 3-gecertificeerde hardwarebeveiligingsmodules. CodeSign Secure integreert met Thales Luna, Entrust nCipher, Utimaco, Securosys en cloud-HSM's van AWS en Azure. Sleutelexport is uitgeschakeld op beleidsniveau. Het USB-tokenmodel en alle bijbehorende logistieke uitdagingen op het gebied van verlenging en toegangsbeheer worden vervangen door een gecentraliseerde, via API toegankelijke ondertekeningsinfrastructuur.

Geforceerde RBAC en goedkeuringsworkflows: Het op rollen gebaseerde toegangscontrolemodel van CodeSign Secure stelt beheerders in staat om nauwkeurig te definiëren wie een ondertekeningsbewerking mag aanvragen, wat ze mogen ondertekenen, welk certificaat wordt gebruikt en welke autorisatiestappen moeten worden doorlopen voordat de ondertekening plaatsvindt. Deze controles worden programmatisch afgedwongen en zijn niet afhankelijk van het volgen van gedocumenteerde procedures door personen.

Beheer van codeondertekeningscertificaten: Het platform houdt een gecentraliseerde inventaris bij van alle beheerde certificaten, met geautomatiseerde verlengingsmeldingen die zijn geconfigureerd om teams voldoende tijd te geven binnen de nieuwe geldigheidsperiode van 460 dagen.

Voor organisaties die al fundamentele controles hebben ingevoerd en werken aan optimalisatie en fase 4:

CI/CD-pipeline-integratie: CodeSign Secure integreert naadloos met Azure DevOps , Jenkins , GitLab CI en andere belangrijke pipeline-systemen. Ondertekeningsbewerkingen worden API-gestuurd door integratie met tools van derden, waarbij de RFC 3161-tijdstempeling wordt afgedwongen.

Ondersteuning voor post-kwantumcryptografie: CodeSign Secure v3.02 introduceert productiegereedde ondersteuning voor ML-DSA (FIPS 204, beschikbaar op beveiligingsniveaus ML-DSA-44, ML-DSA-65 en ML-DSA-87) als afneembare handtekeningen, waardoor organisaties kunnen beginnen met de overgang naar post-kwantumcryptografie.

Auditregistratie en -rapportage: Elke ondertekeningsgebeurtenis in CodeSign Secure genereert een onveranderlijke logvermelding met de hash van het artefact, het certificaat, de tijdstempel, de aanvragende identiteit en de goedkeuringsketen. Logs worden via Opentelemetry geïntegreerd met SIEM-platforms zoals Splunk en Grafana Loki voor realtime detectie van afwijkingen.

Of u nu begint bij Fase 1 en snel fundamentele controles wilt implementeren, of dat u zich in Fase 3 bevindt en werkt aan volledige automatisering en paraatheid na de kwantumcrisis, CodeSign Secure biedt de infrastructuur om die reis te ondersteunen.

Conclusie

Het bereiken van volwassenheid op het gebied van codeondertekening is geen eindbestemming, maar een proces dat je moet doorlopen. Elke organisatie bevindt zich ergens op deze weg, en elke verbeteringsstap vermindert op significante wijze risico's en operationele kwetsbaarheden.

Bij Encryption Consulting hebben we CodeSign Secure ontwikkeld om die transitie in elke fase van het traject praktisch te maken. De vraag "zijn uw codeondertekeningsprocessen volwassen?" heeft geen simpel ja of nee antwoord. Maar er is wel een specifiek, concreet antwoord: breng in kaart waar u zich bevindt, identificeer welke onderdelen het meest achterlopen en stel een prioriteitenlijst op om de hiaten te dichten.

In 2026 wordt de urgentie van die routekaart bepaald door ontwikkelingen in de sector, zoals de 460-dagen geldigheidsduur van certificaten, waardoor handmatig lifecyclemanagement onhoudbaar wordt, aanvallen op de toeleveringsketen die blijven profiteren van zwakke governance op het gebied van digitale handtekeningen, de NIST SSDF-vereisten die aantoonbaar veilige ontwikkelingspraktijken vereisen, en de naderende post-kwantumtransitie die infrastructurele veranderingen vereist waar de meeste organisaties nog niet mee zijn begonnen.

Veelgestelde Vragen / FAQ

Kan een organisatie zich in verschillende volwassenheidsstadia bevinden voor verschillende beheersmaatregelen?

Ja, en dit is eerder de normale gang van zaken dan de uitzondering. Een programma heeft vaak een sterke, door HSM ondersteunde sleutelbewaring (Fase 3), terwijl het intrekkingsplan nog nooit is getest (Fase 2) of de ontwikkelomgeving niet geïsoleerd is (Fase 1 of 2). Beoordeel elke dimensie afzonderlijk in plaats van één algemeen cijfer toe te kennen.

Is een schriftelijk vastgelegd beleid voor codeondertekening voldoende om fase 3 te bereiken?

Nee. Een schriftelijk beleid dat technisch gezien niet wordt gehandhaafd, waarbij niets iemand ervan weerhoudt het te omzeilen, is een kenmerk van Fase 2. Fase 3 vereist dat de controles in de infrastructuur worden geïmplementeerd (HSM-beleid, RBAC-handhaving, geautomatiseerde certificaatregistratie) in plaats van te vertrouwen op mensen die gedocumenteerde procedures volgen.

Waarom maakte bouwisolatie geen deel uit van de oorspronkelijke acht dimensies?

Build-isolatie bevindt zich vóór de ondertekeningsoperatie zelf, in de build-pipeline in plaats van op het ondertekeningsplatform. Dit is precies de reden waarom volwassenheidsbeoordelingen die zich richten op ondertekening het vaak over het hoofd zien. Het is de controle die de build-omgeving van 3CX miste en die thuishoort in elke beoordeling die daadwerkelijk probeert die faalmodus te voorkomen, en niet alleen de sleutelbewaking te verbeteren.

Wat is het verschil tussen dit volwassenheidsmodel en een checklist met best practices?

Een checklist bevat een lijst met werkwijzen die je kunt toepassen; een volwassenheidsmodel analyseert waar je momenteel staat ten opzichte van elk onderdeel en wat de volgende concrete stap is, zodat de inspanningen eerst gericht zijn op de dimensie met de laagste score in plaats van gelijkmatig verdeeld te worden over een platte lijst. Voor de platte checklistversie, zie Best Practices voor codeondertekening in de SDLC.