Kodsignering – En chefsguide

Kodsignering kopplar en kryptografisk digital signatur till programvara, vilket verifierar vem som publicerade den och bekräftar att den inte har manipulerats sedan dess. Detta är viktigt eftersom programvarudistribution online, från mobilappar till företagsuppdateringar till paket med öppen källkod, inte tillhandahåller någon inbyggd autentisering: utan signering kan en användare inte skilja legitim programvara från en manipulerad kopia. Den rekommenderade åtgärden: lagra signeringsnycklar i en FIPS 140-2 nivå 2 eller högre HSM (obligatoriskt sedan juni 2023 enligt CA/Browser Forum), tidsstämpla varje signatur och hantera signeringsprocessen centralt snarare än att lämna den till enskilda utvecklare.

Snabbt svar: Vad är kodsignering och varför behöver chefer förstå det?

Kodsignering använder kryptografi med offentlig nyckel för att binda en programvaruartefakt till utgivarens identitet och för att skapa en manipuleringssäker försegling som upptäcker eventuella modifieringar efter signering. Den besvarar två frågor som användare och operativsystem annars inte kan besvara: kom denna programvara från den den påstår sig vara, och har den ändrats sedan den släpptes? Chefer måste förstå detta eftersom konsekvenserna av att göra fel är organisatoriska: en komprometterad signeringsnyckel ogiltigförklarar varje utgåva som organisationen någonsin har signerat, om ett komprometterat certifikat inte återkallas innebär det att angripare kan fortsätta signera skadlig programvara i organisationens namn, och IBM 2026 Cost of a Data Breach Report fann att den globala genomsnittliga kostnaden för intrånget nådde 4.99 miljoner dollar år 2026. Kodsignering är en av de direkta tekniska kontroller som förhindrar den specifika typen av intrång som orsakas av manipulerad eller personifierad programvara.

Hur blev kodsignering viktigt?

Tre konvergerande trender inom programvarudistribution skapade den miljö där kodsignering blev avgörande.

För det första ökade antalet företag som utvecklade och släppte programvara enormt, accelererat av smartphonerevolutionen och behovet för att varje organisation skulle ha sina egna applikationer. För det andra ersatte internetdistribution fysiska medier (CD-skivor, DVD-skivor) som den primära leveransmekanismen för programvara, vilket möjliggjorde storskalig nästan omedelbar distribution till försumbar kostnad men eliminerade den fysiska spårbarhetskedjan som gav användarna ett visst förtroende för programvarans äkthet. För det tredje ökade antalet oberoende programvaruleverantörer (ISV:er) som byggde programvaruapplikationer stadigt, med vissa forskningsrapporter som indikerar en tiofaldig tillväxt under det senaste decenniet.

Resultatet är att programvara nu färdas från utgivare till användare via kanaler där vem som helst kan fånga upp, modifiera och omdistribuera den. Kodsignering åtgärdar detta genom att tillhandahålla kryptografiskt bevis på både utgivarens identitet och programvarans integritet, vid nedladdnings- och installationstillfället, utan att användarna behöver lita på själva distributionskanalen.

Leveranskedjans dimension har gjort detta mer brådskande: Sonatypes rapport om tillståndet i programvarans leveranskedja för 2026 identifierade mer än 454 600 nya skadliga paket med öppen källkod under 2025, en ökning med 75 % jämfört med föregående år. Tredjeparts inblandning i dataintrång fördubblades från 15 % till 30 % på ett enda år enligt Verizons rapport om dataintrångsinvestigationer för 2025. Kodsignering är den kontroll som låter konsumenter nedströms verifiera att ett paket faktiskt kom från dess påstådda utgivare oförändrat, vilket är just den förtroenderelation som angripare i leveranskedjan utnyttjar.

Hur kodsignering fungerar

Koden i kodsignering kan betyda körbara filer, arkiv, drivrutiner, firmware, bibliotek, paket och i princip all programvara avsedd för utgivning och distribution. För att förstå hur kodsignering fungerar är det bra att ha en grundläggande förståelse för Public Key Infrastructure (PKI) , vilket är den uppsättning roller, policyer, hårdvara, programvara och procedurer som används för att skapa, hantera, distribuera, använda, lagra och återkalla digitala certifikat.

