Best Practices für Software-Lieferkettensicherheit

Quellcode

• Starke Authentifizierung verlangen. Nutzen Sie Multi-Faktor-Authentifizierung für jedes Konto beim Code-Hosting.
• Den Main-Branch schützen. Verlangen Sie ein Review vor dem Merge, und lassen Sie niemanden direkt auf einen Release-Branch pushen.
• Secrets aus dem Code heraushalten. Scannen Sie bei jedem Push danach, und rotieren Sie alles, was offengelegt wurde.
• Workflow-Dateien wie Code behandeln. Eine Änderung an einer Pipeline kann Ihre Secrets erreichen, lassen Sie Änderungen also von den Zuständigen prüfen.

Abhängigkeiten

• Ein Lockfile einchecken und daraus installieren. Nutzen Sie npm ci und seine Entsprechungen, damit Builds nicht versehentlich neue Versionen übernehmen. Ein Lockfile hat Grenzen, aber es ist der richtige Ausgangspunkt.
• Eine Wartezeit für neue Versionen einführen. Bösartige Releases werden oft bald nach ihrem Erscheinen entdeckt, und wer eine Version nicht am Tag ihrer Veröffentlichung übernimmt, gibt der Entdeckung eine Chance.
• Install-Skripte begrenzen. Deaktivieren Sie sie, wo Sie können. Skripte, die bei der Installation laufen, sind der Weg, über den sich npm-Würmer verbreiten.
• Neue Abhängigkeiten prüfen. Kontrollieren Sie den Namen auf Typosquatting, und achten Sie auf Pflege und Verbreitung. OpenSSF Scorecard automatisiert einen Teil davon.
• Interne Paketnamen schützen. Nutzen Sie Scopes und die Registry-Konfiguration, damit kein öffentliches Paket per Dependency Confusion die Stelle eines internen einnehmen kann.
• Entfernen, was Sie nicht brauchen. Jede Abhängigkeit ist etwas, das zusätzlich überwacht werden muss.

Build und CI/CD

• GitHub Actions auf einen vollständigen Commit-Hash pinnen. Tags lassen sich verschieben, wie die Kompromittierung von tj-actions gezeigt hat.
• Begrenzen, was jeder Job darf. Geben Sie dem Workflow-Token nur die Rechte, die es braucht, und nutzen Sie kurzlebige Zugangsdaten statt langlebiger Secrets.
• Ausgehenden Datenverkehr beschränken. Ein Build braucht Pakete aus bekannten Quellen und veröffentlicht an bekannte Orte. Blockieren Sie alles andere, dann können gestohlene Secrets nirgendwohin. Siehe GitHub-Actions-Egress-Richtlinie.
• Jeden Job in einer frischen, isolierten Umgebung ausführen. Nichts sollte von einem Job in den nächsten übergehen, schon gar nicht aus einem Pull Request eines externen Mitwirkenden.
• Caches als Eingabe behandeln. Ein vergifteter Cache überdauert Builds, und was er wiederherstellt, wird leicht übersehen. Siehe GitHub-Actions-Cache.

Die vollständige Liste finden Sie in der Sicherheitscheckliste für CI/CD-Pipelines und unter Runner-Sicherheit im Vergleich.

Release

• Für jedes Release eine SBOM aus dem Build erzeugen. Bewahren Sie sie beim Artefakt auf. Siehe SBOM Best Practices.
• Artefakte signieren und Provenienz veröffentlichen. So können Nutzer prüfen, woher ein Release stammt. SLSA legt die Level dafür fest.
• Releases nur im CI bauen. Hinter einem Release vom Laptop steht keine verlässliche Aufzeichnung.
• Ein Artefakt von Test bis Produktion nutzen. Stufen Sie das Getestete hoch, statt es neu zu bauen, damit die Aufzeichnung stimmt.

Nach dem Release

