Kodsigneringsmognad avslöjad: Utmaningar och insikter

Fråga de flesta utvecklingsteam om de använder kodsignering, och svaret är ja. Fråga om de har en centraliserad signeringspolicy, en dokumenterad nyckelhanteringsprocedur, en revisionslogg för varje signeringshändelse och en automatiserad process som hanterar certifikatförnyelser innan de löper ut, och svaret blir mer komplicerat.

Klyftan mellan ”vi signerar kod” och ”vi har ett moget kodsigneringsprogram” är större än de flesta organisationer inser. Och år 2026 är den klyftan mer betydelsefull än någonsin. Attacker i leveranskedjan är på rekordnivåer, och enligt Verizons rapport om dataintrång från 2026 , som analyserade över 22 000 bekräftade intrång i 145 länder, fann man att tredjepartsinblandning nu står för 48 % av alla intrång, en ökning med 60 % från föregående år.

CA/Browser Forum-omröstningen CSC-31 har minskat giltighetstiden för kodsigneringscertifikat från 39 månader till 460 dagar, med verkan från och med den 1 mars 2026. NIST släppte ett första offentligt utkast av SSDF version 1.2 (SP 800-218 Revision 1) i december 2025, vilket höjer ribban för vad som utgör påvisbart säker programvaruutveckling. Och tillsynsmyndigheter inom olika sektorer går från vägledning till verkställighet.

Vi kommer att titta på en praktisk modell för kodsigneringsmognad: fyra steg som beskriver hur organisationer utvecklas från fragmenterade, ad hoc-signeringsmetoder till helt automatiserade, policystyrda och framtidssäkra program. Oavsett var din organisation befinner sig idag är det utgångspunkten för att komma dit att förstå var du står och hur nästa steg ser ut.

Varför mognad vid kodsignering är viktigare än någonsin

Kodsignering finns av en enda grundläggande anledning: att ge programvaruanvändare och plattformar ett sätt att verifiera att en binärfil har producerats av en känd, betrodd part och inte har ändrats sedan den signerades. När den fungerar korrekt är det den primära mekanismen genom vilken programvaruidentitet fastställs och programvaruintegritet säkerställs.

När det misslyckas, vilket kan bero på att en signeringsnyckel blir stulen, ett certifikat används utan auktorisering eller att en signeringsåtgärd sker utanför något styrningsramverk, kan konsekvenserna bli allvarliga och långtgående.

Låt oss titta på en av de mest betydande attackerna mot leveranskedjorna på senare tid för att se exakt vad som händer när kodsignering missbrukas:

3CX (2023): Den nordkoreanska Lazarus-gruppen utförde en kaskadattack mot leveranskedjor där ett komprometterat finansiellt programvarupaket ledde till att 3CX byggmiljö komprometterades. 3CX-skrivbordsapplikationen, som används av cirka 600 000 organisationer, signerades sedan med 3CX eget legitima certifikat och distribuerades till kunder som en rutinuppdatering. Varken signaturen eller certifikatet var bedrägligt. Den signerade artefakten i sig var skadlig.

Denna attack delar en viktig lärdom: en giltig signatur på skadlig kod är inte ett säkerhetskontrollfel på kryptografisk nivå; det är ett styrnings- och processfel. Varken nyckeln eller certifikatet stals eller förfalskades. Signeringsprocessen hade helt enkelt inga kontroller som skulle ha hindrat en angripare som redan hade nått byggmiljön från att utlösa en signeringsoperation.

Vad är en mognadsmodell för kodsignering?

En mognadsmodell är ett ramverk som beskriver hur en förmåga utvecklas från initial, informell praktik till fullt optimerad drift. Capability Maturity Model (CMM), ursprungligen utvecklad av Carnegie Mellons Software Engineering Institute, etablerade det grundläggande mönstret, vilket krävde att organisationer gick igenom definierade steg, där vart och ett representerade en högre nivå av processdisciplin, repeterbarhet och motståndskraft.

Här är alla kriterier som är viktiga för kodsigneringsmognad:

Dimensionera	Vad det täcker
Nyckelhantering	Hur privata signeringsnycklar genereras, lagras, skyddas och roteras
Åtkomstkontroll	Vem kan skriva under, vad de kan skriva under och vilken tillsyn styr den åtkomsten
Policy och styrning	Huruvida signeringspolicyer dokumenteras, tillämpas och granskas
Certifikathantering	Hur certifikat spåras, förnyas och återkallas i hela organisationen
Pipeline-integration	Om signering är inbäddad i CI/CD-arbetsflöden eller utförs manuellt
Revision och övervakning	Om varje signeringshändelse loggas, granskas och om avvikande händelser aviseras
Incidentrespons	Om organisationen har en plan för komprometterade nycklar eller obehörig signering
Framtida beredskap	Huruvida programmet tar hänsyn till postkvantkryptografi och utvecklande standarder

