Bästa praxis för kodsignering i SDLC

Modern programvara monteras, inte skrivs. En enda utgåva hämtar paket från öppen källkod, containerbaserade avbildningar, SDK:er från externa leverantörer och automatiserade byggpipelines. Var och en av dem är en potentiell ingångspunkt för en angripare. I den miljön är den digitala signaturen som är kopplad till en build ofta det sista verifierbara påståendet om att de bitar en användare kör är de bitar som din organisation faktiskt producerade.

Kodsignering är praxisen att koppla en kryptografisk digital signatur till en programvaruartefakt så att vem som helst kan verifiera vem som producerade den och bekräfta att den inte har ändrats. Disciplinen kring det, det vill säga hur nycklar genereras, skyddas, används och tas bort, avgör om kontrollen håller under attack.

Insatserna är inte teoretiska. Gartner förutspådde att 45 % av organisationer världen över skulle uppleva en attack mot mjukvaruleveranskedjan år 2025, en trefaldig ökning jämfört med 2021. Om något visade sig den prognosen vara konservativ. Verizons rapport om dataintrång från 2025 fann att tredje part var inblandad i ungefär 30 % av intrången, ungefär dubbelt så mycket som andelen som rapporterades ett år tidigare.

Den här bloggen fokuserar på hur kodsignering faktiskt fungerar, var den hör hemma i programvaruutvecklingslivscykeln (SDLC), den heltäckande processen genom vilken programvara planeras, byggs, testas, släpps och underhålls, samt bästa praxis för kodsignering.

Bästa praxis för kodsignering, definierade: uppsättningen kontroller, HSM-baserade icke-exporterbara nycklar, en centraliserad signeringstjänst, obligatorisk tidsstämpling, tvångsverifiering vid distribution, RBAC med M-of-N-godkännande och oföränderliga granskningsloggar, som håller en digital signatur som en pålitlig ursprungsförklaring snarare än en kontroll som en angripare kan stjäla eller dirigera runt.

Key Takeaways

• En giltig signatur bevisar ursprung, inte säkerhet. Incidenterna 3CX (2023) och NVIDIA (2022) visar två distinkta fellägen: en komprometterad byggpipeline som signerar skadlig kod med en äkta nyckel, och en stulen nyckel som signerar skadlig kod direkt.
• Sedan den 1 juni 2023 kräver CA/Browser Forum-regler att privata nycklar för kodsignering genereras och lagras utan export i en FIPS 140-2 Level 2+ (eller Common Criteria EAL4+) hårdvarumodul.
• Den här sidan är en checklista för bästa praxis för hela SDLC. För den djupgående, stegvisa CI/CD-implementeringsarkitekturen, OIDC-tjänstidentitet, dubbelsignering och verifieringsverktyg, se Stärka leveranskedjans säkerhet med SLSA nivå 3 och kodsignering.
• En signatur som ingen kontrollerar ger inget skydd; verifiering måste verkställas vid användningstillfället (distribution, åtkomstkontroll, bootloader), inte bara produceras vid byggtillfället.
• Tidsstämpling (RFC 3161) är det som håller en signatur giltig efter att dess certifikat har löpt ut; att hoppa över den innebär att en hel utgivningshistorik signeras på nytt varje gång ett certifikat upphör att gälla.

Hur kodsignering fungerar: Den kryptografiska förtroendekedjan

I grund och botten binder kodsignering en artefakt till en utgivares identitet med hjälp av asymmetrisk kryptografi. Signeringsverktyget beräknar en kryptografisk hash (en digest) av artefakten och omvandlar sedan den digesten med utgivarens privata nyckel för att skapa en digital signatur. Vem som helst kan verifiera resultatet med motsvarande publika nyckel genom att beräkna om hashen och bekräfta att ingenting har ändrats efter signeringen. Eftersom den privata nyckeln aldrig delas förblir verifieringen öppen medan signeringen förblir noggrant kontrollerad.

