Windows-Codesignierung mit Artefaktsignierung meistern

Nutzer erwarten, dass heruntergeladene Windows-Anwendungen sicher, authentisch und manipulationssicher sind. Die Codesignierung ist unerlässlich, um dieses Vertrauen zu schaffen. Durch die digitale Signatur von Software können Entwickler nachweisen, dass eine Anwendung von einem verifizierten Herausgeber stammt und ihr Inhalt nach der Veröffentlichung nicht verändert wurde. Für Organisationen, die Windows-Anwendungen vertreiben, ist die Codesignierung nicht mehr nur eine bewährte Methode, sondern ein grundlegender Bestandteil der Softwarebereitstellung. Trotz ihrer Bedeutung birgt die traditionelle Codesignierung operative Herausforderungen. Die Beschaffung und Verwaltung von Zertifikaten ist zeitaufwändig, insbesondere angesichts der strengen Anforderungen an die Identitätsprüfung. Der Schutz privater Schlüssel erhöht die Komplexität und erfordert häufig Hardware-Sicherheitsmodule (HSMs), USB-Tokens oder eine dedizierte Infrastruktur. Zertifikatserneuerungen, Zugriffskontrollen und Compliance-Anforderungen erhöhen den administrativen Aufwand zusätzlich.

Diese Probleme verstärken sich in modernen Entwicklungsumgebungen, in denen Software mithilfe automatisierter CI/CD-Pipelines erstellt, getestet und veröffentlicht wird. Entwicklungsteams benötigen nahtlose Signaturprozesse, die sich in ihre Arbeitsabläufe integrieren lassen und Engpässe oder manuelle Schritte vermeiden. Die Verwaltung von Tokens, die Sicherung von Schlüsseln und die Pflege von Inventarlisten können Releases behindern und zu Reibungspunkten zwischen Sicherheit und Entwicklung führen.

Angesichts dieser anhaltenden Herausforderungen hat Microsoft kürzlich die allgemeine Verfügbarkeit von Artifact Signing bekannt gegeben , einem cloudbasierten Signaturdienst, der genau diese Probleme angeht. Mit Artifact Signing können Unternehmen die Verwaltung herkömmlicher Codesignaturzertifikate und der dazugehörigen Infrastruktur auslagern. Der Dienst bietet einen verwalteten, integrierten Ansatz, der Arbeitsabläufe optimiert, den manuellen Aufwand reduziert und zu einer sicheren und vertrauenswürdigen Softwarebereitstellung beiträgt.

Lösungen wie unsere CodeSign Secure ergänzen moderne Signaturdienste, indem sie ein zentrales Inventar kryptografischer Assets bereitstellen. Dies hilft Sicherheitsteams zu verstehen, wo kritische Zertifikate und Schlüssel verwendet werden, und potenzielle Risiken zu erkennen, bevor sie zu Problemen werden.

Angesichts zunehmender Sicherheitsrisiken in der Software-Lieferkette bieten Lösungen, die sowohl die Codesignierung vereinfachen als auch Einblicke in die kryptografische Nutzung ermöglichen, Sicherheitsteams einen entscheidenden Vorteil: Sie stärken die Gesamtsicherheit und reduzieren gleichzeitig Komplexität und Betriebskosten. Dieser doppelte Nutzen ist für den Erhalt von Vertrauen und Wettbewerbsfähigkeit immer wichtiger.

Meistern Sie die Windows-Codesignierung mit Artifact Signing, definiert als: Verwendung des cloudbasierten, von Microsoft verwalteten HSM-Signaturdienstes von Microsoft, ehemals Trusted Signing, zum Signieren von Windows-Executables und -Paketen über signtool.exe oder die dotnet sign CLI, ohne selbst einen privaten Schlüssel bereitzustellen oder zu schützen, und anschließende Überprüfung des Ergebnisses mit dem eigenen verify-Befehl von signtool vor der Auslieferung.

Wichtige Erkenntnisse

• Trusted Signing wurde 2026 in Artifact Signing umbenannt, ohne dass sich die Funktionalität änderte; bestehende Konten, Zertifikatsprofile, Abrechnung und APIs funktionieren weiterhin, lediglich die Client-Tool-Referenzen müssen aktualisiert werden.
• Die Signierung erfolgt weiterhin über signtool.exe (Digest-Signierung: Es wird nur ein Dateihash an Azure gesendet, niemals die vollständige Datei) oder die neuere, einfachere Methode. dotnet sign CLI; beide erfordern die lokale Installation der Artifact Signing Client Tools.
• Der private Schlüssel verlässt niemals das von Microsoft verwaltete HSM; es gibt keinen kundenseitigen Schlüsselanbieter oder HSM-Einrichtungsschritt, was den wesentlichen architektonischen Unterschied zu einer kundenkontrollierten Plattform wie CodeSign Secure darstellt.
• Die genaue Syntax der Befehlszeilenschnittstelle, die minimalen Tool-Versionen und die Namen der Flags haben sich während der Einführung dieses Dienstes mehrfach geändert; betrachten Sie die unten aufgeführten Befehle als zum Zeitpunkt der Erstellung dieses Dokuments verifiziert und überprüfen Sie sie mit den aktuellen Angaben. Dokumentation zur Artefaktsignierung von Microsoft Learn vor der Produktionsaufnahme.
• Die Identitätsprüfung für neue Konten erfolgt über einen Drittanbieter (au10tix) und ist eine häufige Ursache für Verzögerungen beim Onboarding, kein Problem der verwendeten Tools.

