Sicherung der Software-Lieferkette mit CodeSign Secure 

Einführung

Wenn Sie an Softwaresicherheit denken, denken Sie wahrscheinlich zuerst an Firewalls, Virenschutz oder das Patchen von Fehlern. Doch die größten Risiken gehen heutzutage nicht immer vom Code aus, den Sie schreiben. Sie entstehen durch den Code, den Sie verwenden, die Tools, denen Sie vertrauen, und die Systeme, die Ihre Anwendungen erstellen und bereitstellen. 

Die Software-Lieferkette verbindet alles: Ihren Quellcode, Open-Source-Bibliotheken, CI/CD-Pipelines, Build-Server, Cloud-Infrastruktur und sogar die Identitäten Ihrer Automatisierungstools. Wird nur eines dieser Glieder manipuliert, können Angreifer unbemerkt eindringen und das gesamte Produkt kompromittieren, ohne jemals Ihren eigentlichen Quellcode zu berühren.

Wir haben dies bereits bei Angriffen wie denen auf SolarWinds und Codecov erlebt. Ein einziges kompromittiertes Update oder ein durchgesickertes Geheimnis öffnete die Tür für massiven Schaden in Tausenden von Organisationen. Es handelt sich hierbei nicht nur um technische Probleme, sondern um Sicherheitslücken, die Unternehmen Vertrauen, Geld und Zeit kosten können.

Da sich Software schnell weiterentwickelt und stark auf Komponenten von Drittanbietern angewiesen ist, ist der Schutz der Lieferkette eine Grundvoraussetzung. Es geht nicht darum, zusätzliche Schritte hinzuzufügen. Es geht darum, sicherzustellen, dass die gelieferte Software genau das ist, was sie soll – und nicht mehr. 

In diesem Artikel erläutern wir, wie es zu Bedrohungen in der Lieferkette kommt, wo die Schwachstellen liegen und was Sie tun können, um den gesamten Prozess vom Schreiben des Codes bis zum Versand zu sichern. 

Sicherheit der Software-Lieferkette durch Codesignierung, definiert als: Überprüfung bei jeder Übergabe vom Quellcode-Commit zum bereitgestellten Artefakt, ob das, was ausgeführt wird, tatsächlich das ist, was erstellt und genehmigt wurde, unter Verwendung von Signaturen und Herkunftsnachweisen, nicht durch Malware-Scanning, das bekannte schädliche Muster erkennt, aber nichts darüber aussagt, ob dem Ursprung und dem Build-Prozess eines Artefakts vertraut werden kann.

Wichtige Erkenntnisse

• Signierung und Malware-Scanning beantworten unterschiedliche Fragen: Eine Signatur beweist Herkunft und Integrität, nicht aber Sicherheit. Ein vor der Signierung kompromittierter Build, wie beispielsweise bei SolarWinds, erzeugt eine Signatur, die einwandfrei verifiziert werden kann, während gleichzeitig Schadcode ausgeliefert wird.
• Diese Seite konzentriert sich auf die spezifische Rolle von CodeSign Secure im Bereich der Lieferkettensicherheit. Die grundlegende Angriffsflächenanalyse vom Build- bis zum Release-Prozess sowie den detaillierten Vergleich von Signierung und Scannen finden Sie hier: Codesignierung 101: Absicherung Ihrer Software-Lieferkette.

Was genau ist die Software-Lieferkette? 

Stellen Sie sich die Software-Lieferkette wie die Zubereitung einer Mahlzeit vor. Nicht alles auf Ihrem Teller wurde selbst zubereitet. Das Gemüse haben Sie vielleicht selbst geschnitten, aber die Soße kam aus dem Glas, die Gewürze waren vorverpackt und jemand anderes kümmerte sich um die Lieferung. Bei Software funktioniert es genauso. 

Wenn ein Entwickler eine Anwendung erstellt, ist es nicht nur sein eigener Code, der im Endprodukt landet. Es gibt Open-Source-Bibliotheken, Tools von Drittanbietern, APIs, Build-Systeme, Container-Images, Bereitstellungsplattformen und Skripte – im Grunde eine ganze Reihe beweglicher Teile, die alle zusammenkommen, damit die Software funktioniert. 

Diese Komponenten werden aus verschiedenen Quellen, oft automatisch, abgerufen und durch CI/CD-Pipelines zusammengeführt. Hinzu kommen Beiträge von Entwicklern, DevOps- Ingenieuren, Sicherheitsteams und Maschinen wie automatisierten Bots oder Servicekonten, die im Hintergrund die Prozesse vorantreiben.