Den signaturen står inte fristående. Den paketeras med signerarens X.509-certifikat och kedjan av certifikat som leder tillbaka till en betrodd rot. De flesta signeringsformat, inklusive Microsoft Authenticode, Java JAR-signering och Apples kodsignaturer, bygger på Cryptographic Message Syntax (CMS, RFC 5652), IETF:s efterföljare till PKCS #7. Verifieraren går igenom den kedjan i linje med RFC 5280, kontrollerar giltighetsdatum, bekräftar att certifikatet har den utökade nyckelanvändningen för kodsignering och testar återkallningsstatus via en CRL eller OCSP.

En punkt förtjänar att betonas, eftersom den är roten till de mest skadliga incidenterna: en giltig signatur bevisar var en artefakt kommer ifrån, inte att artefakten är säker. Om en angripare stjäl den privata nyckeln eller komprometterar byggpipeline som matar signeraren, kommer signaturen att troget certifiera skadlig kod. Kodsignering säkerställer äkthet och integritet, och den är bara så tillförlitlig som nyckeln och pipeline bakom den.

Två ytterligare detaljer ställer till problem även för erfarna team. Den första är återkallelse. När en signeringsnyckel komprometteras måste certifikatet återkallas, men återkallelse skyddar bara verifierare som faktiskt kontrollerar det. Den andra är tidsstämpling. En betrodd tidsstämpel är en kontrasignatur från en tidsstämplingsinstans (RFC 3161) som registrerar när en signatur skapades. Utan den upphör varje signatur i praktiken att gälla samtidigt som certifikatet gör det, och det är sällan praktiskt att signera en hel tidigare katalog igen. Med den fortsätter programvara som signerades medan certifikatet var giltigt att verifiera långt efter att certifikatet har upphört att gälla. Haken, som senare incidenter visar, är att plattformar som försiktigt accepterar utgångna eller återkallade certifikat förvandlar den bekvämligheten till en lucka som kan utnyttjas.

Var kodsignering passar in i SDLC- och DevSecOps-pipelinen

Att veta hur kryptografi fungerar är bara halva bilden; var du placerar signering i utvecklingsprocessen avgör om dessa garantier faktiskt håller. Kodsignering är mest effektivt som ett steg i processen snarare än ett manuellt steg som läggs till före lansering. NIST:s Secure Software Development Framework behandlar skyddet av integriteten hos släppta artefakter som en kärnpraxis. Referensmönstret är enkelt att ange: bygg, signera, verifiera. Arkitekturen runt det är det som gör det hållbart.

Separera byggandet från signeringen. Byggsystemet ska inte innehålla signeringsnycklar. Det skickar en hash eller artefakt till en dedikerad signeringstjänst som kontrollerar nyckeln, tillämpar policy och returnerar en signatur. Det håller nycklar borta från CI-körningar, den del av pipelinen som är mest utsatt för beroenden och plugin-komprometteringar.

Signera endast det du har verifierat. Begränsa signeringsbehörigheten till artefakter som har klarat integritets-, proveniens- och säkerhetskontroller. Att signera en overifierad version utökar helt enkelt förtroendet till något du aldrig har validerat.

Verifiera på väg in, inte bara på väg ut. Framtvinga signaturverifiering vid driftsättning, till exempel en Kubernetes-admission controller som avvisar osignerade eller otillförlitliga avbildningar. En signatur som ingen kontrollerar ger inget skydd.

Ekosystemet har mognat kring dessa idéer. Leveranskedjans ramverk som SLSA definierar proveniensnivåer, in-toto-attesteringar samlar in verifierbara metadata om hur en artefakt byggdes, och nyckelfria metoder med mycket korta livslängder kopplade till OIDC-identiteter och registrerar signaturer i en offentlig transparenslogg, vilket krymper fönstret där en stulen bestående nyckel är användbar. Dessa metoder kompletterar, snarare än ersätter, signering av släppta binärfiler med certifikat. Ändå vilar de alla fortfarande på ett antagande, att själva signeringsnyckeln inte kan kopieras, och det är precis det antagandet som ett nyligen genomfört branschmandat syftade till att upprätthålla.