Herausforderungen der traditionellen Codesignierung

Während die Codesignierung für die Schaffung von Vertrauen in Windows-Anwendungen unerlässlich ist, bringt der traditionelle Ansatz oft verschiedene betriebliche und sicherheitstechnische Herausforderungen mit sich.

Die erste Hürde ist die Beschaffung und Erneuerung von Zertifikaten. Die Erlangung eines Code-Signatur-Zertifikats umfasst in der Regel Identitätsprüfung, Genehmigungsverfahren und die laufende Zertifikatsverwaltung. Unternehmen müssen zudem die Ablaufdaten im Blick behalten und rechtzeitige Erneuerungen sicherstellen, um Unterbrechungen bei Software-Releases zu vermeiden.

Der Schutz von Signaturschlüsseln ist ein weiteres wichtiges Anliegen. Da ein kompromittierter Signaturschlüssel dazu missbraucht werden kann, Schadsoftware unter einer vertrauenswürdigen Identität zu verbreiten, setzen viele Entwicklerteams auf Hardware-Token oder Hardware-Sicherheitsmodule (HSMs) zur sicheren Speicherung privater Schlüssel. Diese Lösungen verbessern zwar die Sicherheit, verursachen aber auch zusätzliche Kosten, erfordern eine komplexere Infrastruktur und einen höheren Verwaltungsaufwand.

Manuelle Signaturprozesse können den Release-Prozess zusätzlich verkomplizieren. In vielen Umgebungen wird die Signatur als separater Schritt behandelt, der spezielle Tools, Zugangsdaten oder Personal erfordert. Dies kann zu Verzögerungen führen, insbesondere wenn Entwicklungsteams Updates schnell oder häufig veröffentlichen müssen.

Der Wandel hin zu CI/CD-gesteuerter Softwarebereitstellung hat eine weitere Herausforderung aufgezeigt: die Integration. Traditionelle Codesignaturverfahren waren ursprünglich nicht für hochautomatisierte Build- und Deployment-Pipelines konzipiert. Die Verwaltung hardwarebasierter Schlüssel, die Gewährung sicheren Zugriffs auf die Signaturinfrastruktur und die Aufrechterhaltung der Signaturkonsistenz in verschiedenen Umgebungen können mit zunehmender Größe der Entwicklungsteams schwierig werden.

Compliance- und Auditvorgaben erhöhen die Komplexität zusätzlich. Sicherheitsteams müssen häufig nachweisen, wer ein bestimmtes Dokument unterzeichnet hat, wann die Unterzeichnung erfolgte und ob die entsprechenden Kontrollmechanismen eingehalten wurden. Die sorgfältige Dokumentation und der Nachweis der Compliance bei Audits können zeitaufwändig sein, wenn die Unterzeichnungsvorgänge über mehrere Tools und Systeme verteilt sind.

Insgesamt motivieren diese Herausforderungen Unternehmen dazu, nach Lösungen für die Codesignierung zu suchen, die einen klaren Mehrwert bieten: Reduzierung des manuellen Aufwands, Optimierung der Automatisierung, Vereinfachung der Compliance und Gewährleistung robuster Sicherheit. Die ideale Lösung beseitigt Reibungsverluste, ermöglicht eine nahtlose und sichere Softwarebereitstellung über den gesamten Entwicklungszyklus hinweg und bringt technische und geschäftliche Ziele in Einklang.

Was ist Artefaktsignierung?

Artifact Signing ist Microsofts cloudbasierter Signaturdienst, der Unternehmen die Signierung von Windows-Anwendungen und anderen Software-Artefakten vereinfacht. Der Dienst ist nun allgemein verfügbar und unterstützt Entwickler bei der Bewältigung vieler operativer Herausforderungen, die mit herkömmlichen Codesignaturzertifikaten und lokaler Signaturinfrastruktur verbunden sind.

Artifact Signing baut auf Microsofts früherem Trusted Signing-Dienst auf und erweitert das Konzept des verwalteten Signierens für moderne Softwareentwicklungs-Workflows. Anstatt dass Unternehmen die Verwaltung des Zertifikatslebenszyklus, die Schlüsselspeicherung und die Signaturinfrastruktur selbst übernehmen müssen, verwaltet Microsoft einen Großteil dieser Komplexität im Hintergrund.

Ein wesentlicher Vorteil sind die verwalteten Zertifikate, da sie sich nicht um Bereitstellung, Verlängerung oder Schlüsselschutz kümmern müssen . Der Dienst überprüft die Identität der Herausgeber, um Vertrauen herzustellen und sicherzustellen, dass nur autorisierte Organisationen unter ihrem Namen signieren.