All dies – der Code, die Tools, die Infrastruktur, die Mitarbeiter und die Automatisierung – ist Ihre Software-Lieferkette. 

Und genau wie bei der Lebensmittelsicherheit kann eine verunreinigte oder falsch gehandhabte Zutat das gesamte Gericht ruinieren. Deshalb ist es so wichtig zu verstehen, was in Ihrer Software steckt und wie sie erstellt und ausgeliefert wird. 

Wie es tatsächlich zu Angriffen auf die Software-Lieferkette kommt

Angriffe auf die Software-Lieferkette sind keine ferne Bedrohung wie in einem Film – sie sind überraschend real und, ehrlich gesagt, nicht allzu kompliziert. Angreifer dringen nicht immer durch Ihre Firewalls ein. Stattdessen schleichen sie sich unbemerkt über die Tools, Bibliotheken oder Systeme ein, denen Ihr Team bereits vertraut. 

So läuft es normalerweise ab: 

• Zielen Sie auf die Abhängigkeiten ab: Die meisten modernen Apps basieren auf Open-Source-Paketen. Angreifer schleusen Schadcode in diese Pakete ein, indem sie entweder veraltete Pakete übernehmen oder schädliche Updates bereitstellen, die nützlich erscheinen. Wenn Sie dieses Paket in Ihren Build integrieren, ist der Angriff sofort mit von der Partie. 

• Gefährdung der Build-Pipeline: Anstatt Ihre App direkt zu hacken, zielen Angreifer auf die Systeme ab, die sie erstellen oder bereitstellen, wie z. B. Ihre CI / CD-PipelineEin durchgesickertes Token, ein falsch konfiguriertes Skript oder sogar ein anfälliges Plug-In können ihnen Zugriff verschaffen, um Code kurz vor der Veröffentlichung einzuschleusen. 

• Geheimnisse stehlen oder preisgeben: APIs, Datenbanken und Cloud-Plattformen verwenden alle Token und Anmeldeinformationen. Wenn diese Geheimnisse im Quellcode oder in Protokollen landen (was häufiger vorkommt, als Sie denken), können Angreifer sie abgreifen und sich Zugriff verschaffen, ohne Alarm auszulösen. 

• Fälschen Sie die Quelle oder den Autor: In manchen Fällen geben sich Angreifer als vertrauenswürdige Mitwirkende aus und übermitteln scheinbar harmlosen Code. Wird dieser Code freigegeben, wird er Teil Ihres Produkts. Keine Alarme. Keine Warnsignale. Nur eine unauffällige Hintertür, die nur darauf wartet, genutzt zu werden. 

• Eine Abhängigkeit auf Registrierungsebene kapern: Wenn ein Angreifer ein Paketregistrierungskonto (npm, PyPI usw.) übernimmt, kann er gefälschte Versionen weit verbreiteter Tools verbreiten. Tausende von Apps könnten unwissentlich infizierte Versionen herunterladen und verwenden. 

Kurz gesagt: Es geht nicht immer darum, Dinge kaputt zu machen; es geht darum, sich anzupassen, seriös auszusehen und den Rest den Systemen zu überlassen. Und wenn der Schadcode erst einmal drin ist, kann er monatelang unentdeckt bleiben. 

SolarWinds, Codecov und mehr: Lehren aus schwerwiegenden Sicherheitsverletzungen 

Manchmal braucht es einen größeren Vorfall, um die Dinge durcheinander zu bringen, und in der Welt der Software-Lieferkettensicherheit haben einige Angriffe genau das bewirkt. 

SolarWinds 

Ende 2020 schleusten Angreifer Schadcode in ein legitimes Software-Update für die Orion-Plattform von SolarWinds ein. Dieses Update wurde an Tausende von Kunden, darunter namhafte Regierungsbehörden und Unternehmen, ausgeliefert. Was war daran so beunruhigend? Die Angreifer hackten nicht jedes Zielsystem, sondern verschafften sich Zugang über die Software, der die Nutzer bereits vertrauten. 

Lektion: Nur weil Code von einem vertrauenswürdigen Anbieter stammt, heißt das nicht, dass er sauber ist. Wenn Ihr Build-Prozess nicht durchgängig abgesichert ist, lassen Sie die Tür für Sicherheitslücken weit offen.

Codecov 