Kodsignering har två huvudsakliga mål: kodägande (att bevisa att programvaran kommer från dess autentiska utgivare) och kodintegritet (att bevisa att koden inte har manipulerats). Fyrstegsprocessen som uppnår båda:

1. Nyckelgenerering: en privat nyckel och motsvarande publika nyckelpar genereras. Den privata nyckeln måste lagras i en HSM (se avsnittet om nyckelhantering nedan) och aldrig exporteras i användbar form.
2. Kodsigneringscertifikat: ansök om ett kodsigneringscertifikat från en betrodd Certifikatmyndighet (CA)Certifikatet inkluderar organisationens identitet, den publika nyckeln, giltighetsperioden och CA:ns digitala signatur. Sedan juni 2023 kräver offentligt betrodda kodsigneringscertifikat att den privata nyckeln lagras i FIPS 140-2 nivå 2 eller högre hårdvara.
3. Hashing: Programvaruartefakten skickas genom en hashfunktion som producerar ett hashvärde med fast längd som representerar artefaktens innehåll. Varje ändring av artefakten, även en enda bit, producerar ett helt annat hashvärde. SHA-256 är den nuvarande minimumstandarden; SHA-1 och MD5 är föråldrade och får inte användas.
4. Signering: Hashvärdet krypteras med den privata nyckeln, vilket producerar den digitala signaturen. Signaturen, tillsammans med kodsigneringscertifikatet, medföljer programvarupaketet för distribution. Den ursprungliga programvaran är inte krypterad; endast den lilla hashen signeras, vilket gör processen snabb och effektiv.

Guide för val av algoritm och protokoll

Komponent	Rekommenderad	Minsta acceptabla	Föråldrad/undvik	Anmärkningar
Hash-algoritm	SHA-256 eller SHA-384	SHA-256	SHA-1, MD5	SHA-1 är föråldrat av NIST och avvisat av de flesta plattformar; MD5 har kända kollisionsattacker
Signeringsalgoritm	RSA-3072 eller ECDSA P-256	RSA-2048 (upphör att gälla enligt NIST IR 8547 efter 2030)	RSA-1024, DSA-1024	ECDSA P-256 ger motsvarande säkerhet som RSA-3072 med mindre nyckel- och signaturstorlekar
Nyckelförvaring	FIPS 140-2 Nivå 2 eller Nivå 3 HSM	FIPS 140-2 Nivå 2 (obligatorisk enligt CA/B-forumet sedan juni 2023)	Programvarunyckellager, privata nycklar för filsystem	CA/Browser Forum kräver hårdvarulagring för alla offentligt betrodda kodsigneringscertifikat
Tidsstämpel	RFC 3161-tidsstämpel från en betrodd TSA	RFC 3161 tidsstämpel	Ingen tidsstämpel	Utan tidsstämpel upphör signaturens giltighetstid när certifikatet går ut
Postkvantum (planeringshorisont)	ML-DSA (FIPS 204) för ny långlivad signeringsinfrastruktur	Nuvarande ECDSA/RSA väntar på PQC-övergång	RSA-2048 ensamt för ny infrastruktur (kvantsårbar efter 2030)	NIST IR 8547 föreslår att klassiska asymmetriska algoritmer avvecklas efter 2030.

Vad händer när programvaran laddas ner

När en användare laddar ner signerad programvara sker verifieringsprocessen automatiskt i webbläsaren eller operativsystemet:

1. Webbläsaren eller operativsystemet kontrollerar att kodsigneringscertifikatet kommer från en betrodd certifikatutfärdare (rotcertifikat från certifikatutfärdare är förinstallerade i webbläsare och operativsystem). Om certifikatet inte kommer från en betrodd certifikatutfärdare visar operativsystemet en varning och kan blockera installationen.
2. Den offentliga nyckeln extraheras från certifikatet och används för att dekryptera den digitala signaturen, vilket återställer det ursprungliga hashvärdet.
3. Den nedladdade programvaran (exklusive certifikatet och signaturen) hashas igen med samma algoritm.
4. De två hashvärdena jämförs. Om de matchar är programvaran autentisk och omodifierad. Om de inte matchar (eftersom en angripare modifierade programvaran efter signering) varnar operativsystemet användaren och vägrar installationen.