CA/Browser Forum HSM-mandatet: Vad som ändrades och varför det är viktigt

Den enskilt största operativa förändringen av offentligt betrodd kodsignering trädde i kraft den 1 juni 2023. Enligt CA/Browser Forums kodsigneringsgrundkrav måste privata nycklar för både organisationsvaliderings- (OV) och utökad validering (EV) kodsigneringscertifikat nu genereras och lagras i en hårdvarukryptomodul som är certifierad enligt minst FIPS 140-2 nivå 2 eller Common Criteria EAL 4+, och nyckeln måste markeras så att den inte kan exporteras.

Det är värt att notera att FIPS 140-2 nu i sig ersätts av den nyare FIPS 140-3. CMVP slutade acceptera nya FIPS 140-2-valideringsinlämningar i september 2021 som en del av övergången till FIPS 140-3. Befintliga FIPS 140-2-validerade moduler förblir acceptabla till och med den 21 september 2026, varefter de flyttas till den historiska listan och är i allmänhet endast avsedda för befintliga system snarare än nya upphandlingar.

Certifikatutfärdare verifierar detta, ofta genom fjärrnyckelatestering, innan certifikatet utfärdas. Motivet är direkt. Nycklar som finns i programvara kan kopieras, stjälas och återanvändas. Att tvinga in nycklar i hårdvara som motstår manipulering, där de inte kan exporteras, begränsar attackytan dramatiskt. Kostnaden är operativ komplexitet. När en nyckel finns inuti en HSM eller token och inte kan lämna den, måste varje signeringsoperation nå in i den hårdvaran. Den måste hanteras korrekt eftersom tokens inte skalas över distribuerade byggfarmar och en dåligt integrerad HSM blir en flaskhals.

Nyckelskydd, styrning och efterlevnad

Hårdvaruskydd är nödvändigt men inte tillräckligt. En signeringsnyckel i en HSM som vem som helst kan anropa är fortfarande en enda punkt med katastrofalt förtroende. Styrning är det som gör kontrollen meningsfull.

Åtkomstkontroll och separation av uppgifter. Använd åtkomstkontroller så att begäran, godkännande och utförande av en signeringsoperation är separata roller. Kräv dubbel kontroll eller kvorumgodkännande för dina viktigaste utgivningsnycklar så att ingen enskild person kan signera ensam.

Begränsade autentiseringsuppgifter som upphör att gälla snabbt. Begränsa vilka nycklar en given pipeline får använda och hur länge, och föredra tillfälliga signeringsidentiteter för CI framför bestående hemligheter.

Kompletta, oföränderliga revisionsloggar. Logga varje signeringshändelse centralt: vem som signerade, vilken artefakt, med vilken nyckel och när. Detta är både en detekteringskontroll och en evidensbas för ISO/IEC 27001-, SOC 2- och PCI DSS- revisioner.

En testad återkallnings- och rotationsplan. Vet i förväg hur du skulle återkalla en nyckel, meddela plattformsleverantörer och utfärda en ersättningsnyckel innan du behöver göra det.

NIST:s grundläggande vägledning, Cybersecurity White Paper Security Considerations for Code Signing, beskriver dessa arkitektoniska förväntningar och är fortfarande en användbar referens för att utvärdera en signeringslösning.

Stark styrning fortsätter att vara pålitlig mot de hot som organisationer står inför idag. Den svårare frågan är om algoritmerna bakom den fortfarande kommer att hålla när kvantberäkningar mognar, vilket är där framåtblickande planering börjar.

Kryptografisk smidighet och kvantberedskap

Kod som levereras idag, inklusive firmware, medicintekniska produkter, industriella styrenheter och företagsprogramvara som fortsätter att fungera i åratal, kan fortfarande köras när kraftfulla kvantdatorer kan bryta RSA- och elliptisk kurvkryptografi. Eftersom den koden måste verifieras mot nycklar som bäddats in år tidigare är kodsignering en av de första platserna där organisationer bör bygga kryptografisk flexibilitet.

