Vi räknade alla format CodeSign Secure Can Sign

Fråga en releaseingenjör hur många signeringsverktyg deras organisation använder och se dem faktiskt stanna upp och räkna på sina fingrar. Signtool för Windows-installationsprogrammet. Jarsigner för den enda Java-tjänsten ingen vill röra. Vad mobilteamet än kopplade upp för APK:er. En GPG-nyckel som någon konfigurerade för Debian-arkivet för tre ingenjörer sedan, och ingen är helt säker på vem som fortfarande har den. Det är inte hypotetiskt. Det är det genomsnittliga signeringsavtrycket på alla företag som har levererat programvara över mer än en plattform i mer än två år, och det är anledningen till att kodsignering fortsätter att hamna i incidenter efter kod som inte har något att göra med själva koden.

Här är den del som gör detta brådskande just nu istället för "någon gång": CA/Browser Forums omröstning CSC-31 sänkte just den maximala giltigheten för offentligt betrodda kodsigneringscertifikat från 39 månader till 460 dagar, med verkan från och med den 1 mars 2026. Varje spridd signeringsnyckel en organisation har, varje USB-token som ligger i en låda, varje certifikat som ingen minns att de utfärdat, behöver nu beröras ungefär tre gånger så ofta som det gjorde för arton månader sedan. Fragmenterad signering var inte en bra idé innan den omröstningen gick igenom. Det är en operativ belastning nu.

Så vi vill besvara frågan vi får i nästan varje CodeSign Secure-utvärderingssamtal för en företagskodsigneringslösning: "okej, men täcker det verkligen vår stack?" Nedan följer det ärliga, specifika svaret, format för format, med tillräckligt med tekniska detaljer så att du kan kontrollera det mot din egen releasepipeline snarare än att lita på vårt ord.

Lösning för företagskodsignering, definierad som: en centraliserad plattform som genererar och lagrar privata signeringsnycklar inuti HSM-baserad hårdvara, tillämpar rollbaserad signering med flera godkännare för varje signeringsförfrågan och producerar giltiga signaturer i alla format som en organisation levererar, snarare än att varje team måste signera med sina egna lokala nycklar och verktyg.

Key Takeaways

• CodeSign Secure signerar i över 20 format, Windows, Apple, Java/Android, Linux, molnbaserade, PKCS#11-förpackade och post-quantum, från en enda FIPS 140-2 Level 3 HSM-baserad plattform.
• En RBAC-modell och ett M-of-N-godkännandearbetsflöde styr varje signeringsförfrågan, oavsett format.
• CA/Browser Forum-omröstningen CSC-31 förkortade giltigheten för certifikat för offentlig kodsignering från 39 månader till 460 dagar, med verkan från och med den 1 mars 2026, vilket tredubblar hur ofta spridda signeringsnycklar behöver utfärdas på nytt.
• CodeSign Secure stöder avtagbara postkvantumsignaturer (ML-DSA, LMS) tillsammans med klassisk RSA/ECDSA-signering på samma artefakt, så PQC-implementering är additiv, inte en rip-and-ersätt-migrering.
• Distributionsalternativen inkluderar lokala, molnbaserade och hybrida HSM-modeller; se avsnitten Förutsättningar och Kända begränsningar längre ner innan du utvärderar.

Den korta versionen

CodeSign Secure signerar mer än 20 olika format från en HSM-baserad plattform: Windows-binärfiler och skript (Signtool, JSign, PowerShell, Appx/MSIX, ClickOnce via Mage, NuGet, HLK/HCK-drivrutinssignering), Apple-binärfiler, Java- och Android-artefakter (jarsigner, JSign, APK), Linux- och öppen källkodspaket (OpenSSL, XML, GPG2, Debian, RPM), molnbaserade artefakter (containrar, OVA/OVF, firmware), reproducerbara builds, PKCS#11-inlindad HSM-signering och avtagbara post-kvantumsignaturer (ML-DSA, LMS). En rollbaserad åtkomstkontrollmodell (RBAC) och ett M-of-N-godkännandearbetsflöde styr allt. Den sista delen är själva poängen, inte formatantalet. En plattform som signerar tjugo format genom tjugo olika förtroendegränser har inte löst fragmenteringsproblemet; den har bara gett den en längre funktionslista.