De fyra stadierna av kodsigneringsmognad

Steg 1: Ad hoc — Signering utan struktur

Det första steget är där de flesta organisationer bara kodsignering sker, men det hanteras inte som ett ordentligt dedikerat system. Detta inkluderar:

• En eller ett litet antal utvecklare innehar kodsigneringscertifikatet och den privata nyckeln, ofta lagrade på en lokal maskin, en USB-token eller som en fil på en delad byggserver.
• Det finns ingen formell policy som dokumenterar vem som är behörig att skriva under, vad som kan skrivas under eller under vilka villkor signering ska ske.
• Certifikatets utgång spåras informellt där en utvecklare kommer ihåg det (eller inte gör det) och förnyelsen är reaktiv, ofta orsakad av ett signeringsfel snarare än proaktiv hantering.
• Om man frågar ”vad skrev du under förra kvartalet?” skulle svaret kräva att man söker igenom byggloggar manuellt, om dessa loggar och revisionsloggar överhuvudtaget finns.
• Signering är ett manuellt steg som utförs av en utvecklare när det är dags att förbereda en release och är inte integrerat i någon automatiserad pipeline.
• Det finns ingen plan för vad som händer om certifikatet komprometteras eller om utvecklaren som innehar signeringsnyckeln lämnar organisationen.

I detta skede är signeringsinfrastrukturen i princip oskyddad. Privata nycklar på programvaruåtkomliga platser är sårbara för alla angripare som når utvecklarens arbetsstation eller byggservern. Det finns ingen åtskillnad mellan uppgifter, samma person som skriver kod kan signera den utan någon oberoende granskning. Det finns ingen insyn i signeringshändelser, så obehörig signering skulle gå oupptäckt. Och eftersom det inte finns någon dokumenterad policy finns det inget att granska mot.

Det här är den miljö som angripare utnyttjade i SolarWinds- och 3CX-attacker. Inte sofistikerade nolldagsattacker mot kryptografiska algoritmer, utan obevakad åtkomst till signeringssteget i en oövervakad byggmiljö.

Steg 2: Definierad — Policyer finns, men luckor kvarstår

Organisationer i steg 2 har insett att ad hoc-kodsignering är en risk och har vidtagit åtgärder för att formalisera den. Det finns ett policydokument och nycklar lagras säkrare. Men rutinerna tillämpas inte konsekvent och det finns fortfarande brister, särskilt inom automatisering, revisionstäckning och hantering av certifikatlivscykeln. Detta steg har följande:

• Det finns en skriftlig policy för kodsignering som beskriver krav för nyckellagring, vem som är behörig att signera och hur certifikat ska hanteras. Efterlevnaden av policyn är dock inkonsekvent eftersom den upprätthålls genom medvetenhet och konventioner snarare än tekniska kontroller.
• Privata nycklar har flyttats från utvecklarmaskiner. Nycklar kan lagras på USB-hårdvarutokens som uppfyller FIPS 140-2 nivå 2, vilket uppfyller CA / Browser Forum krav men medför logistiska utmaningar, särskilt under den nya giltighetsperioden på 460 dagar för certifikat, där tokens måste bytas ut ungefär var 15:e månad.
• Det finns viss åtkomstkontroll där inte alla kan signera, och vissa certifikat är avsedda för specifika miljöer (utveckling kontra produktion). Denna kontroll är dock inte detaljerad och tillämpas inte på teknisk nivå, utan den förlitar sig på att utvecklare följer dokumenterade procedurer.
• Certifikatförteckning finns i någon form, till exempel ett kalkylblad, en delad kalenderpåminnelse eller ett ärende i ett projektledningssystem, men den underhålls manuellt och är benägen att bli föråldrad.
• Signering kan vara delvis integrerad i byggpipelines för vissa produkter, men manuella signeringssteg kvarstår för andra, särskilt äldre produkter eller produkter som hanteras av mindre team.
• Viss granskningsloggning finns där signeringshändelser kan registreras i byggloggar, men dessa är inte centraliserade, övervakas inte aktivt och används inte för att upptäcka avvikelser.

Den primära risken i steg 2 är gapet mellan policy och praktik. Policyer som inte tekniskt sett tillämpas är egentligen inte kontroller. När en policy säger att "nycklar inte får lagras på utvecklarnas arbetsstationer" men ingenting hindrar en utvecklare från att kopiera en nyckelfil till sin bärbara dator för enkelhetens skull, ger policyn falsk trygghet. På samma sätt är en åtkomstkontrollmodell som förlitar sig på att personer följer dokumenterade procedurer sårbar för både insiderhot och externa komprometter.

Steg 3: Hanterad — Centraliserad, kontrollerad och granskad