Um die Sicherheitsanforderungen von Unternehmen zu erfüllen, bietet Artifact Signing eine rollenbasierte Zugriffskontrolle (RBAC). Administratoren können so festlegen, wer Signaturvorgänge durchführen und Signaturressourcen verwalten darf. Die Protokollierung von Audit-Aktivitäten ermöglicht die Nachverfolgung der Nutzung und die Einhaltung von Compliance-Vorgaben.

Da der Dienst cloudbasiert ist, lässt er sich nahtlos in moderne CI/CD-Pipelines und automatisierte Release-Prozesse integrieren. Entwicklungsteams können die Signierung direkt in Build- und Deployment-Workflows einbinden, ohne eine dedizierte Signaturinfrastruktur vorhalten zu müssen.

Laut Microsofts GA-Ankündigung zielt Artifact Signing darauf ab, die Codesignierung zugänglicher, skalierbarer und betrieblich effizienter zu gestalten und gleichzeitig das Vertrauen und die Sicherheit zu gewährleisten, die Windows-Softwareherausgeber benötigen.

Praxisbeispiel: Signieren eines Windows-Artefakts mit Artefaktsignatur

Diese Schritt-für-Schritt-Anleitung beschreibt den aktuellen, verifizierten Weg zum Signieren einer Windows-Executable: die Umgebung, in der sie ausgeführt wird, die notwendigen Einstellungen vor dem Signieren, die Funktionsweise der Authentifizierung, die eigentlichen Signierungs- und Verifizierungsbefehle, die zu erwartenden Ergebnisse und die Einbindung in CI/CD.

Umgebungsmatrix

Komponente	Unterstützt / Erforderlich	Notizen
Build-Agent-Betriebssystem	Windows x64	Für die Signierung mit signtool.exe erforderlich; prüfen Sie die aktuelle plattformübergreifende Unterstützung für die dotnet sign CLI, bevor Sie einen Linux- oder macOS-Agenten verwenden.
Architektur des Build-Agenten	x64 bestätigt; ARM64 nicht bestätigt	Mindestens ein Client-Tool wird auf ARM-Systemen nicht unterstützt; überprüfen Sie die Kompatibilität Ihres spezifischen Tools und Ihrer Version mit Microsoft Learn, bevor Sie ARM64-Runner verwenden.
signtool.exe	Ein aktueller Windows SDK-Build	Microsoft Learn gibt eine Mindestversion von SignTool an; überprüfen Sie die aktuelle, genaue Mindestversion auf der Seite zur Einrichtung der Artefaktsignatur, anstatt sich auf eine zwischengespeicherte Nummer zu verlassen, da diese mit der Veröffentlichung neuer SDK-Builds aktualisiert wurde.
.NET-Laufzeit (für Dotnet-Zeichen)	.NET 8 oder höher	Frühere Client-Tools hatten strikte Anforderungen an eine einzige .NET-Version; bei einer nicht passenden .NET-Version traten keine Fehler auf. Die aktuellen Artifact Signing Client Tools unterstützen hingegen die Aktualisierung auf spätere .NET-Versionen.
Azure-Abonnement	Erforderlich	Der Ressourcenanbieter Microsoft.CodeSigning muss für das Abonnement registriert sein, bevor ein Konto erstellt werden kann.

Voraussetzungen:

1. Ein Azure-Abonnement, bei dem der Ressourcenanbieter Microsoft.CodeSigning registriert ist.
2. Ein Artifact Signing-Konto und mindestens ein Zertifikatsprofil, das nach Abschluss der Identitätsprüfung (über au10tix) für die veröffentlichende Organisation oder Person erstellt wurde.
3. Die Entscheidung für ein Vertrauensmodell hängt davon ab, ob es sich um Public Trust (Software, die an die breite Öffentlichkeit verteilt wird) oder Private Trust (interne oder nur eingeschränkt verfügbare Software) handelt. Dies wird pro Zertifikatsprofil festgelegt und beeinflusst, auf welches Sie im Signaturbefehl verweisen.
4. Die Artifact Signing Client Tools wurden über winget auf dem Build-Rechner installiert: winget install -e --id Microsoft.Azure.ArtifactSigningClientTools.
5. Entweder sign .NET globales Tool (dotnet tool install -g sign) für den neueren CLI-Workflow oder eine aktuelle signtool.exe aus dem Windows SDK für den traditionellen Workflow.

Schlüsselanbieter-/HSM-Modell

Es gibt keinen kundenseitigen HSM-Einrichtungsschritt. Dies ist eine bewusste Architekturentscheidung und kein Mangel in diesem Leitfaden. Artifact Signing generiert und speichert den privaten Schlüssel innerhalb der von Microsoft verwalteten HSM-Infrastruktur. Der Signiervorgang erfolgt über einen Digest-Signatur-Workflow: Der lokale Client berechnet einen Hash der Datei und sendet nur diesen Hash an den Dienst, der eine Signatur zurückgibt. Die vollständige Datei und der Schlüssel verlassen niemals die jeweilige Grenze. Dies unterscheidet sich von einer kundenseitig kontrollierten Signaturplattform wie CodeSign Secure , bei der das Unternehmen sein eigenes HSM (Thales, Entrust, Utimaco, Securosys oder Cloud-HSM) auswählt und kontrolliert und seine eigene Richtlinie zur Schlüsselisolation und -genehmigung unabhängig von einem einzelnen Cloud-Anbieter durchsetzen kann. Beide Modelle sind legitim; sie beantworten unterschiedliche Fragen: „Möchte ich überhaupt eine Signaturinfrastruktur betreiben?“ versus „Möchte ich die direkte Kontrolle darüber, wo meine Schlüssel gespeichert sind und wie die Signatur über verschiedene Plattformen und Zertifizierungsstellen hinweg gesteuert wird?“