Vill du se hela kartan innan detaljerna? Här är den.

Kategori	Format/verktyg som omfattas	Filändelser
Windows	Signtool (Authenticode), JSign, PowerShell-skript, Appx/MSIX-paket, ClickOnce-manifest (Mage/Mage UI), NuGet-paket, HLK/HCK-certifierade drivrutiner	.exe, .dll, .sys, .msi, .cab, .ps1, .appx/.msix, .application, .nupkg
Apple	macOS-, iOS- och watchOS-applikationer	.app, .ipa
Java och Android	JAR-filer (jarsigner), plattformsoberoende Authenticode via JSign, APK-paket	.jar, .apk
Linux och öppen källkod	OpenSSL-baserad signering, digitala XML-signaturer, GPG2, Debian-paket, RPM-paket	.rpm, .deb, .xml, .asc/.sig
Molnbaserad och infrastruktur	Container-/OCI-avbildningar, OVA/OVF-virtualiseringsfiler, firmware-avbildningar	N/A (innehållssammanfattning), .ova/.ovf, binärfiler för firmware
Försörjningskedjans integritet	Reproducerbara byggen	N/A (byggattestering, inte en enda filtyp)
Efterkvantum	PQC-avtagbara signaturer (ML-DSA, LMS)	.sig (fristående)
Hårdvaruinteroperabilitet	PKCS#11-omslagssignering för tredjeparts- och äldre verktyg	N/A (protokollnivå, inte filspecifik)

Nu ska vi gå igenom vad som egentligen ligger bakom varje rad, för ”vi stöder X” betyder ingenting utan ”varför det är viktigt” kopplat till det.

Windows: Där de flesta signeringsprogram föds, och där de flesta av dem stannar

Om din organisation signerar något, började det nästan säkert med Windows, och det är oftast där spridningen också börjar. Microsofts signtool.exe är referensverktyget för Authenticode-signering, det schema som Windows använder för att lita på PE-filer: .exe, .dll, .sys, .msi, .cab och katalogfiler. Haken är att Signtool bara körs på Windows, och i samma sekund som din byggpipeline inkluderar en Linux-container eller en blandad CI/CD-flotta, slutar det att vara ett mindre besvär och börjar bli anledningen till att någon håller en ensam virtuell Windows-maskin vid liv bara för att signera saker. JSign, ett plattformsoberoende Authenticode-verktyg med öppen källkod skrivet i Java, finns specifikt för att täppa till det gapet, och CodeSign Secure använder det som en av sina signeringsmotorer så att Linux- och macOS-byggagenter kan producera giltiga Authenticode-signaturer utan att någonsin starta den virtuella maskinen. Den privata nyckeln finns kvar i en FIPS 140-2 Level 3 HSM hela tiden, oavsett om begäran kommer in via Signtool eller via JSign.

PowerShell-skript får samma behandling. Om din exekveringspolicy kräver en giltig Authenticode-signatur på varje .ps1-fil (vilket den borde), signerar CodeSign Secure dessa skript via HSM och gör dem verifierbara med ett vanligt Get-AuthenticodeSignature-anrop, utan att någon signeringsnyckel någonsin rör vid maskinen som kör skriptet.

Sedan finns det paketeringslagret, där de flesta Windows-signeringsinställningar tyst fragmenteras i tre eller fyra separata arbetsflöden: Appx- och MSIX-paket, som Windows inte installerar utan ett certifikat som är kopplat till en betrodd rot, oavsett om du skickar via Store eller sidladdar; ClickOnce, den självuppdaterande .NET-distributionsmodellen vars förtroende körs på signerade manifest som genereras via Microsofts Mage- och Mage UI-verktyg (och vars signeringsnycklar har en dålig vana att hamna i en utvecklares lokala certifikatarkiv istället för någonstans där ett säkerhetsteam kan se dem); och NuGet-paket, som har stöttat Authenticode-baserad signering sedan NuGet 4.6 och egentligen borde ha en betrodd tidsstämpel så att signaturen överlever certifikatet. CodeSign Secure hanterar alla tre på samma sätt som den hanterar själva binärfilen: en HSM, en revisionslogg, inga undantag för "det är bara ett manifest".