Im Jahr 2021 verschafften sich Angreifer Zugriff auf das Bash-Uploader-Skript von Codecov, indem sie dessen Docker-Image manipulierten . Dieses Tool wurde von Tausenden von Entwicklern in CI-Pipelines eingesetzt. Die manipulierte Version übertrug unbemerkt Umgebungsvariablen, darunter auch sensible Daten, an einen entfernten Server.

Lektion: Schon eine kleine Änderung an einem Tool in Ihrer CI/CD-Pipeline kann sensible Informationen an Angreifer weitergeben. Alles, was Anmeldeinformationen oder Builds betrifft, erfordert besondere Aufmerksamkeit.

Weitere erwähnenswerte Beispiele 

• Ereignis-Stream (npm): Ein Angreifer verschaffte sich Zugang, indem er seine Hilfe bei der Wartung eines verlassenen Softwarepakets anbot und anschließend Schadsoftware hinzufügte, die auf Krypto-Wallets abzielte. 

• UAParser.js (npm): Eine beliebte JavaScript-Bibliothek wurde entführt, um Schadsoftware auf den Systemen zu verbreiten, auf denen sie installiert war. 

Lektion: Wenn ein Paket öffentlich, unbeaufsichtigt oder weit verbreitet ist, stellt es ein verlockendes Ziel dar. Angreifer freuen sich, wenn man Paketen vertraut, ohne deren Inhalt zu überprüfen.

Vom Quellcode bis zur Bereitstellung: Wo die Schwachstellen liegen 

Softwareentwicklung ist wie ein Staffellauf: Ihr Code durchläuft zahlreiche Kontrollpunkte, bevor er in die Produktion gelangt. Das Problem? Bei jeder dieser Übergaben kann etwas schiefgehen, wenn Sie nicht genau aufpassen. 

Hier ist eine Aufschlüsselung, wo Dinge oft durch die Maschen schlüpfen: 

• Quellcode-Repos: Es beginnt mit dem Code. Aber wer hat Zugriff? Sind die Zweige geschützt? Wenn jemand eine Änderung ohne Überprüfung direkt in den Hauptcode eingibt oder, schlimmer noch, mit einem gestohlenen Token Zugriff erhält, gibt es Probleme, bevor der Build überhaupt beginnt. 

• Abhängigkeiten: Ihr Projekt basiert wahrscheinlich auf Hunderten externer Pakete. Einige sind möglicherweise veraltet, andere werden nicht mehr gewartet und manche enthalten möglicherweise sogar versteckte Malware. Es ist einfach, eine Abhängigkeit hinzuzufügen. Schwieriger ist es jedoch, den Überblick über die einzelnen Pakete zu behalten. 

• CI/CD-Pipelines: Diese automatisieren Ihre Builds, Tests und Bereitstellungen, was großartig ist. Sie verarbeiten aber auch Geheimnisse, führen Skripte aus und kommunizieren mit Produktionssystemen. Wird ein Job in der Pipeline kompromittiert, könnten Angreifer unbemerkt Code einschleusen oder vertrauliche Daten preisgeben. 

• Artefakte erstellen: Sobald Ihre App erstellt ist, wird der Ausgabe Ihres Container-Images, Ihrer Binärdatei oder Ihres Pakets in der Regel ohne Zweifel vertraut. Wenn dieses Artefakt jedoch nicht signiert oder verifiziert ist, lässt sich nicht feststellen, ob es echt oder manipuliert ist. 

• Bereitstellungssysteme: Kubernetes-, Terraform- und GitOps-Tools helfen alle dabei, Software schnell auszuliefern. Aber sie können auch eine Hintertür sein, wenn sie falsch konfiguriert sind. Ein einziger exponierter API oder ein missbrauchtes Servicekonto kann direkt zur Produktion führen. 

Jeder Schritt scheint für sich genommen einfach, doch zusammen bilden sie eine lange, zusammenhängende Kette. Und wie jede Kette ist sie nur so stark wie ihr schwächstes Glied. Deshalb muss Sicherheit Teil jedes einzelnen Schrittes sein und darf nicht erst am Ende angehängt werden. 

Warum CI/CD-Pipelines zu einem beliebten Angriffsziel geworden sind 

CI/CD-Pipelines sind das Herzstück moderner Softwarebereitstellung. Sie erstellen Ihren Code, führen Ihre Tests aus, signieren Ihre Artefakte und übertragen alles automatisch in die Produktion. Das ist viel Leistung an einem Ort. Und wissen Sie was? Angreifer haben es definitiv bemerkt. 