Bästa metoder för kodsignering

1. Lagra privata nycklar i en HSM: d HSM tillåter inte export av privata kryptografiska nycklar. Enligt CA/Browser Forums krav från juni 2023 är en FIPS 140-2 nivå 2 (eller högre) certifierad HSM nu obligatorisk för alla offentligt betrodda kodsigneringscertifikat.
2. Begränsa åtkomst till privata nycklar: Endast personal eller automatiserade system med ett specifikt, dokumenterat behov ska kunna utlösa en signeringsoperation. Varje signeringshändelse ska generera en granskningsloggpost som inkluderar vem eller vad som utlöste den, när och vilken artefakt som signerades.
3. Alltid tidsstämpla signerad kod: En RFC 3161-tidsstämpel från en betrodd tidsstämplingsauktoritet (TSA) binder signeringshändelsen till en viss tidpunkt. Detta gör att signaturen förblir verifierbar efter att signeringscertifikatet har löpt ut eller återkallats, så länge certifikatet var giltigt vid signeringstillfället.
4. Använd separata nycklar per produktlinje: Att använda en nyckel för alla produkter innebär att en kompromiss med den nyckeln ogiltigförklarar signeringsförtroendet för varje produkt som organisationen någonsin har släppt. Separata nycklar per produktlinje, och helst per större utgåva, begränsar explosionsradien för en kompromiss med nyckeln.
5. Centralisera signeringshanteringen: Ad hoc-signering av enskilda utvecklare med lokalt lagrade nycklar ger ingen insyn, granskningsbarhet eller policytillämpning. En centraliserad signeringsplattform upprätthåller en konsekvent policy för alla produkter och team och tillhandahåller den revisionslogg som krävs för efterlevnad och incidentutredning.

Kodsignering för säkerhet i programvaruleveranskedjan

När en privat nyckel komprometteras förlorar certifikatet sitt förtroende, vilket förstör äktheten och integriteten hos all programvara som signerats med den nyckeln. Den risk i leveranskedjan som detta åtgärdar är betydande: Sonatypes rapport om tillståndet i programvarans leveranskedja från 2026 identifierade mer än 454 600 nya skadliga paket med öppen källkod under 2025 (en ökning med 75 % jämfört med föregående år), och tredjepartsinblandning i intrång fördubblades från 15 % till 30 % enligt Verizons DBIR för 2025.

För säkerhet i leveranskedjan är två kontroller utöver grundläggande signering avgörande:

1. Autentisera koden innan signering: organisationer bör integrera inloggning i CI / CD-rörledningar med godkännandegrindar som förhindrar att skadlig eller icke-godkänd kod når signeringssteget. Efter signering bör artefakter verifieras mot signaturen före distribution. Alla signeringshändelser måste loggas för senare granskning.
2. Återkalla komprometterade certifikat omedelbart: Om en privat nyckel misstänks vara komprometterad måste den utfärdande certifikatutfärdaren omedelbart återkalla certifikatet. Återkallelsen kommunicerar till alla förlitande parter att certifikatet inte längre ska vara tillförlitligt. Fördröjd återkallelse innebär att angripare kan fortsätta att signera skadlig programvara i organisationens namn medan certifikatet är giltigt.

Kodsignering i molnbaserade och CI/CD-miljöer

Kodsignering är avgörande i molnbaserade distributioner. Containeravbildningar, applikationsbinärfiler och Kubernetes-distributionsmanifest kräver alla signering för att upprätta en betrodd artefaktkedja från byggfas till distribution. I molnbaserade miljöer är signering integrerad med CI/CD-pipelines så att varje artefakt som produceras av pipelinen signeras automatiskt i byggfasen, inte som ett manuellt steg efter byggfasen.