Kryptografisk agilitet är förmågan att ändra de algoritmer ett system förlitar sig på utan att omkonstruera systemet runt dem. I ett signeringssammanhang innebär det att behandla signaturalgoritmen som ett konfigurerbart val snarare än en hårdkodad konstant: abstrahera den bakom en signeringstjänst eller ett gränssnitt, registrera i varje signatur och certifikat vilken algoritm som producerade den, och se till att verifierare kan acceptera mer än ett schema samtidigt. Agilitet låter en organisation introducera en ny algoritm, köra den tillsammans med den befintliga och ta bort den gamla enligt sitt eget schema, istället för att kämpa för att återuppbygga firmware.

I augusti 2024 slutförde NIST sina första standarder utformade för att motstå kvantdatorer: FIPS 204 (ML-DSA, en signatur baserad på gitterkryptografi) och FIPS 205 (SLH-DSA, en statslös signatur baserad på hashfunktioner).

Specifikt för signering av programvara och firmware godkände NIST även två tillståndskänsliga scheman baserade på hashfunktioner, LMS och XMSS, i specialpublikation 800-208 . Deras säkerhet beror endast på styrkan hos en hashfunktion, ett avsiktligt konservativt antagande, och deras tillståndskänsliga design gör dem väl lämpade för att signera ett begränsat, förutsägbart antal utgåvor.

De praktiska implikationerna är verkliga. Nycklarna och signaturerna som dessa algoritmer producerar är mycket större än ECDSA eller RSA, vilket påverkar firmwarelagring, uppdateringsbandbredd och verifieringstid, vilket jämförelsen nedan visar. Tillståndskänsliga scheman som LMS och XMSS kräver också noggrann tillståndshantering som överlever krascher, eftersom återanvändning av en engångsnyckel är katastrofalt, så de kräver dedikerat HSM-stöd och disciplinerad drift.

Ungefärliga storlekar på publika nycklar och signaturer, i byte:

Schema	Offentlig nyckel	namnteckning	Säkerhetsnivå
ECDSA P-256 (klassisk)	65	64	~128 bitar
RSA-2048 (klassisk)	256 (modulstorlek)	256	~112 bitar
ML-DSA-65 (FIPS 204)	1,952	3,309	NIST Nivå 3
SLH-DSA-128f (FIPS 205)	32	17,088	NIST Nivå 1

Storlekar definieras i FIPS 204 och FIPS 205.

Det kortsiktiga målet är inte att rippa och ersätta, utan att inventera var signeringsalgoritmer är fasta i koden, bekräfta HSM- och verktygsstöd, och designa för utbytbara eller hybridalgoritmer. NSA:s tidslinje för CNSA 2.0 gör signering av mjukvara och firmware till den tidigaste övergången av alla. Även om den endast binder National Security Systems och deras leverantörer, ber den dem att föredra de nya algoritmerna senast 2025 och använda dem uteslutande senast 2030, eftersom firmware-rötter av förtroende är de svåraste komponenterna att uppdatera efter driftsättning. En subtilitet är viktig för reglerade miljöer.

För signering av programvara och firmware godkänner CNSA 2.0 ML-DSA, LMS och XMSS för signering, men inte SLH-DSA, även om SLH-DSA också bygger på hashing. Dess statslösa hashbaserade signaturschema ger stark probabilistisk resistens men leder till oöverkomligt stora signaturstorlekar och prestandaflaskhalsar.

Exempel på arbetsflöde: Bygg till verifierad distribution

Sätt ihop de föregående avsnitten så följer en kompatibel version, i vilken SDLC som helst, samma allmänna sekvens. Detta är mönstret på den nivå som varje team bör implementera; för den fullt fungerande CI/CD-versionen med OIDC-baserad tjänstidentitet, dubbel klassisk/postkvantumsignering och specifika verifieringsverktyg, se Stärka leveranskedjans säkerhet med SLSA nivå 3 och kodsignering.