• Hoher Zugang, geringe Sichtbarkeit: CI/CD-Tools haben oft mehr Zugriff als die meisten Entwickler. Sie können Code extrahieren, Geheimnisse nutzen und ihn in der Produktion einsetzen – alles ohne menschliches Zutun. Das macht sie zu einer wahren Goldgrube für Angreifer. Und da das meiste davon im Hintergrund geschieht, können böswillige Änderungen eine Zeit lang unentdeckt bleiben. 

• Offenkundig aufbewahrte Geheimnisse: CI/CD-Umgebungen benötigen in der Regel Anmeldeinformationen für Dinge wie Cloud-Zugriff, Signaturschlüssel und APIs. Wenn diese Geheimnisse jedoch im Klartext gespeichert, falsch konfiguriert oder mit zu vielen Berechtigungen versehen sind, sind sie für Angreifer, die Zugriff auf die Pipeline erhalten, ein leichtes Ziel. 

• Viele Tools, viele Lücken: Die Pipeline besteht nicht nur aus einem Tool, sondern aus einer Mischung von Git-Plattformen, Runnern, Plugins, Paketmanagern, Cloud-Diensten und vielem mehr. Ist ein Teil dieser Kette unsicher oder ungepatcht, öffnet das Tür und Tor. Angreifer müssen nicht alles zerstören. Ein einziges Teil reicht aus. 

• Automatisierung ausnutzen: Sobald Angreifer in die Pipeline eingedrungen sind, können sie den Schaden automatisieren. Sie können Malware in einen Build einschleusen, Umgebungsvariablen ändern oder Geheimnisse an einen externen Server senden – und das alles, ohne ständigen Zugriff zu benötigen. Die Pipeline erledigt die Arbeit für sie. 

Warum Sie sich kümmern sollten 

Wenn ein Angreifer Ihre CI/CD-Pipeline kompromittiert, kann er schädliche Updates direkt an Ihre Benutzer senden. Keine Warnungen. Keine Alarme. Nur eine sauber aussehende Bereitstellung mit etwas Bösartigem darin. 

CI/CD ermöglicht eine schnelle und reibungslose Codebereitstellung, doch ohne angemessene Kontrollmechanismen werden Angriffe dadurch auch schnell und unbemerkt. Die Absicherung der Pipeline ist daher nicht mehr nur Aufgabe des DevOps-Teams , sondern hat höchste Sicherheitspriorität.

Code Signing richtig gemacht 

Die Codesignierung ist wie ein Wachssiegel auf Ihrer Softwareverpackung. Sie beweist, dass der Code tatsächlich von Ihnen stammt und nicht manipuliert wurde. Ohne ordnungsgemäße Codesignierung könnte jeder Schadcode in Ihre App oder Ihr Update einschleusen. Das bedeutet, dass Nutzer möglicherweise unwissentlich gefährliche Software installieren.

Das Signieren Ihres Codes schafft zusätzliches Vertrauen. Es signalisiert Benutzern und Systemen: „Das ist echt und kann sicher ausgeführt werden.“ Es trägt auch zur Einhaltung von Vorschriften bei. Viele Vorschriften verlangen den Nachweis, dass Software während der Bereitstellung nicht manipuliert wurde. Es geht aber nicht nur darum, eine Signatur anzubringen. Es geht darum, es richtig zu machen, sichere Schlüssel zu verwenden, diese Schlüssel zu schützen und die Signierung in Ihre Build- und Release-Pipeline zu integrieren. Wenn die Code-Signierung umständlich oder manuell erfolgt, wird sie oft übersprungen oder vermasselt. Das birgt Risiken. 

Um es richtig zu machen, sind Automatisierung, starke Kryptografie und klare Richtlinien erforderlich. 

In der heutigen Softwarewelt, in der Angriffe aus Ihrer Lieferkette kommen können, ist eine starke Code-Signierung ein Muss und kein nettes Extra. 

Unterschreiben ist kein Ersatz für Scannen

Es ist wichtig, genau zu definieren, was eine Signatur tatsächlich beweist, da die Verwechslung mit Malware-Scans ein häufiger und kostspieliger Fehler ist. Eine Signatur beantwortet die Frage: „Stammt die Datei von der erwarteten Quelle und hat sie sich seitdem verändert?“ Ein Scan hingegen beantwortet die Frage: „Entspricht die Datei bekannten Schadprogrammmustern oder -verhaltensweisen?“ SolarWinds ist ein Paradebeispiel dafür, warum diese Unterscheidung so wichtig ist: Das kompromittierte Orion-Update war mit einem gültigen Zertifikat signiert, weil die Angreifer den Build vor der Signierung und nicht danach modifiziert hatten. Die Signatur wurde einwandfrei verifiziert. Schwachstellen- und Malware-Scans sollten als Kontrollmechanismus vor der Signierung erfolgen. Die Signierung zertifiziert also bereits geprüften Code und nicht nur Code, dem zufällig ein gültiger Schlüssel zugeordnet ist.