Och så finns det formatet som i tysthet skrämmer hårdvaruleverantörer: HLK/HCK-drivrutinssignering. Att få en drivrutin certifierad genom Windows Hardware Lab Kit (efterföljaren till det äldre Hardware Certification Kit) innebär att man skickar in signerade paket till Microsofts Windows Hardware Dev Center, och kernellägesdrivrutiner på 64-bitars Windows laddas helt enkelt inte utan en signatur från ett certifikat som uppfyller Microsofts nuvarande krav för EV eller hårdvarubaserade nyckelringar. En avvisad HLK-inlämning på grund av en signeringsteknikalitet kostar ett hårdvaruteam i realtid. CodeSign Secure stöder signering direkt mot dessa krav, vilket är skillnaden mellan en inlämning som godkänns granskning och en som studsar tillbaka med en anteckning som ingen vill läsa.

Apple: Ett ekosystem, ett strängare regelverk

Apple har en strammare plattform än Windows på den här fronten. codesign och Gatekeeper förväntar sig att varje macOS-, iOS- och watchOS-binärfil ska ha en signatur från ett Apple Developer-certifikat, och macOS lägger till en andra kontroll genom notarisering innan Gatekeeper låter en användare öppna appen utan en varningsdialogruta som avråder dem från det. Det vanligaste felläget här är inte en saknad signatur; det är ett Apple Developer-ID som sitter i en enskild ingenjörs nyckelring istället för någonstans där ett team kan rotera eller återkalla det. CodeSign Secure signerar macOS-, iOS- och watchOS-appar via standardflödet för Apple samtidigt som dessa certifikat förvaras i samma HSM-baserade valv som alla andra plattformsnycklar, så att "personen som äger Apples signeringscertifikat" slutar vara en enda felpunkt knuten till en bärbar dator.

Java och Android: Stacken där alla antar att någon annan signerar

Varje företag har minst en intern Java-tjänst som har körts tyst sedan en JVM som det nuvarande teamet knappt minns. jarsigner, som levereras med JDK, signerar de JAR-filer som dessa tjänster är beroende av så att en JVM (eller en användare) kan bekräfta att arkivet inte har manipulerats och, när manifestet inkluderar det, vem som faktiskt publicerade det. CodeSign Secure signerar JAR-filer genom sitt normala centraliserade flöde, vilket är viktigt främst eftersom JAR-signeringsnycklar är exakt den typ av autentiseringsuppgifter som konfigureras en gång, glöms bort och aldrig roteras. JSign dyker upp igen här också, vilket låter Linux- och macOS-baserade CI/CD- användare begära signaturer i Windows-format utan en dedikerad Windows-signeringsvärd bara för det enda pipeline-steget.

Android är sin egen historia. Varje APK måste signeras före installation, och schemat har utvecklats fyra gånger: v1 (ärvt direkt från Javas JAR-signering), v2 och v3 (helfilssigneringsscheman som Android introducerade i version 7.0 och 9 specifikt för att täppa till luckor som v1 lämnade öppna, och binda signaturen till det exakta APK-innehållet istället för bara manifestet), och v4 (ett strömningsschema som används tillsammans med v2/v3 för stegvisa appuppdateringar). CodeSign Secure signerar över alla dessa via APKSigner, dirigerat genom dess PKCS#11- omslag på både Linux-, Windows- och macOS-byggagenter, så en mobilversion uppfyller nuvarande Google Play-krav utan ett separat, ohanterat mobilt signeringsverktyg som ligger utanför allt annat.

Linux och öppen källkod: Ekosystemet med flest signeringskonventioner, inte minst