1. Byggnaden producerar en artefakt och dess innehållshash; byggmiljön innehåller aldrig en signeringsnyckel.
2. Integritet, proveniens och säkerhetsgrindar gäller för artefakten; endast artefakter som godkänns är berättigade till signering.
3. Pipelinen skickar hashen till den centraliserade signeringstjänsten med hjälp av en begränsad, kortlivad autentiseringsuppgift, inte en permanent hemlighet.
4. Signeringstjänsten kontrollerar RBAC och kräver, för produktionsnivåversioner, M-of-N-godkännande innan signeringsåtgärden utförs i HSM.
5. Signaturen returneras, bifogas artefakten och tidsstämplas (RFC 3161) så att den förblir verifierbar efter att certifikatet har löpt ut.
6. Signeringshändelsen, artefakt-hashen, nyckel-ID, godkännare och tidsstämpel skrivs till en oföränderlig, centralt lagrad logg.
7. Vid användningstillfället, distribution, åtkomstkontroll eller enhetsstart verkställs verifiering innan artefakten är betrodd, inte antas enbart utifrån närvaron av en signatur.

Vanliga fallgropar: Två lärdomar från verkliga incidenter

De flesta signeringsmisslyckanden faller inom en av två kategorier. Antingen stals nyckeln, eller så komprometterades pipelinen som matade signeraren. Två noggrant dokumenterade incidenter illustrerar varje kategori.

Stulna nycklar (NVIDIA, 2022). När Lapsus$-gruppen läckte två NVIDIA-kodsigneringscertifikat använde angripare dem för att signera skadlig kod, inklusive Cobalt Strike-beacons och fjärråtkomsttrojaner. Certifikaten hade redan löpt ut, men Windows accepterade dem fortfarande för drivrutinssignering, en påminnelse om att återkallelse och plattformsförtroendepolicyer är lika viktiga som själva nyckeln.

En komprometterad pipeline (3CX, 2023). Angripare bröt sig in i 3CX:s byggmiljö och trojanerade deras skrivbordsapp. Den skadliga versionen signerades med 3CX:s eget giltiga certifikat, och macOS-versionen notariserades till och med av Apple, vilket gjorde det möjligt för den komprometterade programvaran att klara förtroendekontroller och potentiellt nå 3CX:s kundbas på mer än 600 000 organisationer. Ingen nyckel stals och signaturen var äkta. Detta är den tydligaste möjliga demonstrationen av att en giltig signatur bevisar ursprung, inte säkerhet, och det visar varför byggpipelinen måste skyddas som ett av era känsligaste system.

De stödjande fellägena är bekanta: nycklar som förvaras på utvecklarens bärbara datorer eller i byggskript; signering utan tidsstämplar, så signaturer upphör tyst att gälla; ingen inventering av vilka nycklar och certifikat som finns eller när de upphör att gälla; och signering av tredjepartskod på förtroende. Var och en av dem vidgar tyst klyftan mellan "signerad" och "pålitlig". Den goda nyheten är att var och en av dem är undvikbara, och de bästa metoderna nedan visar hur man kan minska den klyftan.

Bästa praxis för kodsignering

De metoder som nämns nedan inkluderar: hur signeringsnycklar genereras och skyddas, hur signering styrs och verifieras, och hur schemat förblir flexibelt när algoritmer förändras. Betrakta dem som en baslinje för att mäta dina nuvarande kodsigneringsmetoder, inte en engångsinstallation.