Sichere Authentifizierung

Es werden drei Authentifizierungspfade unterstützt, in der Reihenfolge ihrer Präferenz für automatisierte Umgebungen:

• Verbundene Anmeldeinformationen (OIDC) für GitHub Actions oder Azure DevOps: Konfigurieren Sie bei der App-Registrierung eine föderierte Anmeldeinformation, die auf das jeweilige Repository, die Organisation und den Branch oder Pull Request beschränkt ist, sodass die Pipeline ohne gespeichertes Geheimnis authentifiziert wird. Dies ist die bevorzugte Option für CI/CD.
• Verwaltete Identität für die Signierung von einer Azure-VM: Weisen Sie der VM eine vom Benutzer zugewiesene verwaltete Identität zu und erteilen Sie ihr die Rolle „Artefaktsignaturzertifikatprofil-Signierer“ auf Ressourcengruppen- oder Abonnementebene.
• Dienstprinzipal über Umgebungsvariablen, für andere CI-Systeme oder lokale Tests: kompensieren AZURE_TENANT_ID, AZURE_CLIENT_ID und AZURE_CLIENT_SECRET In der Umgebung prüfen sowohl signtool als auch die sign CLI automatisch darauf. Für die interaktive lokale Nutzung az login ist am einfachsten.

Bevor Sie mit diesen Arbeiten beginnen, registrieren Sie den Ressourcenanbieter einmal pro Abonnement:

az login
az provider register --namespace Microsoft.CodeSigning
az provider show --namespace Microsoft.CodeSigning --query "registrationState"

Warten Sie, bis der letzte Befehl eingegangen ist. "Registered" vor der Erstellung eines Anmeldekontos; die Registrierung dauert in der Regel ein paar Minuten.

Signierbefehl

Verwendung der sign CLI (der aktuelle, einfachere, offiziell unterstützte Weg):

sign code artifact-signing `
  --verbosity warning `
  --timestamp-url http://timestamp.acs.microsoft.com `
  --artifact-signing-endpoint https://eus.codesigning.azure.net/ `
  --artifact-signing-account <your-account-name> `
  --artifact-signing-certificate-profile <your-profile-name> `
  path\to\your-app.exe

Die Endpunkt-URL ist regionsspezifisch. Überprüfen Sie den korrekten regionalen Endpunkt für Ihr Artefaktsignaturkonto im Azure-Portal, anstatt ihn anzunehmen. eus (Ost-USA) gilt für Ihr Konto. Zum Signieren vieler Dateien hinzufügen --max-concurrency 10 (Standardwert ist 4), um die gesamte Signierzeit zu verkürzen.

Direkte Verwendung von signtool.exe (der traditionelle Pfad, der für bestehende Skripte weiterhin unterstützt wird):

signtool.exe sign /v /fd SHA256 /tr http://timestamp.acs.microsoft.com /td SHA256 ^
  /dlib "<path-to-Azure-Artifact-Signing-dlib>" ^
  /dmdf "<path-to-metadata-json-file>" ^
  path\to\your-app.exe

Die Metadatendatei, auf die verwiesen wird /dmdf Es handelt sich um eine kleine JSON-Datei, die Sie einmalig erstellen und die auf Ihr Artifact Signing-Konto, Ihr Zertifikatsprofil und Ihren Endpunkt verweist. Generieren Sie sie gemäß den aktuellen Einrichtungsschritten von Microsoft Learn und nicht, indem Sie ein Beispiel manuell kopieren, da sich das genaue Schema zwischen den Toolversionen geändert hat.

Verifizierungsbefehl und erwartete Ausgabe

Überprüfen Sie dies mit dem Befehl „verify“ von signtool, direkt aus der Microsoft-Dokumentation:

signtool.exe verify /v /debug /pa path\to\your-app.exe

Eine erfolgreiche Überprüfung meldet die Signatur als gültig, nennt den Betreff des Signaturzertifikats (der mit den Einstellungen Ihres Zertifikatsprofils im Azure-Portal übereinstimmen sollte) und bestätigt einen gültigen Zeitstempel der Gegensignatur. Wird die Signatur im Windows Explorer nicht unter „Eigenschaften“ > „Digitale Signaturen“ angezeigt, ist dies nicht unbedingt ein Fehler. Nicht jeder Dateityp zeigt diese Registerkarte an. Daher ist die Ausgabe von „signtool verify“ maßgebend und nicht die Anzeige im Explorer.

