Policy-Gates: Schwachstellen vor der Produktion stoppen

Warum Warnungen nicht ausreichen

Die meisten Sicherheitstools melden erst im Nachhinein. Ein Befund landet in einem Dashboard, jemand sichtet ihn, ein Ticket geht an das zuständige Team, und währenddessen läuft das Release weiter. Wurde der Befund übersehen oder hat der Scan das Paket nie gesehen, ist die Schwachstelle in Produktion, bevor irgendjemand etwas entscheidet.

Policy-Gates können einen Build auch in Echtzeit stoppen, bevor das Release weiterläuft.

Was ein Gate stoppen kann

Regel	Was passiert
Befunde im Build	Ein Build mit Befunden, die Ihre Richtlinie ausschließt, wird blockiert.
Eine bestimmte CVE	Sobald Ihr Team entschieden hat, dass eine CVE nicht ausgeliefert werden darf, werden Builds blockiert, die sie enthalten.
Ein bekanntes bösartiges Release	Ein bösartiges Release mit veröffentlichter CVE, etwa xz, wird markiert und lässt sich auf dieselbe Weise blockieren.
Eine Lizenz	Lizenzrichtlinien können einen Build blockieren, der eine von Ihnen ausgeschlossene Lizenz einbringt.

Ein Gate ist nur so gut wie das, was es sieht

Ein Gate, das auf einem Lockfile-Scan beruht, kann nur blockieren, was im Lockfile steht. CRACI sieht den Datenverkehr, der in jeden Build hineinkommt. Seine Gates arbeiten deshalb mit dem, was der Job wirklich geladen hat:

• Transitive Abhängigkeiten auf jeder Ebene. Siehe transitive Abhängigkeiten.
• Versteckte Abhängigkeiten, etwa Code, den Install-Skripte herunterladen, Rust-Build-Skripte, die zur Build-Zeit Dateien laden, und das Basis-Image eines Container-Builds.
• Pakete aus einem CI-Cache, die aufgezeichnet und als gecacht markiert werden.

Jede Komponente in einer CRACI-SBOM war im Build, ein Gate arbeitet also nie mit einem Paket, das nur abgeleitet wurde. Die Begründung lesen Sie unter Build-Time-SBOMs.

Gates und Egress-Richtlinien erfüllen unterschiedliche Aufgaben

Risiko	Was es stoppt
Eine Abhängigkeit mit bekannter CVE, die Sie ausgeschlossen haben	Policy-Gate
Eine Lizenz, die Sie ausgeschlossen haben	Policy-Gate
Eine Verbindung zu einem Host, den der Build nicht braucht	Egress-Richtlinie, auf Default Deny gesetzt
Ein neues bösartiges Paket ohne bisheriges Advisory	Wird erst markiert, wenn ein Advisory existiert. Eine auf Default Deny gesetzte Egress-Richtlinie hindert es trotzdem daran, Ihre Secrets an einen Host zu senden, den der Build nicht braucht.

Wenn eine neue CVE auftaucht

1. CRACI bewertet überwachte SBOMs neu und markiert, was betroffen ist.
2. Ihr Sicherheitsteam sichtet den Befund und gibt ihn an das Team weiter, das für die Behebung zuständig ist.
3. Die Build-Historie zeigt, welche Builds die CVE enthielten und damit, wie lange Sie betroffen waren.
4. Das zuständige Team liefert die Behebung aus, und ein Policy-Gate hält die CVE aus späteren Builds heraus.

Die Behebung bleibt Ihre Sache. Das Gate sorgt dafür, dass sie Bestand hat. Siehe Schwachstellenverfolgung.

Was Gates nicht leisten

• Keine Erreichbarkeitsanalyse. Ein Gate richtet sich danach, ob ein Paket im Build ist, nicht danach, ob Ihr Code die verwundbare Funktion aufruft.
• Keine Malware-Erkennung. Advisories steuern das Gate, ein brandneues bösartiges Paket fängt es also nicht ab.
• Kein Code-Scanning. SAST und Secrets-Scanning gehören bewusst nicht zum Umfang, und viele hervorragende Tools arbeiten neben CRACI.

Policy-Gates: häufig gestellte Fragen

Was ist ein Policy-Gate?

Eine Regel, die einen Build stoppt, wenn er gegen Ihre Richtlinie verstößt. Statt ein Problem zu melden, das sich später jemand ansieht, verhindert das Gate, dass der Build weiterläuft.

Worin unterscheidet sich ein Policy-Gate von einer Scanner-Warnung?

Eine Warnung ist darauf angewiesen, dass jemand rechtzeitig darauf reagiert. Ein Gate handelt von selbst. Die Gates von CRACI arbeiten außerdem mit einer Aufzeichnung dessen, was der Build geladen hat, und können so Pakete erfassen, die ein Lockfile-Scan nie sehen würde.

Kann ich eine bestimmte CVE blockieren?

Ja. Ein Policy-Gate kann Builds blockieren, die eine bestimmte CVE enthalten, sodass eine Schwachstelle, über die Ihr Team entschieden hat, nicht in einem späteren Build zurückkehrt.

Kann ein Gate eine Lizenz blockieren?

Ja. Jedes aufgezeichnete Paket bringt seine deklarierte Lizenz mit, und Lizenzrichtlinien können einen Build aufgrund einer Lizenz blockieren.

Stoppt ein Gate neue Malware?

Nicht von sich aus. Ein bekanntes bösartiges Release mit veröffentlichter CVE wird wie jede andere Schwachstelle markiert, und ein Gate kann Builds blockieren, die es enthalten. Ein neues bösartiges Paket wird erst markiert, wenn ein Advisory existiert. In diesem Zeitfenster begrenzt eine auf Default Deny gesetzte Egress-Richtlinie den Schaden.

Welche CI-Systeme funktionieren mit Policy-Gates?

GitHub Actions, auf CRACI-Runnern. Weitere CI-Systeme sind auf der Roadmap.