1. Nycklar i hårdvara, ej exporterbara. Generera signeringsnycklar inuti HSM:erna och markera dem som ej exporterbara så att de aldrig kan lämna hårdvaran. Isolera nycklar per produktlinje eller betrodd domän på HSM-partitionsnivå, så att kompromettering av en nyckel aldrig låter en angripare signera för en annan.
2. Centralisera signering bakom en tjänst. Centralisera signering bakom en dedikerad tjänst som lagrar nycklarna, tillämpar policyer och endast returnerar en signatur. Håll privata nycklar borta från CI-användare, utvecklarbärbara datorer och byggskript, de delar av pipelinen som är mest utsatta för beroenden och plugin-komprometteringar.
3. Signera endast verifierade artefakter. Signera endast artefakter som har godkänts för integritet, proveniens och säkerhetsgrindar, och bifoga maskinverifierbar proveniens, såsom SLSA eller in-toto-attesteringar. Att signera en overifierad version utökar helt enkelt förtroendet för något du aldrig validerat.
4. Tidsstämpla varje signatur. Använd en RFC 3161-tidsstämpel för betrodda signaturer på varje signatur så att den fortsätter att verifieras långt efter att certifikatet har löpt ut. Utan tidsstämplar skulle du behöva gå tillbaka och signera om varje tidigare utgåva varje gång ett certifikat löper ut, vilket är opraktiskt när du har levererade produkter i flera år.
5. Verifiera vid användningstillfället. Framtvinga signatur- och policyverifiering vid användningstillfället, inte bara vid byggtillfället, oavsett om det är en Kubernetes-admissionskontroller som avvisar otillförlitliga avbildningar eller en bootloader som vägrar osignerad firmware. En signatur som ingen kontrollerar ger inget skydd.
6. Separation av arbetsuppgifter och godkännande från M-of-N. Gör begäran, godkännande och utförande av signeringsåtgärder till separata roller under RBAC, och kräv M-of-N (kvorum)-godkännande för produktions- och releasenycklar så att ingen enskild identitet kan både initiera och godkänna en signering. Håll själva åtkomstpolicyn versionsstyrd och granskningsbar.
7. Oföränderlig, detaljerad revisionslogg. Registrera varje signeringshändelse till enbart tilläggslagring som hålls separat från signeringsinfrastrukturen, och samla in artefakt-hash, nyckelidentifierare, certifikat, godkännandeidentitet och tidsstämpel. Detta är både en detekteringskontroll och evidensbasen för ISO/IEC 27001, SOC 2, PCI DSS och nyare system som EU. Cyberresilience Act.
8. Skydda byggpipelinen. Behandla bygg- och signeringspipelinen som ett av era känsligaste system, med härdade löpare, tjänstidentiteter med lägst privilegium och manipuleringssäker loggning. Som 3CX-intrånget visade, skickar en giltig signatur på en komprometterad build fortfarande skadlig kod.
9. Planera återkallelse och rotation. Dokumentera, automatisera och öva på hur du återkallar en nyckel, meddelar plattformsleverantörer och utfärdar en ersättningsnyckel innan en incident tvingar fram den. Där det passar, föredra kortlivade eller efemära signeringsidentiteter, där certifikatet bara är giltigt under en kort tid och den privata nyckeln kasseras direkt efter signering, så att det inte finns någon stående nyckel kvar att rotera, återkalla eller stjäla.
10. Bygg kryptografisk flexibilitet. Bygg kryptografisk flexibilitet för övergången efter kvantum: inventera där signaturalgoritmer är fixerade i kod (en CBOM hjälper), bekräfta HSM- och verktygsstöd för ML-DSA (FIPS 204) och de hashbaserade scheman i SP 800-208, och designa för utbytbara eller hybrida klassiska plus-PQC-signaturer. Långlivad firmware som levereras idag måste fortfarande verifieras mot algoritmer som motstår en framtida kvantdator, så migrera på CNSA 2.0-tidslinjen snarare än under deadlinepress.

Felhantering och återställning

En signeringsåtgärd bör misslyckas vid stängning: om godkännande inte beviljas, HSM inte kan nås, eller en obligatorisk gate inte godkänns, publiceras inte artefakten, signeras inte med en reservsökväg och skickas ändå. Återställning, när något som redan har skickats visar sig vara ett problem, är en annan åtgärd än återkallelse och de två förväxlas ofta. Återkallelse ogiltigförklarar certifikatet framöver; det tar inte bort artefakten som redan finns i fältet. Återställning innebär att man omdistribuerar den senast fungerande signerade versionen och, där plattformen stöder det, använder återställningsskydd (en monoton versionsräknare) för att säkerställa att den tidigare fungerande versionen fortfarande kan installeras om även efter att en nyare, komprometterad version har skickats. Planera för båda: ett certifikatproblem behöver återkallelse, en felaktig version behöver en återställningssökväg, och ingen av dem ersätter den andra.