Om någon säger att Linux-signering "bara är GPG" så har de inte behandlat RPM-, Debian- och signering på repository-nivå som tre helt olika konventioner. RPM-baserade distributioner signerar med rpm –addsign (eller rpmsign), vilket bäddar in en GPG-nyckel direkt i pakethuvudet. Debian-baserade paket signeras via verktyg som dpkg-sig eller under bygget via debsign. Och APT-repositorymetadata, själva releasefilen, signeras separat så att en pakethanterare kan lita på ett helt repository snarare än att verifiera paket ett i taget. Tre konventioner betyder vanligtvis tre GPG-nyckelringar utspridda över bygginfrastrukturen, var och en med sin egen uppfattning om vem som är behörig att använda den. CodeSign Secure centraliserar alla tre under ett nyckelhanteringslager istället.

Två ytterligare Linux-anslutna format kompletterar detta. OpenSSL-signering täcker de fall där paketeringsverktyg inte klarar av det: råa hashtyper, anpassade datastrukturer, godtyckliga filer som behöver en fristående signatur och inte passar ett standardpaketformat. CodeSign Secure stöder OpenSSL-baserad signering (dgst -sign och CMS-arbetsflöden) så att dessa artefakter inte faller tillbaka på "den som har en lokal nyckelfil till hands". Och digitala XML-signaturer, det W3C-standardiserade XML-DSig-formatet under SAML-assertions, SOAP-meddelanden och en hel del reglerat dokumentutbyte, signeras enligt samma specifikation när ett efterlevnads- eller B2B-integrationskrav specifikt kräver det.

Molnbaserad infrastruktur och infrastruktur: Där signeringsstrategier är yngst och mest sannolikt att hoppas över

Det här är den kategori som de flesta äldre signeringsverktyg aldrig byggdes för, och det syns.

Signering av containerbilder kopplar en kryptografisk signatur till en bild så att alla som hämtar den kan verifiera vem som publicerade den och bekräfta att den inte har ändrats. Ekosystemet har mestadels konvergerat kring två tillvägagångssätt: Sigstores Cosign, som stöder självhanterade nycklar (inklusive HSM-baserade) eller nyckelfri signering genom kortlivade certifikat och en offentlig transparenslogg, och Notation, byggd på CNCF Notary v2-specifikationen, som använder PKI-baserade förtroendepolicyer och är vad Microsoft AKS och Amazon EKS rekommenderar för företags-Kubernetes. Båda binder signaturen till bildens innehållssammanfattning snarare än en muterbar tagg, vilket är hela anledningen till att manipulering överhuvudtaget är möjligt. CodeSign Säkra skyltar mot dessa nuvarande standarder, inte Docker Content Trust-modellen som Docker själv redan har föråldrat för officiella bilder.

OVA- och OVF -signering gör samma jobb för virtuella maskinenheter, standardpaketeringsformaten i VMware och den bredare specifikationen för öppna virtualiseringar från Distributed Management Task Force, så att ett team kan verifiera en VM-enhets integritet innan den går i närheten av produktion.

Signering av firmware är viktigare än något annat eftersom firmware finns under operativsystemet. En komprometterad firmware-avbildning överlever en ominstallation av operativsystemet och går direkt förbi de flesta verktyg för slutpunktssäkerhet. Signerad firmware, kontrollerad mot en säker startkedja, är den kontroll som hindrar en modifierad avbildning från att laddas från första början, och det är precis den typen av långlivad nyckel med hög explosionsradie som aldrig borde finnas i ett byggskript eller en leverantörs lokala verktyg. CodeSign Secure signerar firmware via samma HSM som allt annat på den här listan, inga undantag.

Reproducerbara byggen: Bevisa att binärfilen faktiskt matchar källan

En reproducerbar build innebär att kompilering av samma källkod med samma instruktioner producerar exakt samma binärfil, bit för bit, oavsett vem som bygger den eller när. Den egenskapen låter någon utanför din organisation självständigt återskapa en release och bekräfta att det du levererade faktiskt matchar det du publicerade, vilket är ungefär lika starkt ett försvar mot en komprometterad build-pipeline som finns just nu. CodeSign Secure stöder signeringsarbetsflöden byggda kring reproducerbara build-metoder, så signaturen på en release-artefakt är kopplad till en build-process som kan kontrolleras, inte bara litas på för att leverantören sa det. För hur detta kopplas till bredare leveranskedjeattestering, se Stärka leveranskedjesäkerheten med SLSA nivå 3 och kodsignering.