Ett nyare mönster är nyckelfri signering, populariserat genom Sigstore-projektet med öppen källkod. Istället för att en administratör provisionerar och roterar långlivade certifikat för varje pipeline, utfärdar nyckelfri signering ett kortlivat certifikat kopplat till en OIDC (OpenID Connect)-identitet, till exempel en CI/CD-arbetsbelastningsidentitet, vid signeringstillfället, och kasserar sedan den privata nyckeln helt. Signaturen och en offentlig post loggas i en transparent ledger istället för att förlita sig på ett certifikat som måste spåras, förnyas och återkallas under månader eller år.

Traditionell PKI-baserad signering kontra nyckelfri signering (Sigstore-liknande)

Aspect	Traditionell PKI-baserad signering	Nyckelfri signering (Sigstore-stil)
Nyckellivslängd	Långlivad (vanligtvis 1–3 år), måste hanteras aktivt	Tillfällig; utfärdad per signeringshändelse, sedan kasserad
Nyckelförvaring	HSM eller hårdvarutoken (obligatoriskt sedan juni 2023)	Ingen permanent privat nyckel att lagra
Identitetsbindning	Organisationsidentitet verifierad av en CA vid utfärdande	Arbetsbelastnings-/OIDC-identitet verifierad vid signeringstillfället
Återkallande	Manuell återkallelseprocess för certifikatutfärdare om den är komprometterad	Inte tillämpligt; en komprometterad, tillfällig nyckel upphör att gälla nästan omedelbart.
Bäst för	Levererad skrivbordsprogramvara, drivrutiner och installationsprogram som kräver långsiktig giltighetstid för signaturer	CI/CD-pipelines, containeravbildningar, molnbaserade artefakter signeras ofta

De flesta företag använder båda modellerna: traditionella certifikat för levererade, långlivade binärfiler och nyckelfri eller kortlivad signering för högfrekventa artefakter som rör sig genom CI/CD-pipelines.

Implementeringsexempel

Version av Windows-skrivbordsprogrammet: utvecklaren skickar en version till signeringspipelinen. CodeSign Secure hashar den körbara filen, skickar hashen till HSM för RSA-3072-signering, hämtar den signerade hashen, tillämpar en RFC 3161-tidsstämpel från TSA och paketerar certifikatet, signaturen och tidsstämpeln med den distribuerbara filen. Hela processen sker inuti pipelinen utan att den privata nyckeln någonsin lämnar HSM. När användare laddar ner installationsprogrammet verifierar Windows SmartScreen certifikatkedjan mot betrodda rötter och bekräftar hashmatchningarna innan installationen tillåts.

Signering av containeravbildningar i en Kubernetes-miljö: efter att en containeravbildning har byggts och skickats till registret anropar CI/CD-pipelinen CodeSign Secure för att signera avbildningssammanfattningen med organisationens ECDSA P-256-nyckel som lagras i HSM. Den signerade avbildningssammanfattningen och certifikatet lagras i registret tillsammans med avbildningen. Kubernetes-åtkomstkontroller (som OPA Gatekeeper eller Kyverno) är konfigurerade för att verifiera signaturen innan någon container tillåts distribueras i produktion, vilket avvisar avbildningar som inte signerades av organisationens nyckel.

Paketutgivning med öppen källkod och nyckelfri signering (Sigstore): paketansvarigs GitHub Actions-utgivningsarbetsflöde utlöser Sigstores cosign-verktyg, som begär ett kortlivat certifikat från Sigstores Fulcio CA kopplat till GitHub Actions OIDC-identiteten för utgivningsarbetsflödet. Paketet signeras med den efemära nyckeln, den privata nyckeln kasseras omedelbart och signaturen registreras i Sigstores Rekor-transparenslogg. Nedströmskonsumenter använder cosign verify för att kontrollera signaturen mot Rekor-loggen och bekräfta att paketet signerades av det legitima utgivningsarbetsflödet vid den specifika commiten.

Hur CodeSign Secure hjälper chefer att kontrollera denna risk