Felsökning

Symptom	Troligtvis orsak	Vad ska man kontrollera
Signaturen visar giltig men artefakten misslyckas fortfarande med plattformens förtroendekontroller	Certifikatet saknar korrekt utökad nyckelanvändning, eller så bygger kedjan inte till en betrodd rot på den plattformen.	Bekräfta kodsignerings-EKU:n och validera hela kedjan mot målplattformens förtroendearkiv
Gamla utgåvor visas plötsligt som ogiltiga	Signeringscertifikatet har upphört att gälla och signaturerna var inte tidsstämplade	Lägg till RFC 3161-tidsstämpling framöver; redan skickade, ostämplade signaturer kan i allmänhet inte åtgärdas retroaktivt.
Ett redan återkallat certifikat verkar fortfarande fungera på vissa klienter	Verifieraren kontrollerar inte återkallelse (CRL/OCSP), eller cachade en inaktuell status	Bekräfta vilka av dina faktiska verifierare som kontrollerar återkallelse överhuvudtaget; anta inte att återkallelse tillämpas universellt.
Signeringsförfrågningar misslyckas intermittent under belastning	HSM- eller signeringstjänstdataflödesgränser, särskilt med större PQC-signaturer	Testa signeringsdataflödet under din verkliga algoritm och volym innan du förlitar dig på den under en lanseringsdag

Manuell kontra centraliserad signering: En snabb jämförelse

Aspect	Manuell/ad hoc-signering	Centraliserad signeringstjänst
Nyckelplats	Utvecklarens bärbara dator, byggskript eller USB-token	FIPS 140-2 Nivå 2+ HSM, ej exporterbar
Godkännande	Den som har nyckeln kan skriva under	RBAC med M-of-N-godkännande för produktionsnivåer
Verifieringskedja	Inkonsekvent eller frånvarande	Oföränderlig logg per signeringshändelse
Tidsstämpling	Ofta hoppade över	Tillämpas automatiskt på varje signatur
Beredskap för återkallelse	Ad hoc, upptäckt under en incident	Dokumenterad, inövad process

Hur krypteringskonsulting kan hjälpa

CodeSign Secure är Encryption Consultings plattform för kodsigneringshantering i företagsklass, utformad för att tillhandahålla de infrastrukturkontroller som branscher behöver.

HSM-baserad nyckelhantering

CodeSign Secure lagrar alla privata signeringsnycklar i FIPS 140-2 nivå 3-certifierade hårdvarusäkerhetsmoduler, som integreras med Thales Luna, Entrust nCipher, Utimaco, Securosys och molnbaserade HSM:er från AWS och Azure. Produktspecifik isolering av nyckeln sker på HSM-partitionsnivå: varje produktlinje får sin egen dedikerade nyckel, som genereras inuti hårdvaran och aldrig exporteras.

M-of-N-signeringsquorum och RBAC

Plattformens rollbaserade åtkomstkontrollmodell tillämpar krav på M-of-N-godkännande för signering av produktionsfirmware. Ingen enskild individ kan initiera och godkänna en signeringsoperation. Signeringsförfrågningar, godkännanden och avslag loggas alla. Själva RBAC-konfigurationen är granskningsbar och versionskontrollerad, vilket ger den dokumenterade signeringspolicy som CRA-överensstämmelsebedömningar kräver.

Oföränderlig granskningsloggning

Varje signeringshändelse i CodeSign Secure genererar en oföränderlig loggpost som registrerar artefaktens hash, nyckelidentifieraren, det använda certifikatet, den godkännande identiteten och RFC 3161-tidsstämpeln. Loggarna är centraliserade och lagras separat från signeringsinfrastrukturen.

Stöd för firmwareformat över flera plattformar