Post-Quantum Signing: Det som de flesta lag inte tänker på än

Här är ett obekvämt faktum: varje RSA- och ECDSA-signatur som stöder kodsignering idag är precis den typ av sak som en tillräckligt kapabel kvantdator skulle förstöra. NIST lämnade inte detta teoretiskt. FIPS 204 (ML-DSA, Module-Lattice-Based Digital Signature Standard) och FIPS 205 (SLH-DSA, Stateless Hash-Based Digital Signature Standard) slutfördes i augusti 2024, tillsammans med de tillståndsfulla hashbaserade LMS- och XMSS-scheman som specificeras i NIST SP 800-208. CodeSign Secure stöder avtagbar PQC-signering med ML-DSA och LMS, vilket innebär att en post-kvantumsignatur kan placeras bredvid, eller istället för, en klassisk RSA/ECDSA-signatur på samma artefakt. Ingen behöver riva ut sitt befintliga signaturschema för att starta detta. Det är hela värdet av "avtagbar": kryptoagilitet som du kan börja bygga in i en pipeline idag istället för under en scramble senare. Det är också där detta kopplas till en större fråga som de flesta team ännu inte har besvarat, nämligen att veta vilka signeringsalgoritmer som faktiskt används i deras miljö från första början. Det är mer en CBOM Secure- diskussion än en kodsigneringsdiskussion, men de två utgår från samma inventering.

PKCS#11: Se till att äldre verktyg inte blir ursäkten

En enorm mängd befintliga signeringsverktyg, särskilt äldre verktyg, skrevs direkt mot PKCS#11, det vanliga kryptografiska API som de flesta HSM:er och smarta tokens exponerar. Istället för att göra vart och ett av dessa verktyg till ett problem för någon att ersätta, presenterar sig CodeSign Secure som en PKCS#11-leverantör, så befintliga skript och tredjepartsverktyg som förväntar sig direkt hårdvaruåtkomst fortsätter att fungera exakt som de är skrivna. Skillnaden är vad som händer bakom det gränssnittet: varje signeringsoperation går fortfarande genom CodeSign Secures centraliserade policy-, loggnings- och godkännandelager istället för att kommunicera med rå hårdvara utan att övervakas.

I praktiken är PKCS#11-omslaget det som CodeSign Secures egna signeringsmotorer bygger på, och det körs på alla större byggplattformar:

• APK-signering — Linux, Windows och macOS
• OpenSSL-baserad signering — Linux och Windows
• Digitala XML-signaturer — Linux och macOS
• JSign-baserad signering — Linux, Windows och macOS
• Jarsigner (JAR)-signering — Linux, Windows och macOS
• GPG2-, Debian- och RPM-paketsignering — Linux

Hur CodeSign Secure är uppbyggt

Om man tar bort detaljerna ovan för varje format är arkitekturen densamma för var och en av dem: en hårdvarubaserad förtroendekälla, en uppsättning signeringsmotorer som talar varje formats inbyggda verktyg och ett policylager som varje begäran måste rensa innan en nyckeloperation sker.

• Hårdvarurot för förtroende: Privata nycklar genereras och lagras i en FIPS 140-2 nivå 3 HSM, distribueras lokalt, i molnet eller som en hybrid av båda, så att själva nyckelmaterialet aldrig lämnar validerad hårdvara oavsett format.
• Formatspecifika signeringsmotorer: Signtool och JSign för Authenticode, jarsigner och APKSigner för Java/Android, samdesign för Apple och Cosign/Notation-anpassad signering för containrar, där var och en anropar HSM istället för att innehålla en lokal nyckelkopia.
• PKCS#11 interoperabilitetslager: Ett PKCS#11-leverantörsgränssnitt låter befintliga skript och tredjepartsverktyg som förväntar sig direkt hårdvaruåtkomst fortsätta att fungera oförändrade, medan varje anrop fortfarande dirigeras genom policylagret nedanför.
• Centraliserat policy- och godkännandelager: RBAC- och M-of-N-arbetsflöden för flera godkännare ligger framför varje signeringsmotor, så en komprometterad byggautentiseringsuppgift kan inte producera en betrodd signatur på egen hand.
• Integrationspunkter: CI/CD-pipeline-plugins, ett API/CLI och PKCS#11-gränssnittet ovan täcker de sätt som byggsystem vanligtvis begär en signatur; bekräfta exakt vilka CI/CD-plattformar och OS-versioner som stöds för din miljö mot CodeSign Secures aktuella distributionsdokumentation innan du slutför en arkitektur.