Häufige Fehler

Symptom	Wahrscheinliche Ursache	Was zu überprüfen
Die Signierung war erfolgreich, aber die Ausgabedatei ist unsigniert.	Eine nicht übereinstimmende .NET-Laufzeitversion mit älteren Client-Tools kann zu einem stillen Fehler führen, anstatt eine Fehlermeldung auszugeben.	Prüfen Sie, welche .NET-Version das Clienttool erwartet; die aktuellen Artifact Signing Client Tools unterstützen .NET 8+ mit Rolling Forward-Kompatibilität.
Zertifikats- oder EKU-bezogener Fehler	Die Datei signtool.exe wurde ausgewählt, hat aber die falsche Architektur (x86 statt x64 oder umgekehrt).	Überprüfen Sie die Umgebungsvariable SIGNTOOL_PATH und alle fest codierten Pfade in Ihrem Build-Skript.
Die GitHub-Aktion schlägt mit einem undokumentierten „Fehlercode 3“ fehl.	Mehrere Nutzer haben dies gemeldet, ohne dass zum jetzigen Zeitpunkt eine dokumentierte Ursache bekannt ist.	Prüfen Sie den aktuellen Problem-Tracker der Aktion und die FAQ zur Artefaktsignierung von Microsoft auf Aktualisierungen, bevor Sie davon ausgehen, dass das Problem spezifisch für Ihre Konfiguration ist.
Die Installation der Azure DevOps-Erweiterung schlägt mit einer InvalidSignature- oder NullReferenceException fehl.	Die .vsix-Datei wurde direkt über VSIXInstaller.exe auf einer Workstation ausgeführt, anstatt über den Marketplace in die Organisation installiert zu werden.	Installieren Sie die Erweiterung ausschließlich über den Visual Studio Marketplace in der Azure DevOps-Organisation, nicht als lokale Visual Studio-Erweiterung.
Die Anmeldung für eine große Charge ist zeitgesteuert.	Das standardmäßige Anforderungstimeout (300 Sekunden im PowerShell-Modul) wurde überschritten.	Erhöhen Sie den Timeout-Parameter für große Batches, teilen Sie den Batch auf oder erhöhen Sie den Wert für `--max-concurrency` über die Sign-CLI.
Der Onboarding-Prozess hängt bei der Identitätsprüfung fest.	au10tix (Drittanbieter für Identitätsverifizierung) Backend-Fehler bei der Dokumenten- oder Selfie-Verifizierung	Dies ist ein bekanntes, gelegentlich auftretendes Problem bei der Kontoeinrichtung und kein Fehler bei der Signatur. Versuchen Sie es erneut oder kontaktieren Sie den Support über den FAQ-Kanal zur Artefaktsignatur.

CI/CD-Beispiel

GitHub Actions , unter Verwendung einer föderierten Anmeldeinformation (ohne gespeichertes Clientgeheimnis) und der Sign-CLI:

- name: Install sign CLI
  run: dotnet tool install -g sign