I steg 3 har kodsignering utvecklats från en dokumenterad policy till en tekniskt upprätthållen, centralt hanterad disciplin. Kontrollerna är inte bara nedskrivna; de implementeras i infrastruktur och system. Åtkomst styrs av RBAC som konfigureras och upprätthålls i en signeringsplattform med nycklar i HSM:er och inte i tokens. Den har också en omfattande och aktivt övervakad revisionslogg.

• Privata signeringsnycklar genereras inuti och lämnar aldrig FIPS 140-2 nivå 3-certifierade HårdvarusäkerhetsmodulerDen fysiska eller molnbaserade HSM hanteras av säkerhetsteamet och innehas inte av enskilda utvecklare. Nyckelexport är tekniskt inaktiverad på HSM-policynivå.
• En centraliserad signeringsplattform tillämpar rollbaserad åtkomstkontroll med utsedda roller med definierade behörigheter som styr vem som kan begära en signeringsåtgärd, vem som måste godkänna den och vilka artefakter som kan signeras med vilket certifikat.  
• Livscykelhanteringen för kodsigneringscertifikat är systematisk, med en inventering av alla signeringscertifikat, med utgångsdatum, tilldelade ägare och tillhörande produkter och pipelines, vilket underhålls i ett hanteringssystem, inte ett kalkylblad. Förnyelseaviseringar automatiseras och utlöses långt före utgångsdatumet.
• Signering är integrerad i CI/CD-pipelines för alla produktionsartefakter och är ett kontrollerat, policystyrt steg i releasepipelinen, inte ett manuellt steg som initieras av en utvecklare med RFC 3161-tidsstämpling som tillämpas konsekvent på alla signeringsåtgärder.
• Varje signeringshändelse genererar en oföränderlig granskningsloggpost som registrerar artefaktens hash, använt certifikat, tidsstämpel, begärande identitet och godkännandekedja. Loggarna är centraliserade, granskas aktivt och avvikande signeringshändelser genererar realtidsvarningar.
• Det finns en dokumenterad incidentplan för komprometterade signeringsnycklar, som täcker vilka nycklar som kan återkallas och ersättas via programvarumekanismer, vilka som kräver utbyte av hårdvara och hur tidslinjen för kommunikation och åtgärd ser ut.

I steg 3 är signeringsinfrastrukturen verkligen svår att missbruka. En angripare som komprometterar ett utvecklarkonto kan låsas och hindras från att utföra en signeringsåtgärd. Ett insiderhot som försöker signera en obehörig artefakt genererar en avvikelsevarning. Ett certifikat som närmar sig utgångsdatumet utlöser ett automatiserat förnyelsearbetsflöde snarare än att tyst löpa ut och orsaka ett produktionsfel. Med en korrekt revisionslogg kan alla historiska signeringshändelser granskas, spåras och undersökas.

Steg 4: Optimerad — Automatiserad, motståndskraftig och framtidsklar

Organisationer på denna nivå har inte bara implementerat starka kontroller, de har också byggt ett signeringsprogram som kontinuerligt förbättras, proaktivt anpassar sig till branschförändringar och är utformat för att förbli motståndskraftigt genom framtida utvecklingar, inklusive migrering efter kvantkryptografi och pågående regelutveckling.

• Signeringsinfrastrukturen är helt automatiserad där identifiering, förnyelse, distribution och återkallelse av certifikat hanteras av integrerade system utan manuell inblandning.
• Organisationen har implementerat kryptoagilitet i sin signeringsinfrastruktur. Migrering av algoritmer och nyckelstorlekar kan utföras över hela certifikatflottan utan att individuella pipeline-uppdateringar eller manuell omkonfiguration krävs.
• Post-quantum kryptografi signering är i produktion eller i aktiv pilotfas för artefakter med lång livscykel. NIST-slutförda algoritmer som ML-DSA (FIPS 204), SLH-DSA (FIPS 205), och LMS (NIST SP 800-208) som godkända post-kvantumsignaturalgoritmer.  
• Kodsigneringsprogrammet deltar i organisationens bredare säkerhetsramverk för leveranskedjan och integreras med generering av SBOM (Software Bill of Materials), spårning av binär proveniens och processer för sårbarhetshantering.
• Organisationen genomför regelbundna kontradiktoriska tester av sin signeringsinfrastruktur, såsom övningar med röda team som försöker kringgå RBAC-kontroller, introducera obehöriga signeringshändelser eller extrahera nyckelmaterial, för att validera att kontrollerna fungerar som utformade under realistiska attackförhållanden.
• Viktiga kompromisshanteringsplaner övas genom övningar, med dokumenterade återställningstidsmål för varje kategori av signeringsnyckel och certifikat.