Säkerhetskontroller bakom varje signatur

Formatlistan spelar mindre roll än vad som händer under den. Varje signeringshändelse, oavsett vilket av de 20+ formaten ovan som utlöser den, passerar genom samma uppsättning kontroller:

• Nyckelvård: Privata nycklar genereras och finns kvar i en FIPS 140-2 nivå 3 HSM; inget formats signeringsmotor får en lokal kopia av nyckeln.
• Rollbaserad åtkomstkontroll: Vem som kan begära en signatur, för vilket format och under vilket certifikat, definieras per roll snarare än per individuell autentiseringsuppgift.
• M-of-N-godkännande: Signeringsåtgärder med högre risk (en ny HLK-drivrutinsändning, en firmware-avbildning, en produktionsbehållare) kan kräva signering från ett definierat kvorum av godkännare snarare än en enda utvecklares godkännande.
• Centraliserad, oföränderlig revisionslogg: Varje signeringshändelse i alla format landar i en logg, kontrollen saknas helt och hållet för de mest fragmenterade signeringsinställningarna, snarare än en logg per verktyg (eller ingen logg alls).

Vad du behöver innan du distribuerar en kodsigneringslösning för företag

Inget av ovanstående fungerar utan att några saker är på plats först. Innan du utvärderar eller driftsätter en centraliserad signeringsplattform, bekräfta att du har:

• En HSM som uppfyller FIPS 140-2 nivå 3 (lokal, molnbaserad eller via HSM-as-a-Service om du inte redan använder en).
• Bygg agenter eller CI/CD-löpare för varje plattform du signerar för (Windows, Linux, macOS) som kan nå signeringsplattformens API, CI/CD-plugin eller PKCS#11-gränssnitt.
• Certifikat utfärdade från en certifikatutfärdare som är lämplig för varje användningsfall: en offentligt betrodd certifikatutfärdare för Authenticode- och Apple Developer-signering, och, där policyn tillåter, en intern certifikatutfärdare för intern Java-, XML- eller paketarkivsignering.
• En identitetskälla (befintlig katalog eller IdP) för att mappa namngivna godkännare till RBAC- och M-of-N-godkännandearbetsflödet.
• Specifikt för containersignering, ett register som stöder OCI-signaturbifogning så att signaturer i Cosign- eller Notation-stil binder till avbildningssammanfattningen.

Exakt vilka operativsystemversioner, CI/CD-plattformar och nätverkskrav som stöds varierar beroende på distributionsmodell. Kontrollera den aktuella listan mot CodeSign Secures distributionsdokumentation eller med din utvärderingskontakt istället för att anta enbart utifrån det här inlägget.

Kända begränsningar

En ärlig lista över vad centraliserad signering inte gör, inte bara vad den gör:

• Att centralisera nyckeln eliminerar inte behovet av plattformsbaserade verktyg för att först förbereda artefakten. Xcodes verktygskedja för Apples notariseringsinlämning, Windows Hardware Lab Kits paketeringsverktyg för drivrutinscertifiering och liknande verktyg körs fortfarande på byggagenten; CodeSign Secure tillhandahåller den betrodda nyckeloperationen, inte paketeringssteget.
• En lokal distribution kräver fortfarande att organisationen tillhandahåller eller ansluter en FIPS 140-2 nivå 3-kompatibel HSM (eller använder den som HSM-as-a-Service); CodeSign Secure är ett signerings- och policylager, inte en ersättning för själva HSM:en.
• PKCS#11-omslaget dokumenteras ovan för sex specifika arbetsflöden (APK, OpenSSL, XML, JSign, jarsigner och GPG2/Debian/RPM-signering); ett äldre verktyg utanför den listan bör bekräftas direkt med CodeSign Secures team innan du övertar täckningen.
• Avtagbar PQC-signering lägger till en andra signatur utöver den klassiska; den varken tar bort eller ersätter RSA/ECDSA-signaturen som dina befintliga klienter fortfarande verifierar mot idag, så behandla det som additiv kryptoagilitet, inte en slutförd migrering.