SBOMs, Bescheinigungen und Transparenz in der gesamten Kette 

In Software-Lieferketten gilt: Was man nicht sieht, kann man nicht schützen. Hier kommen Dinge wie SBOMs und Attestierungen ins Spiel. Sie geben Ihnen ein klares Bild davon, was in Ihrer Software steckt und wie es dorthin gelangt ist. 

Was ist überhaupt eine SBOM? 

SBOM steht für Software Bill of Materials. Stellen Sie sich das als eine Zutatenliste Ihrer Software vor, die alle Komponenten, Bibliotheken und Abhängigkeiten auflistet, die zusammen gebündelt sind. Es hilft Teams, Schwachstellen schnell zu erkennen und erleichtert die Einhaltung von Vorschriften erheblich. 

Warum sind Bescheinigungen wichtig? 

Attestierungen sind wie digitale Quittungen, die bestimmte Schritte während Ihres Build- oder Release-Prozesses bestätigen. Eine Attestierung kann beispielsweise belegen, dass Ihr Code auf Schwachstellen geprüft oder mit einem vertrauenswürdigen Schlüssel signiert wurde. 

Die gesamte Kette im Blick 

Zusammen bieten SBOMs und Attestierungen einen besseren Einblick in den Inhalt und die Entwicklung Ihrer Apps. Diese Transparenz hilft, Probleme frühzeitig zu erkennen, Risiken zu vermeiden und schneller zu reagieren, wenn etwas schiefgeht. 

Mehr Transparenz, mehr Sicherheit 

Wenn Sie genau wissen, was in der Produktion läuft, und Sie den Nachweis haben, dass Ihr Code die richtigen Prüfungen durchlaufen hat, können Sie Ihrer Software leichter vertrauen und dies auch gegenüber Kunden und Prüfern leichter nachweisen. 

Wie CodeSign Secure von EC Ihnen hilft, Ihre Software von der Erstellung bis zur Auslieferung zu sichern 

Unser CodeSign Secure ist wie der Bodyguard Ihrer Software und stellt sicher, dass vom Zeitpunkt der Erstellung Ihres Codes bis zum Erreichen der Benutzer alles legal bleibt. 

Ihre Container-Images und andere Artefakte werden automatisch signiert, sodass Sie immer sicher sein können, dass sie nicht manipuliert wurden. Sie müssen sich nicht mehr fragen, ob das, was in der Produktion ist, mit dem übereinstimmt, was Sie getestet haben. 

Auf unserer Plattform können Sie außerdem sogenannte Attestierungen anhängen. Diese belegen, dass Ihr Build bestimmte Sicherheitsprüfungen oder Compliance-Schritte bestanden hat. So erhalten Sie vollständige Transparenz über den Werdegang Ihrer Software. 

Darüber hinaus funktioniert es reibungslos mit gängigen CI/CD-Tools, sodass sich das Signieren und Verifizieren nahtlos in Ihre vorhandenen Arbeitsabläufe einfügt, ohne diese zu verlangsamen. 

Und da unser CodeSign Secure moderne Standards unterstützt, funktioniert es gut mit Tools in der gesamten Lieferkette, sodass die Vertrauenswürdigkeit Ihrer Software bei jedem Schritt leichter gewahrt bleibt. 

Mit unserer Plattform unterzeichnen Sie nicht nur Code, sondern bauen auch Vertrauen in das auf, was Sie liefern. 

Compliance-fähige Sicherheit: Erfüllung der Anforderungen von SLSA, NIST, SSDF und CRA 

Die Sicherheit Ihrer Software-Lieferkette ist nicht nur eine gute Praxis, sondern oft auch unerlässlich, um Branchenstandards und -vorschriften einzuhalten. Hier kommen Frameworks wie SLSA, NIST SSDF und CRA ins Spiel. 

Was sind diese Frameworks? 

• SLSA (Supply-chain Levels for Software Artifacts), derzeit in Version 1.2, definiert drei zunehmend strengere Build-Track-Level, von der grundlegenden Build-Dokumentation auf Level 1 bis hin zu einer gehärteten, isolierten Build-Umgebung auf Level 3, die Ihren Build-Prozess nachvollziehbar und manipulationssicher machen. 

