Das SLSA-Framework entwickelt sich ständig weiter, und das Neue SLSA v1.2 Diese Version enthält wichtige Aktualisierungen für alle, die Software in modernen Umgebungen entwickeln pipelineIm Gegensatz zu früheren Versionen konzentriert sich SLSA v1.2 stärker auf die praktische Anwendung, stärkere Herkunftsgarantien und klarere Regeln für SLSA-BescheinigungDa Angriffe auf die Software-Lieferkette immer zunehmen, benötigen Entwickler jetzt eine einfache und zuverlässige Möglichkeit, zu überprüfen, wie jedes einzelne Artefakt erstellt wurde und welche Systeme damit in Berührung gekommen sind.
Dieser Leitfaden erklärt die Neuerungen in Lieferkettenebenen für Softwareartefakte v1.2, warum zum SLSA-Framework wird zu einer Grundlage für software supply chain security und wie Sie diese Anforderungen auf natürliche Weise in Ihre CI- und CD-Workflows integrieren können.
1. Was ist SLSA und warum verlassen sich Entwickler auf das SLSA-Framework?
SLSA steht für Supply Chain Levels for Software Artifacts (Lieferkettenebenen für Softwareartefakte). SLSA-Framework schützt die Software-Lieferkette, indem es überprüft, wie der Code durch die Build-Prozesse fließt, wie Abhängigkeiten in ein Projekt gelangen und wie Artefakte übertragen werden. pipelines. Es definiert klare Regeln für Herkunft, Isolation und Integrität, damit die Teams genau wissen, was sie ausliefern.
Entwickler nutzen Supply-Chain-Levels für Softwareartefakte, weil sie eine praktische Frage beantworten: Lässt sich nachweisen, wie das Build-System eine Binärdatei erzeugt hat und ob dieser Prozess manipuliert wurde? Das ist in der Praxis von Bedeutung. pipelineIn Umgebungen, in denen sich Abhängigkeiten häufig ändern und Builds auf vielen Systemen ausgeführt werden, verringert SLSA das Risiko von Abhängigkeitsvergiftungen, fehlerhaften Build-Schritten und unautorisierten Änderungen innerhalb komplexer Workflows.
2. Was ist neu in SLSA v1.2?
SLSA v1.2 führt mehrere Änderungen ein, die die Einführung für Entwicklungsteams vereinfachen und realistischer gestalten. Diese Aktualisierungen bringen die Spezifikation zudem in Einklang mit den heutigen Softwareentwicklungsmethoden von Unternehmen.
Anforderungen an die Bauqualität
SLSA v1.2 präzisiert die Anforderungen an die Build-Isolation, damit Entwickler verstehen können, welche Teile eines Builds pipeline muss kontrolliert werden. Dies reduziert die Verwirrung im Vergleich zu früheren Versionen und hilft Teams dabei, einheitliche Schutzmaßnahmen für Runner, Builder und Orchestratoren anzuwenden.
Änderungen am SLSA v1.2 Attestierungsformat
Die neue Version aktualisiert die SLSA-Attestierungsstruktur, um die Erstellung und Nutzung von Nachweisen zu vereinfachen. Attestierungen lassen sich nun leichter auswerten, wodurch Tools die Verifizierung mit weniger manuellen Schritten automatisieren können.
Aktualisierte Herkunftsnachweisanforderungen
Das Herkunftsschema erfasst nun mehr Informationen über Abhängigkeiten, Build-Parameter und vertrauenswürdige Quellen. Dadurch wird es einfacher, jedes Artefakt zu seinem Ursprung zurückzuverfolgen.
Verbesserungen der Abhängigkeitssicherheit
Da Lieferkettenangriffe oft mit kompromittierten Paketen beginnen, verschärft Supply Chain Levels for Software Artifacts v1.2 die Erwartungen an die Auswahl von Abhängigkeiten, die Versionskontrolle und die Validierung.
Klarere Definitionen von Isolation
Die Spezifikation verbessert die Definitionen für hermetische Builds und isolierte Umgebungen. Dadurch können Entwickler ihre Build-Logik genauer validieren und versehentliches Vertrauen in unsichere Systeme vermeiden.
3. SLSA v1.2 vs. Frühere Versionen
Nachfolgend ein visueller Vergleich, der zeigt, wie SLSA v1.2 die Erwartungen an Provenienz, Build-Isolation und SLSA-Attestierung verändert.
| Gebiet | SLSA v1.1 | SLSA v1.2 |
|---|---|---|
| Herkunft | Grundlegende Herkunftsinformationen mit begrenzten Abhängigkeitsmetadaten | Erweiterte Herkunftsnachverfolgung mit detaillierterer Abhängigkeits- und Build-Parameter-Verfolgung |
| Bescheinigung | strengeres Attestierungsformat | Verfeinertes **SLSA-Attestierungsmodell** für einfachere Automatisierung und Validierung |
| Isolierung bauen | Allgemeine Isolationsrichtlinien | Klarere Definitionen für isolierte Bauelemente und hermetische Bauweisen |
| Abhängigkeitskontrollen | Begrenzte Erwartungen | Strengere Regeln für die Auswahl, Verfolgung und Überprüfung von Abhängigkeiten |
| Adoptionsschwierigkeiten | Gelegentliche Unklarheiten in den Anforderungen | Praktischer und einfacher für Entwicklungsteams anzuwenden |
4. SLSA-Attestierung verstehen
A SLSA-Bescheinigung Eine Attestierung ist eine signierte Erklärung, die die Entstehung eines Softwareartefakts belegt. Sie beschreibt den Build-Prozess, den Quellcode, die Abhängigkeiten und die Umgebung, in der die Binärdatei erzeugt wurde. Da Attestierungen einem festen Schema folgen, können sie von Tools automatisch validiert werden.
Für Entwickler bedeutet dies, dass sie überprüfen können, ob ein Build von der erwarteten Quelle stammt. pipeline und wurde nicht von einem nicht vertrauenswürdigen System verändert. Darüber hinaus helfen Attestierungen, Manipulationen frühzeitig zu erkennen, da verdächtige Änderungen direkt in der Herkunft sichtbar werden.
5. Wie Xygeni Ihnen hilft, die SLSA v1.2-Anforderungen zu erfüllen
Xygeni bietet ein gesamten build security Schicht das eng mit dem übereinstimmt SLSA-FrameworkStatt auf manuelle Überprüfungen angewiesen zu sein, erhalten Sie kontinuierliche Prüfungen von Code, Abhängigkeiten und CI. pipelines.
Herkunftsnachweis und Beglaubigungsvalidierung
Xygeni validiert Herkunftsdateien, überprüft SLSA-Bescheinigung Inhalte und Prüfungen, die Metadaten erstellen, die den erwarteten Quellen entsprechen.
Überwachung des Build-Skripts
Xygeni überwacht Build-Skripte, um unautorisierte Änderungen, unsichere Befehle oder verdächtiges Verhalten innerhalb des Build-Prozesses zu erkennen. pipelines.
Abhängigkeitsprüfung
Xygeni überprüft die Integrität, den Versionsverlauf und die Vertrauenswürdigkeit von Abhängigkeiten, um das Risiko kompromittierter Pakete zu reduzieren.
Artefaktintegrität
Xygeni scannt Artefakte auf Manipulationen und stellt sicher, dass sie dem erwarteten Build-Ergebnis entsprechen.
Pipeline Security
Xygeni bestätigt, dass CI und CD pipelines folgen einheitlichen und sicheren Konstruktionsmustern.
SBOM und Lieferkettenkartierung
Xygeni generiert und analysiert SBOMs, was Teams dabei hilft, zufrieden zu stellen SLSA provenance und nachgelagerte Prüfungsanforderungen.
Dadurch können Teams die Erwartungen von SLSA v1.2 erfüllen, ohne die Entwicklung zu verlangsamen und ohne mehrere Tools zusammenfügen zu müssen.
6. Abschließende Gedanken zum SLSA v1.2-Update
Die Supply-Chain-Levels für Software-Artefakte v1.2 sorgen für mehr Transparenz und stärkere Garantien in der Software-Lieferkette. Darüber hinaus haben Entwickler nun eine einfachere Möglichkeit, die Herkunft zu verstehen, die Integrität des Builds zu überprüfen und konsistente Kontrollen zu implementieren. pipelines. Die Spezifikation wird dadurch auch leichter zu übernehmen, und SLSA-Bescheinigung spielt eine zentrale Rolle beim Nachweis der Softwareentwicklung. Dadurch können Teams ein stärkeres Vertrauen in die von ihnen ausgelieferten Artefakte aufbauen.
Mit Xygeni können Sie die SLSA-Framework innerhalb Ihres bestehenden SDLCDarüber hinaus können Sie die Herkunft automatisch validieren, Abhängigkeiten kontinuierlich prüfen und Ihre Builds vor Manipulationen schützen. Dadurch stärken Sie Ihre Lieferkette, ohne die Entwicklung zu verlangsamen.
👉 Starten Sie Ihre kostenlose Testversion or Kontakt und sichern Sie Ihre Builds mit SLSA v1.2