Här är den del vi faktiskt skulle berätta för dig i ett samtal

Antalet format som en signeringsplattform stöder är inte särskilt intressant. Vi säger detta i nästan varje utvärderingssamtal, och det förvånar personer som är mindre erfarna med utrymmet än man skulle kunna tro. Det intressanta värdet är hur många av en organisations signeringsnycklar som för närvarande ligger utanför ett enda, HSM-baserat kontrollplan, var och en med sin egen åtkomstlista, sin egen revisionslogg (eller fullständig brist på sådan) och sin egen förnyelsekalender som ingen spårar centralt.

Den siffran blev just mycket dyrare att ignorera. Under det nya maximala giltighetsfönstret på 460 dagar behöver var och en av dessa spridda nycklar utfärdas och omdistribueras ungefär tre gånger så ofta som före mars 2026. Ett manuellt signeringsarbetsflöde per verktyg som bara var irriterande för arton månader sedan är nu något som slukar verklig ingenjörstid varje kvartal, och det är värst för alla som fortfarande skickar runt fysiska USB-tokens för signering snarare än att dirigeras via en nätverksansluten eller molnbaserad HSM.

Så lösningen är inte att välja vilket verktyg som har den längsta funktionslistan på sin webbplats. Den ser till att varje signeringsformat som en organisation faktiskt använder ligger bakom en HSM, en RBAC-modell och ett M-of-N-godkännandearbetsflöde, så att en komprometterad byggserver eller ett nätfiskat utvecklarkonto inte kan producera en betrodd signatur oavsett vilket av de över tjugo formaten ovan den försöker.

Utvärderingschecklista för en företagskodsigneringslösning

Använd dessa frågor, i ordning, när du jämför en centraliserad signeringsplattform med din egen lista över format och verktyg:

1. Skickas varje format du faktiskt skickar via en HSM-baserad förtroenderot, eller döljer formaträkningen ett separat nyckellager per verktyg?
2. Tillämpas RBAC- och M-of-N-godkännande i alla format, eller bara på de få IT-avdelningar som konfigureras först?
3. Kan ni hämta en revisionslogg för en specifik signeringshändelse på begäran, i vilket format som helst, utan att kontrollera ett andra eller tredje verktygs loggar?
4. Stöder plattformen avtagbar post-kvantumsignering idag, eller är det fortfarande "på vägen"?
5. Matchar distributionsmodellen, lokalt, molnet eller hybrid, era krav på HSM-ägande och dataresidentitet?
6. För alla verktyg som era team förlitar sig på som förväntar sig direkt åtkomst till PKCS#11-hårdvara, publicerar leverantören exakt vilka arbetsflöden som stöds idag, snarare än ett generiskt påstående om att vara "PKCS#11-kompatibelt"?

Oberoende validering

Ta inte formatlistan på den här sidan som enda bevis. Jämför den med källor utanför Encryption Consulting:

• ABI Research utsåg CodeSign Secure till en av marknadsledarna inom kodsignering i sin oberoende marknadsbedömning; se ABI Research utser CodeSign säkert bland marknadsledarna inom kodsignering.
• Förändringen av certifikatgiltighet som driver detta inläggs brådska dokumenteras direkt av standardiseringsorganet: CA/Browser Forum-omröstning CSC-31: Maximal giltighetsreduktion.
• Postkvantumsignaturstandarderna som refereras till ovan, FIPS 204 (ML-DSA) och FIPS 205 (SLH-DSA), publiceras direkt av NIST och sammanfattas inte i andra hand.
• Encryption Consultings egen säkerhetspolicy (ISO/IEC 27001:2022, SOC 2, PCI DSS) finns dokumenterad på trust Center, oberoende av påståenden från någon enskild produkt.

Om du har kommit så här långt