Chefer behöver inte själva hantera kryptografin, men de behöver en plattform som tillämpar ovanstående bästa praxis utan att förlita sig på enskilda utvecklare för att komma ihåg dem. Encryption Consultings CodeSign Secure gör detta genom att signera varje artefakt i en HSM så att privata nycklar aldrig lämnar hårdvaran, tillämpa rollbaserad åtkomstkontroll så att endast behöriga användare kan utlösa en signeringshändelse och logga varje signeringsåtgärd för den revisionslogg som ovanstående bästa praxis kräver.

CodeSign Secure använder även klientsidig hashning, så filen som signeras lämnar aldrig kundens miljö i ett oskyddat tillstånd, och varje signatur tidsstämplas för att förhindra problemet med att programvarusignaturer löper ut när certifikatet gör det. För team som hanterar både levererade binärfiler och CI/CD-pipelines tillhandahåller CodeSign Secure en centraliserad plattform som täcker både traditionell HSM-baserad signering och integration med moderna pipeline-signeringsarbetsflöden, snarare än att kräva en separat manuell process för varje artefakttyp.

Begränsningar av kodsignering

• Kodsignering verifierar integritet och identitet, inte korrekthet: En signerad artefakt bevisar att den kommer från dess påstådda utgivare i oförändrad form. Den bevisar inte att koden är fri från sårbarheter, bakdörrar eller skadlig logik som fanns före signeringen. En utvecklare kan signera skadlig kod som de själva skrev. Kodsignering och säkerhetstestning av applikationer tar upp olika hotkategorier.
• Den viktigaste kompromissen är katastrofal och svår att begränsa: Om en privat nyckel för signering komprometteras är varje artefakt som någonsin signerats med den nyckeln misstänkt. Återkallelse kommunicerar misstro mot förlitande parter, men artefakter som redan är installerade på användarsystem förblir signerade. Konsekvensen är varför nyckelhantering, HSM-lagring och åtkomst till signeringsåtgärder med minsta möjliga behörighet är så viktiga.
• Återkallningskontrollen har luckor: Återkallelse av certifikat fungerar bara om förlitande parter faktiskt kontrollerar återkallningsstatusen. OCSP-häftning och CRL-distribution förbättrar täckningen, men vissa plattformar och miljöer utför inte återkallningskontroller tillförlitligt. Detta innebär att ett återkallt certifikat kan fortsätta att accepteras i miljöer som inte kontrollerar återkallelser.
• Nyckelfri signering är beroende av transparenslogginfrastrukturen: Nyckelfri signering med Sigstore flyttar förtroendet till Rekors transparenslogg och Fulcio CA. Dessa är nya infrastrukturkomponenter med sina egna tillgänglighets- och förtroendekrav. Organisationer som använder nyckelfri signering för kritiska artefakter bör förstå dessa beroenden.

Slutsats

Kodsignering är en viktig del av programvaruutvecklingens livscykel, och landskapet kring den har förändrats avsevärt de senaste åren. HSM-lagring är nu obligatorisk, inte valfri, för offentligt betrodda certifikat. Attackytan i leveranskedjan har expanderat dramatiskt. Och nya signeringsmodeller, inklusive nyckelfri signering och pipeline-integrerad signering, förändrar hur organisationer närmar sig artefaktförtroende i stor skala.

För chefer är de viktigaste besluten organisatoriska: vem kontrollerar signeringsnycklar, vilken åtkomst som kontrollerar gatesigneringshändelser, hur signering granskas och hur organisationen reagerar när en nyckel komprometteras. Dessa är styrningsbeslut lika mycket som tekniska, och de kräver samma noggrannhet som tillämpas på alla andra privilegierade system i organisationen. Om du vill bedöma din nuvarande kodsigneringssituation eller integrera signering i dina CI/CD-pipelines med HSM-baserade nyckelskydd, kontakta Encryption Consulting för att diskutera var du ska börja.

Vanliga frågor om partihandel med mat och dryck

Vilka är de två huvudmålen med kodsignering?

Kodägande, vilket bevisar att programvaran kommer från dess påstådda utgivare, och kodintegritet, vilket bevisar att den inte har ändrats sedan den signerades. Allt annat i en kodsigneringsprocess finns för att stödja ett av dessa två mål.