- name: Sign artifact
  env:
    AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
    AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
  run: |
    sign code artifact-signing `
      --timestamp-url http://timestamp.acs.microsoft.com `
      --artifact-signing-endpoint ${{ secrets.AZURE_SIGNING_ENDPOINT }} `
      --artifact-signing-account ${{ secrets.AZURE_SIGNING_ACCOUNT }} `
      --artifact-signing-certificate-profile ${{ secrets.AZURE_SIGNING_PROFILE }} `
      path\to\your-app.exe

Beachten Sie, dass dies auslässt AZURE_CLIENT_SECRET bewusst; mit einer föderierten Anmeldeinformation, die bei der App-Registrierung für dieses spezifische Repository konfiguriert ist, erfüllt das eigene OIDC-Token von GitHub die Authentifizierung, ohne dass jemals ein dauerhaftes Geheimnis gespeichert werden muss. Azure-DevOps Verwendet eine Erstanbietererweiterung anstelle eines direkten CLI-Schritts: Installieren Sie „Artifact Signing“ aus dem Visual Studio Marketplace in Ihrer Organisation (erfordert die Berechtigung „Erweiterungen verwalten“) und verweisen Sie anschließend auf die AzureArtifactSigning@<version> Fügen Sie die Aufgabe in Ihre Pipeline-YAML-Datei ein und folgen Sie dabei der aktuellen Eingabereferenz der Aufgabe im Marketplace-Eintrag, um die genauen Parameternamen für Ihre installierte Version zu erhalten.

Aufräumen

• Wenn Sie für lokale Tests ein Dienstprinzipalgeheimnis verwendet haben, entfernen Sie es aus Ihrer Shell-Umgebung und, falls es nur vorübergehend benötigt wurde, löschen Sie das Clientgeheimnis aus der App-Registrierung in Azure AD.
• Führen Sie az logout auf einem beliebigen gemeinsam genutzten oder temporären Build-Agenten, bei dem Sie sich interaktiv authentifiziert haben.
• Entfernen Sie alle föderierten Anmeldeinformationen, die auf einen Branch, ein Repository oder eine Pull-Anfrage beschränkt sind, die nicht mehr aktiv sind, da eine veraltete föderierte Anmeldeinformation auch ohne gespeichertes Geheimnis eine bestehende Vertrauensbeziehung darstellt.
• Wenn die Artifact Signing Client Tools nur für einen einmaligen Test installiert wurden, deinstallieren Sie sie mit winget uninstall --id Microsoft.Azure.ArtifactSigningClientTools anstatt die Signaturwerkzeuge auf einer Maschine zu belassen, die sie langfristig nicht benötigt.

Unterstützung moderner Software-Lieferketten

Die Codesignierung wurde traditionell mit ausführbaren Dateien in Verbindung gebracht, doch der heutige Softwarebereitstellungsprozess umfasst weit mehr als nur Anwendungen und Installationsprogramme. Unternehmen erstellen, verpacken, verteilen und implementieren mittlerweile eine Vielzahl von Softwareartefakten, darunter Container, Bibliotheken, Skripte, Konfigurationsdateien, Pakete und Bereitstellungsmanifeste. Daher muss sich das Vertrauen über die endgültige ausführbare Datei hinaus erstrecken.

Diese Entwicklung hat die Sicherheit der Software-Lieferkette zu einer zentralen Priorität gemacht. Angreifer zielen zunehmend auf Build-Umgebungen, Abhängigkeiten und Vertriebspipelines ab, da die Kompromittierung einer einzelnen Komponente Tausende von Nutzern nachgelagerter Systeme beeinträchtigen kann. In vielen Fällen wird die Software selbst nicht direkt verändert; stattdessen werden an einer beliebigen Stelle im Auslieferungsprozess bösartige Änderungen eingeschleust.

Hier kommt der digitalen Signatur eine wichtige Rolle zu. Digitale Signaturen tragen zur Herkunftssicherung bei, indem sie belegen, woher ein Artefakt stammt und wer seine Verbreitung genehmigt hat. Sie unterstützen außerdem die Integritätsprüfung, indem sie den Empfängern ermöglichen, zu bestätigen, dass ein Artefakt nach der Signatur nicht verändert wurde.

Da Entwicklungsteams zunehmend automatisieren, Pipelines aufbauen und verteilte Entwicklungsmethoden einführen, ist Vertrauen auf Artefaktebene unerlässlich. Sicherheitsteams benötigen die Gewissheit, dass jede Komponente, die zur Erstellung und Bereitstellung von Anwendungen beiträgt, vertrauenswürdig ist. Unabhängig vom Typ sollte jedes Artefakt auf eine vertrauenswürdige Quelle zurückführbar sein.

Forschung und Branchenempfehlungen bestätigen weiterhin die Bedeutung der Codesignierung als zentrales Kontrollinstrument zur Stärkung der Softwareherkunft und der Lieferkettensicherheit. Bei konsequenter Anwendung trägt die Signierung dazu bei, eine nachweisbare Vertrauenskette im gesamten Softwarebereitstellungsprozess zu schaffen. Dies erleichtert die Erkennung unautorisierter Änderungen, reduziert das Manipulationsrisiko und erhöht das Vertrauen in die veröffentlichte Software.

Kurz gesagt, geht es bei der modernen Codesignierung nicht mehr nur darum, die Authentizität einer ausführbaren Datei nachzuweisen. Es geht darum, Vertrauen entlang der gesamten Software-Lieferkette zu schaffen.

Mehr als nur Signieren: Warum kryptografische Transparenz wichtig ist

Die Artefaktsignierung vereinfacht zwar die Softwaresignierung, doch ist die Signierung nur ein Teilaspekt der kryptografischen Sicherheit. Unternehmen verfügen möglicherweise über einen optimierten Signierungsprozess, haben aber dennoch Schwierigkeiten, wichtige Fragen zu beantworten, wie beispielsweise: Welche Zertifikate werden in den Entwicklungsumgebungen verwendet? Wo werden die Signaturschlüssel gespeichert? Welche kryptografischen Algorithmen kommen zum Einsatz? Gibt es abgelaufene, schwache oder nicht verwaltete Assets, die ein Risiko darstellen?

Ohne klare Transparenz sind diese Fragen schwer zu beantworten, insbesondere in großen Unternehmen, in denen kryptografische Assets über Cloud-Dienste, HSMs, CI/CD-Pipelines, Server, Anwendungen und Entwicklerumgebungen verteilt sind.

Artifact Signing vereinfacht zwar den Signierungsprozess, Unternehmen benötigen aber auch Einblick in die kryptografischen Assets, die ihre Softwarebereitstellungspipelines unterstützen. Hier ergänzt CodeSign Secure moderne Codesignaturprogramme, indem es Zertifikate, Schlüssel und kryptografische Abhängigkeiten in Cloud-, HSM-, DevOps- und Unternehmensumgebungen erkennt, inventarisiert und verfolgt.

Unsere Lösung ermöglicht die automatisierte Erkennung von Code-Signatur-Zertifikaten und zugehörigen kryptografischen Assets. So erhalten Sicherheitsteams einen umfassenden Überblick über vorhandene Ressourcen, deren Speicherort und Verwendung. Anstatt auf Tabellenkalkulationen oder manuelle Prüfungen angewiesen zu sein, erhalten Unternehmen ein zentrales kryptografisches Inventar, das einen klaren Überblick über Zertifikate, Schlüssel, Algorithmen, Vertrauensketten und die Signaturinfrastruktur bietet.

Diese Transparenz ist wertvoll, um Risiken zu erkennen, bevor sie die Softwarebereitstellung beeinträchtigen. Sicherheitsteams können abgelaufene Zertifikate, schwache Algorithmen, nicht verwaltete Schlüssel, doppelte Assets oder kryptografische Abhängigkeiten erkennen, die möglicherweise Aufmerksamkeit erfordern. Die Verfügbarkeit dieser Informationen vereinfacht zudem Audits und unterstützt stärkere Governance-Praktiken.

Über die operative Sicherheit hinaus gewinnt die Transparenz kryptografischer Daten für die langfristige Planung zunehmend an Bedeutung. Im Zuge der Vorbereitung auf die Umstellung auf Post-Quanten-Kryptografie (PQC) ist es ein entscheidender erster Schritt zu verstehen, wo kryptografische Ressourcen und Algorithmen eingesetzt werden. Unternehmen können keine effektive Migrationsstrategie planen, ohne zuvor zu wissen, welche kryptografischen Ressourcen in ihrer Umgebung im Einsatz sind.

Durch die Kombination der einfachen Signierung von Artefakten mit den Erkennungs- und Analysefunktionen unserer Lösung können Unternehmen das Vertrauen in ihre Software stärken und gleichzeitig die kryptografische Governance verbessern. Die Signierung trägt zur Sicherstellung von Authentizität und Integrität bei, während unsere Lösung die notwendige Transparenz bietet, um die kryptografischen Grundlagen moderner Softwareentwicklung zu verwalten, zu bewerten und zukunftssicher zu gestalten.

Wie unser CodeSign Secure hilft

Artifact Signing vereinfacht zwar die Softwaresignierung, doch viele Sicherheitsteams benötigen weiterhin eine umfassende Lösung für die Verwaltung von Signaturvorgängen über verschiedene Plattformen, Umgebungen und Anwendungsfälle hinweg. Hier setzt CodeSign Secure von Encryption Consulting an und bietet einen echten Mehrwert.

Unsere Lösung CodeSign Secure bietet zentrale Kontrolle über Codesignierungsaktivitäten und unterstützt Unternehmen bei der Durchsetzung einheitlicher Signaturrichtlinien über Entwicklungsteams und Release-Pipelines hinweg. Ob Windows-Anwendungen, Container, Skripte, Treiber oder andere Softwareartefakte signiert werden – Teams können den gesamten Signaturprozess über eine einzige Plattform verwalten.

Einer der Hauptvorteile unserer Lösung ist ihre Flexibilität. Unternehmen können cloudbasierte Signaturdienste, öffentliche und private Zertifizierungsstellen , HSMs und bestehende DevOps- Tools integrieren und dabei die volle Transparenz und Kontrolle über die Signatur-Workflows behalten. So können Sicherheitsteams Genehmigungsprozesse definieren, Zugriffskontrollen durchsetzen und sicherstellen, dass Signaturschlüssel nur von autorisierten Benutzern und Systemen verwendet werden.

Die Plattform bietet zudem detaillierte Prüfprotokolle, wodurch sich leichter nachvollziehen lässt, wer wann was signiert hat und welche Anmeldeinformationen verwendet wurden. Dies unterstützt die Einhaltung von Compliance-Anforderungen und vereinfacht Sicherheitsüberprüfungen.

In Kombination mit Diensten wie Artifact Signing dient unsere Lösung als Governance- und Orchestrierungsschicht, die Signaturvorgänge, Richtliniendurchsetzung und Transparenz integriert. Das Ergebnis ist ein kontrollierteres, skalierbareres und sichereres Codesignaturprogramm, das sowohl die Entwicklungseffizienz als auch die Sicherheitsanforderungen von Unternehmen erfüllt.

Signierung von Artefakten vs. eine kundenkontrollierte Plattform: Was passt besser?

Berücksichtigung	Artefaktsignierung	CodeSign Secure (kundengesteuert)
Schlüsselverwahrung	Microsoft-verwaltetes HSM; Sie wählen die Hardware nie aus und müssen sie auch nicht berühren.	Ihr gewähltes HSM (Thales, Entrust, Utimaco, Securosys oder Cloud-HSM)
Plattformumfang	Windows-Fokus (Authenticode, MSIX, Treibersignatur)	Plattformübergreifend: Windows, Java/Android, Linux, Container, Firmware, PQC
CA/Trust-Modell	Microsofts eigene Signatur-CA, öffentliches oder privates Treuhandkonto	Ihre Wahl zwischen öffentlicher oder privater CA
Governance über mehrere Signaturwerkzeuge hinweg	Regelt ausschließlich Aktivitäten im Zusammenhang mit der Artefaktsignierung.	Eine einheitliche Richtlinien-Engine für alle verwendeten Signaturtools und -plattformen
Optimale Bildschirmwahl	Windows-basierte Shops, die den Betrieb einer Signaturinfrastruktur komplett vermeiden wollen.	Organisationen, die über mehrere Plattformen hinweg Signaturen erstellen oder die direkte Kontrolle über die Schlüsselverwaltung und die Wahl der Zertifizierungsstelle benötigen.

Häufig gestellte Fragen

Ist Trusted Signing dasselbe wie Artifact Signing?

Ja. Microsoft hat Trusted Signing im Jahr 2026 in Artifact Signing umbenannt, ohne dass sich die Funktionalität geändert hat. Bestehende Konten, Zertifikatsprofile, Abrechnung und APIs funktionieren weiterhin unverändert; lediglich die Verweise auf Client-Tools müssen auf den neuen Namen aktualisiert werden.

Benötige ich ein eigenes HSM, um Artifact Signing zu verwenden?

Nein. Artifact Signing generiert und speichert den privaten Schlüssel innerhalb der von Microsoft verwalteten HSM-Infrastruktur. Dies ist der zentrale Kompromiss gegenüber einer kundenkontrollierten Plattform: weniger Einrichtungsaufwand, aber keine Wahlmöglichkeit hinsichtlich der Schlüsselverwaltung oder des Hardwareanbieters.

Wird die vollständige Datei zum Signieren in Azure hochgeladen?

Nein. Die Signierung erfolgt mittels Digest-Signatur: Der lokale Client berechnet einen Hashwert der Datei und sendet nur diesen an den Dienst, der daraufhin eine Signatur zurückgibt. Die Datei selbst verlässt niemals den Build-Rechner.

Welche Befehlszeilenschnittstelle wird derzeit empfohlen, signtool.exe oder dotnet sign?

Beide werden offiziell unterstützt. sign Das globale .NET-Tool (dotnet sign) hat sich als einfacherer und schnellerer Weg für neue Setups etabliert, während signtool.exe mit der Artifact Signing dlib die Option für Teams bleibt, die bereits signtool-basierte Build-Skripte besitzen und diese nicht neu schreiben möchten.

Warum ist die Installation meiner Azure DevOps-Erweiterung fehlgeschlagen?

Meistens liegt das daran, dass die .vsix-Datei direkt über VSIXInstaller.exe auf einer Workstation ausgeführt wurde. Dies führt zu einer irreführenden Fehlermeldung wie „InvalidSignature“ oder „NullReferenceException“, obwohl die Signatur des Pakets gültig ist. Installieren Sie es ausschließlich über den Visual Studio Marketplace in Ihrer Azure DevOps-Organisation.

Fazit

Für viele Unternehmen ist die traditionelle Codesignierung seit Langem ein notwendiger, aber oft komplizierter Bestandteil der Softwarebereitstellung. Die Verwaltung von Zertifikaten, der Schutz von Signaturschlüsseln, die Wartung der Signaturinfrastruktur und die Einhaltung von Compliance-Anforderungen können einen erheblichen operativen Aufwand verursachen, insbesondere da Entwicklungsteams schnellere Releasezyklen und automatisierte Bereitstellungspipelines einführen.

Microsofts Artifact Signing ist ein wichtiger Schritt zur Vereinfachung dieses Prozesses. Durch die Verlagerung der Zertifikatsverwaltung und der Signiervorgänge in einen Cloud-basierten Dienst reduzieren Sie den Verwaltungsaufwand, verbessern die Skalierbarkeit und integrieren die Signierung nahtlos in moderne CI/CD-Workflows. So können sich Entwicklungsteams stärker auf die Softwareentwicklung und -bereitstellung konzentrieren, anstatt die Signaturinfrastruktur zu warten.

Die Signierung von Software ist jedoch nur ein Teil des Sicherheitspuzzles. Sicherheitsteams benötigen außerdem Einblick in die Zertifikate, Schlüssel, Algorithmen , Vertrauensketten und Signatursysteme, die ihre Software-Lieferketten unterstützen. Ohne diesen Einblick wird es schwierig, Risiken einzuschätzen, Governance-Richtlinien durchzusetzen oder sich auf zukünftige kryptografische Änderungen vorzubereiten.

Hier spielen Lösungen wie CodeSign Secure eine wichtige Rolle. Durch die automatisierte Erkennung und Inventarisierung kryptografischer Assets in Cloud-, HSM-, DevOps- und Unternehmensumgebungen unterstützt unsere Lösung Sie dabei, die Kryptografie Ihrer Softwarebereitstellungsprozesse zu verstehen und zu verwalten. In Kombination mit unserer Lösung erhalten Teams mehr Kontrolle über Signaturvorgänge und behalten gleichzeitig die für Governance und Compliance notwendige Transparenz.

Artifact Signing und unsere Lösung unterstützen gemeinsam Entwicklungsteams beim Aufbau einer stärkeren Grundlage für Softwarevertrauen. Sie vereinfachen Signaturprozesse, verbessern die kryptografische Kontrolle und fördern eine sicherere Software-Lieferkette von der Entwicklung bis zur Bereitstellung.