I steg 4 skyddar signeringsprogrammet inte bara mot kända attackmönster, utan är också arkitekturmässigt motståndskraftigt mot kommande attacker. Den post-kvantövergång som kommer att kräva betydande infrastrukturarbete för de flesta organisationer i slutet av 2020-talet är redan igång. Regeländringar som kräver påvisbara bevis på efterlevnad, såsom NIST SSDF-attestering, revisionsloggar för federala programvaruavtal och sektorspecifika krav, kan uppfyllas från operativa data snarare än att kräva retroaktiv dokumentation.

Hur Encryption Consultings CodeSign Secure kan hjälpa till?

CodeSign Secure är Encryption Consultings centraliserade, policystyrda kodsigneringsplattform. Den är utformad för att stödja organisationer i varje steg av mognadsprocess och tillhandahåller den infrastruktur och de kontroller som behövs för att nå steg 3 och de avancerade funktioner som krävs för att uppnå steg 4.

CodeSign Secure ger organisationer som kommer från ad hoc- eller delvis definierade signeringsrutiner en omedelbar väg till de grundläggande kontroller som kännetecknar steg 3:

HSM-baserad nyckelhantering: Privata signeringsnycklar genereras inuti och lämnar aldrig FIPS 140-2 nivå 3-certifierade hårdvarusäkerhetsmoduler. CodeSign Secure integreras med Thales Luna, Entrust nCipher, Utimaco, Securosys och moln-HSM:er från AWS och Azure. Nyckelexport är inaktiverad på policynivå. USB-tokenmodellen och all dess förnyelselogistik och åtkomsthanteringsutmaningar ersätts av en centraliserad, API-åtkomlig signeringsinfrastruktur.

Förstärkta RBAC- och godkännandearbetsflöden: CodeSign Secures rollbaserade åtkomstkontrollmodell låter administratörer definiera exakt vem som kan begära en signeringsåtgärd, vad de kan signera, vilket certifikat som används och vilka auktoriseringssteg som måste matchas innan signeringen fortsätter. Dessa kontroller är programmatiskt framtvingade och är inte beroende av att personer följer dokumenterade procedurer.

Hantering av kodsigneringscertifikat: Plattformen upprätthåller en centraliserad inventering av alla certifikat som hanteras, med automatiska förnyelseaviseringar konfigurerade för att ge teamen tillräckligt med ledtid under den nya giltighetsperioden på 460 dagar.

För organisationer som redan har etablerat grundläggande kontroller och bygger mot optimering och steg 4:

CI/CD-pipelineintegration: CodeSign Secure integreras direkt med Azure DevOps , Jenkins , GitLab CI och andra större pipelinesystem. Signeringsåtgärder är API-drivna genom integration med tredjeparts signeringsverktyg med tillämpning av RFC 3161-tidsstämpling.

Stöd för postkvantkryptografi: CodeSign Secure v3.02 introducerar produktionsklart stöd för ML-DSA (FIPS 204, tillgängligt på säkerhetsnivåerna ML-DSA-44, ML-DSA-65 och ML-DSA-87) som avtagbara signaturer, vilket gör det möjligt för organisationer att påbörja PQC-övergången.

Granskningsloggning och rapportering: Varje signeringshändelse i CodeSign Secure genererar en oföränderlig loggpost som samlar in artefakt-hash, certifikat, tidsstämpel, begärande identitet och godkännandekedja. Loggar integreras med SIEM-plattformar som Splunk och Grafana Loki via Opentelemetry för realtidsdetektering av avvikelser.

Oavsett om du börjar från steg 1 och behöver etablera grundläggande kontroller snabbt, eller om du är i steg 3 och bygger mot full automatisering och post-kvantumberedskap, tillhandahåller CodeSign Secure infrastrukturen för att stödja den resan.

Slutsats

Kodsigneringsmognad är inte en destination utan en procedur att uppnå. Varje organisation befinner sig någonstans på resans gång, och varje förbättringssteg minskar risk och operativ exponering avsevärt.

På Encryption Consulting byggde vi CodeSign Secure för att göra den övergången praktisk i varje steg av resan. Frågan "är era kodsigneringsprocesser mogna?" har inte ett binärt ja- eller nej-svar. Men den har ett specifikt, handlingsbart svar: identifiera var ni befinner er, identifiera vilka komponenter som släpar efter mest och bygg en prioriterad färdplan för att täppa till luckorna.

År 2026 definieras brådskan i den färdplanen av branschutvecklingar, såsom 460-dagars certifikatgiltighet som gör manuell livscykelhantering ohållbar, attacker i leveranskedjan som fortsätter att utnyttja svag signeringsstyrning, NIST SSDF-krav som kräver påvisbara säkra utvecklingsmetoder och den kommande post-kvantumövergången som kommer att kräva infrastrukturförändringar som de flesta organisationer ännu inte har påbörjat.