Vilka är de fyra stegen i kodsigneringsprocessen?

Nyckelgenerering, erhållande av ett kodsigneringscertifikat från en certifikatutfärdare, hashning av koden och signering av hashen med den privata nyckeln. Den signerade hashen och certifikatet följer sedan med programvarupaketet.

Varför måste privata nycklar för kodsignering lagras i en HSM?

En hårdvarusäkerhetsmodul förhindrar att den privata nyckeln någonsin exporteras i användbar form, vilket är precis vad en angripare behöver för att signera skadlig kod på ett övertygande sätt. Sedan den 1 juni 2023 har CA/Browser Forum gjort lagring av hårdvarunycklar obligatorisk för alla offentligt betrodda kodsigneringscertifikat.

Vad händer om den privata nyckeln för ett kodsigneringscertifikat komprometteras?

Certifikatet förlorar helt sitt förtroende. Varje mjukvara som någonsin signerats med den nyckeln blir misstänkt, vilket är anledningen till att certifikatutfärdaren måste återkalla det komprometterade certifikatet omedelbart och varför säkerhetsteam rekommenderar att man roterar signeringsnycklar snarare än att återanvända en nyckel över många produktlinjer.

Hur mycket kostar ett genomsnittligt dataintrång, och varför spelar det roll för kodsignering?

Den globala genomsnittliga kostnaden för ett dataintrång nådde 4.99 miljoner dollar år 2026, en ökning med 12 % jämfört med föregående år, enligt IBMs rapport om kostnaden för ett dataintrång från 2026. Kodsignering är en av de direkta kontrollerna som förhindrar den specifika typen av dataintrång som orsakas av manipulerad eller personifierad programvara.

Varför är kodsignering särskilt viktigt för säkerhet i programvaruleveranskedjan?

Sonatype identifierade över 454 600 nya skadliga paket med öppen källkod under 2025, en ökning med 75 % jämfört med föregående år, och inblandningen av tredjepartsintrång fördubblades till 30 % enligt Verizon 2025 DBIR. Kodsignering låter nedströmsanvändare verifiera att ett paket kom från dess påstådda utgivare oförändrat, vilket är precis det förtroende som angripare i leveranskedjan utnyttjar.

Vad är skillnaden mellan traditionell PKI-baserad kodsignering och nyckelfri signering?

Traditionell signering använder ett långsiktigt certifikat som lagras i en HSM, förnyas och återkallas via CA. Nyckellös signering utfärdar ett tillfälligt certifikat som är kopplat till en arbetsbelastningsidentitet vid signeringstillfället och kasserar nyckeln omedelbart, vilket byter ut långsiktig nyckelhantering mot utfärdande per händelse via en transparenslogg.

Spelar tidsstämplingen någon roll om mitt kodsigneringscertifikat går ut?

Ja. Utan en tidsstämpel upphör en signaturs giltighetstid tillsammans med certifikatet. En RFC 3161-tidsstämpel gör att signerad kod kan fortsätta att verifieras som autentisk även efter att det ursprungliga certifikatet inte längre är giltigt, så länge certifikatet var giltigt vid tidpunkten för signeringen.

Hur passar kodsignering in i CI/CD och molnbaserade miljöer?

Kodsignering byggs in direkt i pipelinen snarare än att tillämpas som ett manuellt sista steg, vilket signerar containeravbildningar och binärfiler automatiskt allt eftersom de byggs. Många molnbaserade team kombinerar traditionell HSM-baserad signering för långlivade binärfiler med nyckelfri eller kortlivad signering för högfrekventa pipeline-artefakter.

Hur hjälper CodeSign Secure chefer att kontrollera risken vid kodsignering.

Den signerar varje artefakt i en HSM så att nycklar aldrig lämnar hårdvaran, tillämpar rollbaserad åtkomstkontroll över vem som kan utlösa en signeringshändelse, tidsstämplar varje signatur och loggar varje åtgärd för granskningsändamål, vilket omvandlar de bästa metoderna i den här guiden till påtvingat plattformsbeteende.