• Überwachen, was Sie ausgeliefert haben. Gleichen Sie die SBOMs unterstützter Releases laufend mit neuen Schwachstellen ab.
• Nicht nur nach CVSS priorisieren. Nutzen Sie CISA KEV, EPSS und Kontext. Siehe so priorisieren Sie Schwachstellen.
• Wissen, wie lange Sie exponiert waren. Die Build-Historie zeigt, welche Releases ein Paket enthielten und seit wann.
• Einen Plan haben, bevor Sie ihn brauchen. Legen Sie fest, wer sichtet, wer behebt und wer mit Kunden spricht. Siehe den Lebenszyklus des Schwachstellenmanagements.
• Mit einem realen Szenario üben. Fragen Sie, wie lange es dauern würde, jedes Release mit einem bestimmten Paket zu finden. Lautet die Antwort Tage, fangen Sie dort an.

Was zuerst zu tun ist

Wann	Was Sie tun
Diese Woche	Multi-Faktor-Authentifizierung, Lockfiles im CI, gepinnte GitHub Actions, Workflow-Tokens mit minimalen Rechten
Diesen Monat	SBOM aus jedem Release-Build, Abhängigkeitswarnungen mit einem Zuständigen, Secret-Scanning
Dieses Quartal	Regeln für den ausgehenden Datenverkehr von Builds, Überwachung ausgelieferter Releases, ein getesteter Reaktionsplan
Danach	Signierte Provenienz, eine formale Prüfung der Abdeckung von SLSA oder NIST SSDF, Lieferanten-SBOMs

Was davon CRACI übernimmt

CRACI deckt den Build ab und alles, was danach kommt. Als Ihr GitHub-Actions-Runner führt es jeden Job in einer eigenen isolierten virtuellen Maschine aus, zeichnet jedes Paket, das der Job lädt, in einer SBOM auf, kennzeichnet aus CI-Caches wiederhergestellte Pakete und setzt eine Egress-Richtlinie durch, die Verbindungen blockiert, die Ihr Build nicht braucht. Danach prüft es das Ausgelieferte laufend, zeigt, welche Builds ein verwundbares Paket enthielten, und kann Builds mit Policy-Gates blockieren.

Der Rest bleibt bei Ihren anderen Tools: CRACI scannt weder Quellcode noch Secrets, erkennt neue bösartige Pakete nicht anhand ihres Verhaltens und signiert weder SBOMs noch Provenienz. Was jede Lücke füllt, zeigt Tools für Software-Lieferkettensicherheit im Vergleich.

Best Practices für Software-Lieferkettensicherheit: häufig gestellte Fragen

Wie sichern Sie eine Software-Lieferkette ab?

Halten Sie mit einer SBOM aus jedem Release-Build fest, was Sie ausliefern, steuern Sie mit Lockfiles und Prüfungen, was hineinkommt, schützen Sie den Build, indem Sie Secrets und ausgehenden Datenverkehr begrenzen, und überwachen Sie das Veröffentlichte weiter.

Was sollte ein kleines Team zuerst tun?

Aktivieren Sie Multi-Faktor-Authentifizierung, installieren Sie im CI aus Lockfiles, pinnen Sie GitHub Actions auf Commit-Hashes und geben Sie Workflow-Tokens nur die Rechte, die sie brauchen. Diese Schritte sind eine Sache von Tagen und schließen gängige Angriffswege.

Wie verhindern Sie bösartige Pakete?

Kein einzelner Schritt schafft das. Übernehmen Sie neue Versionen verzögert, begrenzen Sie Install-Skripte und prüfen Sie neue Abhängigkeiten. Beschränkter ausgehender Datenverkehr von Builds begrenzt den Schaden, falls ein bösartiges Paket durchkommt.

Warum GitHub Actions auf einen Commit-Hash pinnen?

Weil ein Versions-Tag auf anderen Code verschoben werden kann. Ein vollständiger Commit-Hash verweist immer auf denselben Code, sodass ein gekapertes Tag Ihre Pipeline nicht erreicht.

Wie oft sollten Sie Ihre Lieferkette überprüfen?

Die Überwachung sollte kontinuierlich laufen. Überprüfen Sie Ihre Abhängigkeitsrichtlinie, Workflow-Berechtigungen und Ihren Reaktionsplan mindestens jährlich und nach jedem Vorfall in Ihrem Stack.