Tjugo plus format är inte en fåfäng mätmetod; det är bara en ärlig återspegling av hur många olika sätt en modern mjukvaruorganisation faktiskt levererar saker: kod, skript, paket, containrar, firmware och nu post-kvantumsignaturer, ofta från samma releasepipeline. De team som drabbas är inte de som saknar ett signeringsverktyg. De är de som kör sex av dem, var och en med en nyckel som ligger någonstans där ingen tittar, precis som certifikatens livslängd blev tre gånger kortare.

Om ditt eget signeringsavtryck redan berör mer än två eller tre av formaten ovan, är det vanligtvis den punkt där konsolidering till en HSM-stödd plattform slutar vara ett projekt för en dag och börjar vara det som står mellan en rutinmässig release och en mycket dålig vecka.

Se hur CodeSign Secure centraliserar vart och ett av dessa arbetsflöden: utforska CodeSign Secure-plattformen.

Vanliga frågor om partihandel med mat och dryck

Kräver CodeSign Secure olika HSM för varje signeringsformat?

Nej. Alla format som CodeSign Secure stöder, från Authenticode till containeravbildningar till avtagbara PQC-signaturer, körs genom samma centraliserade HSM-infrastruktur, distribuerad lokalt, i molnet eller som en hybrid, så en organisation hanterar en hårdvaruförtroenderot istället för en per verktyg.

Kan CodeSign Secure signera både klassiska (RSA/ECDSA) och post-kvantumsignaturer på samma artefakt?

Ja. CodeSign Secure stöder avtagbara PQC-signaturer med hjälp av ML-DSA och LMS tillsammans med klassisk signering, så en post-kvantumsignatur kan läggas till i en release utan att ta bort den klassiska signatur som klienter fortfarande är beroende av för verifiering.

Varför behöver HLK/HCK-drivrutinssignering ett dedikerat arbetsflöde istället för standard Authenticode-signering?

Inlämningar av Windows Hardware Lab Kit har sina egna certifikat- och inlämningskrav knutna till Microsofts Windows Hardware Dev Center, och kernellägesdrivrutiner på 64-bitars Windows laddas inte utan en signatur som uppfyller dessa specifika krav, så signeringsarbetsflödet måste matcha Microsofts drivrutinscertifieringsprocess snarare än generiska Authenticode-regler.

Är Docker Content Trust fortfarande ett stödt sätt att signera containrar?

Docker har föråldrat Content Trust för officiella bilder, och nuvarande praxis har gått över till Sigstore Cosign eller Notation (Notary v2), vilka båda binder signaturer till en bilds innehållssammanfattning. CodeSign Säkra skyltar mot dessa nuvarande standarder snarare än den föråldrade modellen.

Vad förändrades med giltigheten för kodsigneringscertifikat år 2026?

Enligt CA/Browser Forum Ballot CSC-31 sänktes den maximala giltighetstiden för offentligt betrodda kodsigneringscertifikat från 39 månader till 460 dagar, med verkan från och med den 1 mars 2026, vilket avsevärt ökar hur ofta certifikat behöver utfärdas på nytt, särskilt för organisationer som fortfarande förlitar sig på fysiska hårdvarutokens istället för centraliserad HSM-signering.

Vad behöver jag innan jag driftsätter en kodsigneringslösning för företag som CodeSign Secure?

Som minimum en FIPS 140-2 nivå 3 HSM (lokal, molnbaserad eller som en tjänst), build agents eller CI/CD runners för varje plattform du signerar för, korrekt utfärdade certifikat för varje användningsfall och en identitetskälla för att mappa godkännare till RBAC- och M-of-N-arbetsflödet. Exakta OS-versioner som stöds och CI/CD-integrationer bör bekräftas mot aktuell distributionsdokumentation.

Tar centraliserad kodsignering bort behovet av plattformsspecifika signeringsverktyg?

Nej. Verktyg som Xcodes verktygskedja för Apple-notarisering eller Windows Hardware Lab Kits paketeringsverktyg för drivrutinscertifiering körs fortfarande på byggagenten för att förbereda artefakten. CodeSign Secure ändrar var den privata nyckeln finns och hur signeringsbegäran auktoriseras, inte själva plattformsnativa paketeringssteget.