CodeSign Secure stöder signering av firmware-artefakter i alla format som en varierad produktportfölj kräver: .bin, .img, .hex, .fw, .dfu och .efi, vilket uppfyller CRA:s krav på konsekventa kontroller över produktlinjer utan att behöva bygga om signeringsinfrastrukturen för varje plattform.

Stöd för postkvantkryptografi

CodeSign Secure v3.02 stöder ML-DSA i produktionsklass (FIPS 204, på säkerhetsnivåerna ML-DSA-44, ML-DSA-65 och ML-DSA-87) och SLH-DSA (FIPS 205) som avtagbara signaturer vid sidan av klassiska algoritmer. För tillverkare som bygger produkter med CRA-supportskyldigheter på över fem år är PQC-signering idag den arkitektur som skyddar mot HNDL-hotet innan en CRQC anländer.

CI/CD Pipeline Integration

CodeSign Secure integreras med Azure DevOps , Jenkins , GitLab CI och andra större pipeline-plattformar via API- och kommandoradsgränssnitt. Firmware-signering är ett kontrollerat, policystyrt steg i byggpipelinen, inte ett manuellt steg.

Slutsats

Kodsignering är bedrägligt enkelt att beskriva och kräver expertvägledning för att fungera bra i stor skala. Kryptografin är den enkla delen. Kontrollens hållbarhet kommer från hur nycklar skyddas, hur signering vävs in i SDLC, hur verifiering upprätthålls och hur hela systemet styrs och förbereds för vad som kommer härnäst. Få rätt arkitektur, med nycklar som lagras i hårdvara, en centraliserad signeringstjänst, obligatorisk tidsstämpling, tvångsverifiering, stark styrning och en färdplan för kryptografisk flexibilitet, och en signatur blir ett pålitligt löfte snarare än en skuld som väntar på att bli stulen eller förfalskad.

Om er organisation omprövar hur den signerar och skyddar programvara under hela livscykeln är det värt att se över hur era nuvarande rutiner står sig i förhållande till dessa riktmärken och bestämma var de ska stärkas härnäst.

Vanliga frågor om partihandel med mat och dryck

Vad är skillnaden mellan återkallelse och rollback?

Återkallelse ogiltigförklarar ett certifikat framöver; det tar inte bort en redan levererad artefakt från fältet. Återställning innebär att den senast fungerande signerade versionen distribueras om. Ett komprometterat certifikat kräver återkallelse; en felaktig utgåva kräver en återställningssökväg. De löser olika problem och ingen ersätter den andra.

Spelar tidsstämplingen någon roll om mitt certifikat bara är giltigt i 460 dagar nu?

Det spelar större roll, inte mindre. Kortare certifikatgiltighet innebär att artefakter är mer benägna att kontrolleras efter att deras ursprungliga signeringscertifikat har löpt ut. En RFC 3161-tidsstämpel är det som gör att signaturen kan verifieras oavsett.

Är en giltig kodsignatur ett bevis på att en artefakt är säker?

Nej. En signatur bevisar ursprung och integritet sedan signeringen, inte säkerhet. 3CX-incidenten är det tydligaste exemplet: en byggpipeline komprometterades, och den resulterande skadliga programvaran signerades med 3CX:s eget giltiga certifikat och bestyrktes till och med av Apple.

Var ska jag vända mig för den detaljerade CI/CD-implementeringen, inte bara checklistan?

Se Stärka leveranskedjans säkerhet med SLSA nivå 3 och kodsignering för den fullständiga arkitekturen: OIDC-baserad tjänstidentitet, dubbel klassisk/postkvantumsignering och specifika verifieringsverktyg.

Ersätter efemära signeringsidentiteter behovet av en HSM?

Nej. En kortvarig signeringsidentitet begränsar hur länge en autentiseringsuppgift är giltig; själva den privata nyckeloperationen måste fortfarande ske inuti en icke-exporterbar, hårdvaruskyddad modul för att uppfylla kraven från CA/Browser Forum och för att motstå nyckelstöld.