• NIST SSDF (Secure Software Development Framework) bietet Richtlinien zum Integrieren von Sicherheit in Ihren Entwicklungslebenszyklus und konzentriert sich dabei auf die Reduzierung von Risiken bei der Softwarebereitstellung. 

• Der EU Cyber ​​Resilience Act (CRA) legt Cybersicherheitsanforderungen für Produkte mit digitalen Elementen fest, die in der EU verkauft werden, darunter sichere Entwicklung, Umgang mit Schwachstellen und Verpflichtungen zur Integrität von Aktualisierungen, die durch Codesignierung direkt unterstützt werden. 

Warum sind sie wichtig? 

Wenn Sie diese Frameworks befolgen, ergreifen Sie konkrete Maßnahmen, um Ihre Pipeline abzusichern und Ihre Software zu schützen. Sie bieten klare, umsetzbare Anleitungen, sodass Sie nicht nur raten müssen, was Sie sichern müssen. 

Wie CodeSign Secure hilft 

Plattformen wie unsere CodeSign Secure erleichtern die Erfüllung dieser Anforderungen. Durch die Automatisierung der Codesignierung und der Artefaktbeglaubigung unterstützt unsere Plattform Ihre Compliance-Bemühungen ohne zusätzlichen manuellen Aufwand.

Letztendlich hilft Ihnen die Einhaltung dieser Standards dabei, das Vertrauen Ihrer Kunden, Partner und Prüfer aufzubauen und gleichzeitig die Bösewichte fernzuhalten. 

Häufig gestellte Fragen

Ist es sicher, ein signiertes Artefakt bereitzustellen?

Nicht unbedingt. Eine Signatur beweist Herkunft und Integrität ab dem Zeitpunkt der Signierung. Sie sagt nichts darüber aus, ob der Code vor der Signierung schädlich war, was aber genau im Fall des SolarWinds-Vorfalls der Fall war.

Wofür steht CRA in diesem Zusammenhang?

Der EU-Cyberresilience-Act ist eine Verordnung, die Cybersicherheitsanforderungen für Produkte mit digitalen Elementen festlegt, die in der EU verkauft werden. Er stellt ein anderes Rahmenwerk als SLSA oder NIST SSDF dar, obwohl die Codesignierung die Einhaltung aller drei unterstützt.

Welche SLSA-Stufe unterstützt CodeSign Secure?

CodeSign Secure unterstützt die reproduzierbare Build-Verifizierung, die Grundlage der gehärteten Build-Anforderung von SLSA Level 3. So können Sie Byte für Byte bestätigen, dass das, was Sie lokal erstellt haben, mit dem in der Produktion befindlichen übereinstimmt.

Fazit 

In der Software-Lieferkette geht es nicht mehr nur darum, sauberen Code zu schreiben. Es geht darum zu wissen, was in Ihre Builds einfließt, wie Ihre Software zusammengestellt wird und in der Lage zu sein, nachzuweisen, dass dabei nichts Undurchsichtiges passiert ist. 

Angreifer werden immer raffinierter und zielen auf die Tools und Automatisierungen ab, auf die Sie sich täglich verlassen. Ob es sich um eine kompromittierte Abhängigkeit, einen fehlerhaften CI-Job oder ein heimtückisches, unsigniertes Artefakt handelt – kleine Sicherheitslücken können zu großen Problemen führen. 

Aus diesem Grund sind Sichtbarkeit, Signierung und Rückverfolgbarkeit keine optionalen Dinge mehr. Sie bilden die Grundlage. 

CodeSign Secure hilft Ihnen, die Sicherheitsstandards zu erhöhen, indem Ihre Artefakte vom Build-Prozess bis zur Produktion geschützt werden. Dank integrierter Unterstützung für automatisierte Signaturen, detaillierte Attestierungen und SBOM-Integration erleichtert unsere Plattform den Aufbau von Vertrauen in jedem Schritt Ihrer Pipeline.

Und wenn Sie hohe Standards wie SLSA Level 3 oder höher anstreben, unterstützt Sie unsere Plattform mit reproduzierbarer Build-Unterstützung, sodass Sie Byte für Byte überprüfen können, ob das, was Sie lokal erstellen, genau dem entspricht, was in der Produktion landet. 

In einer Welt, in der das Vertrauen in Software ständig auf die Probe gestellt wird, bietet Ihnen unsere Plattform die Tools, um Ihre Arbeit zu zeigen und dafür einzustehen.