Lieferkette

Coding-Agenten installieren viele Pakete, und eine frisch kompromittierte Abhängigkeit ist einer der direktesten Wege, eine Sandbox zu vergiften. Der Bereich Lieferkette konfiguriert die Richtlinie pro Arbeitsbereich, die Bromure Agentic Coding auf jeden Paketabruf anwendet. Wie die Beschreibung des Bereichs selbst sagt: Bromure scannt jeden Paketabruf (npm, PyPI, Cargo, RubyGems, Maven, NuGet, Go-Module, Packagist) über den MITM auf dem Host und wendet diese Richtlinien an, bevor der Agent die Antwort sieht; die .npmrc / pip.conf in der VM kann diese Einstellungen nur weiter einschränken — sie kann sie nicht lockern. Verwenden Sie die paketbezogenen Zulassungslisten für punktuelle Ausnahmen.

Der Bereich gruppiert fünf unabhängig umschaltbare Ebenen: Alterssperre, OSV-Schwachstellenprüfung, Paketfilterung, Installationsskripte und Lockfile-gepinnte Installationen (scrollen Sie für die letzten drei). Diese Seite dokumentiert die Einstellungen; die vollständige Pipeline — Ökosystem-Abdeckung, das Sicherheitsprotokoll, Antwort-Header und Kompromittierungserkennung — wird im Kapitel zum Lieferketten-Schutz behandelt.

So funktioniert die Durchsetzung

Alle Prüfungen laufen im Proxy auf der Host-Seite, niemals innerhalb der VM. API-Schlüssel für Reputationsdienste (socket.dev, Delpi) werden nur auf dem Host gehalten und niemals in die VM exportiert. Wenn eine Prüfung auslöst, blockiert der Proxy den Download mit einer HTTP-451-Antwort, die einen Klartext-Grund enthält (zum Beispiel „npm-Paket [email protected] vor 4 Stunden veröffentlicht — Richtlinie verlangt mindestens 2 Tage"); npm, pip und cargo geben diesen Text wortgetreu aus, sodass sowohl der Agent als auch Sie genau sehen, warum eine Installation fehlgeschlagen ist. Blockierte Antworten tragen den Header X-Bromure-Block: supply-chain; umgeschriebene Antworten tragen X-Bromure-Rewritten: supply-chain.

Richtlinienänderungen werden live angewendet: Das Sichern des Arbeitsbereichs überträgt die neue Richtlinie sofort an laufende Sitzungen — kein VM-Neustart — und jede Änderung wird mit einer Zeile [supply-chain] policy engaged im Sicherheitsprotokoll bestätigt (Menü „Fenster" → Sicherheitsprotokoll…).

Hinweis: Pakete, die bereits im lokalen Cache von npm oder pip vorhanden sind, berühren niemals das Netzwerk, sodass für sie nichts geprüft oder protokolliert wird. Ein ruhiges Sicherheitsprotokoll während einer Installation kann einfach bedeuten, dass alles zwischengespeichert war.

Alterssperre

Die Alterssperre verweigert Paketversionen, die jünger als ein konfigurierbarer Schwellenwert sind, ausgehend von der Annahme, dass gerade veröffentlichte Releases am wahrscheinlichsten ein frisch kompromittiertes Paket sind. Sie ist die einzige standardmäßig aktivierte Ebene.

• Pakete verweigern, die jünger als der Schwellenwert sind — der Hauptschalter. Standardmäßig aktiviert.
• Mindestalter — der Schwellenwert in Tagen (Stepper, 0–90). Standard: 2 Tage.
• Ausgenommene Pakete — eine Zulassungsliste im Format npm:axios (ein Ökosystem) oder nur axios (jedes Ökosystem), ohne Beachtung der Groß-/Kleinschreibung. Klicken Sie auf Eintrag hinzufügen, um eine Zeile anzuhängen.

Gleitende Referenzen (pkg@latest, Semver-Bereiche) werden niemals hart blockiert: Der Proxy schreibt die Registry-Metadaten so um, dass zu frische Versionen aus Sicht des Agenten schlicht nicht existieren, und der Paketmanager löst auf die neueste zulässige Version auf. Nur gepinnte Referenzen auf zu frische Versionen erhalten die 451, unter Angabe des Alters des Pakets und des erforderlichen Mindestalters.

Hinweis: Maven, NuGet und Go-Module führen in ihren Standard-Metadatenantworten keine versionsspezifischen Zeitstempel, sodass die Alterssperre diese drei Ökosysteme derzeit nicht blockiert. npm, PyPI, Cargo, RubyGems und Packagist sind vollständig abgedeckt (für PyPI ruft Bromure die Veröffentlichungszeiten bei Bedarf über die PyPI-JSON-API ab).

OSV-Schwachstellenprüfung

Wenn Pakete auf api.osv.dev nachschlagen (kostenlos, kein Schlüssel erforderlich) aktiviert ist, werden Ökosystem, Paket und Version jedes heruntergeladenen Artefakts gegen die OSV-Datenbank geprüft — eine kostenlose Aggregation der GitHub Advisory Database, der PyPI-Advisories, der Schwachstellendatenbank von Go, RubySec und anderer. Jede Meldung mit einem Schweregrad auf oder über dem Schwellenwert Blockieren ab Schweregrad blockiert den Download mit einer 451.

• Standardmäßig deaktiviert — wie der Bereich anmerkt, sollte eine CVE mit niedrigem Schweregrad in einem transitiven Unterpaket keinen Arbeitsablauf unterbrechen.
• Blockieren ab Schweregrad bietet Niedrig und höher, Mittel und höher, Hoch und höher (der Standard) oder Nur kritisch.
• Deckt alle acht Ökosysteme ab; Prüfungen laufen beim Download des Artefakts, nicht bei Metadatenabrufen.

Paketfilterung

Das Optionsfeld Paketfilterung wählt einen Reputationsanbieter: Keiner, socket.dev oder Delpi. Die beiden Anbieter arbeiten unterschiedlich — socket.dev ist eine Vorabprüfung, die der Proxy konsultiert, bevor er einen Abruf durchlässt, während Delpi die npm-Registry vollständig ersetzt — daher schließen sie sich gegenseitig aus. Gespeicherte API-Schlüssel bleiben beim Wechsel erhalten, sodass das Umschalten zwischen Anbietern zerstörungsfrei ist.

socket.dev

Wenn socket.dev ausgewählt ist, fügen Sie ein API-Token in API-Schlüssel ein (der Link API-Schlüssel abrufen öffnet die Token-Seite von socket.dev). Beide untenstehenden Schalter bleiben deaktiviert, bis ein Schlüssel eingegeben ist, und ein leerer Schlüssel deaktiviert socket.dev vollständig, unabhängig von den Schaltern. Der Schlüssel wird nur auf der Host-Seite gespeichert und gelangt niemals in die VM.

• Kompromittierte Pakete blockieren (schädliche Installationsskripte, als Malware markiert, Typosquats, verdächtige Telemetrie) — blockiert bei angriffsförmigen Lieferketten-Risikosignalen: eindeutige Malware-Indikatoren bei jedem Schweregrad; störanfälligere Signale wie verschleierter Code, Installationsskripte, Typosquatting oder Shell-Zugriff nur, wenn socket.dev sie als hoch oder kritisch einstuft (sodass ein Paket mit einem harmlosen postinstall nicht blockiert wird). Standardmäßig deaktiviert.
• Pakete mit bekannten CVEs blockieren — blockiert anhand des Schwachstellen-Buckets von socket.dev auf oder über dem CVE-Blockierungsschwellenwert (Standard Hoch und höher; die Auswahl ist deaktiviert, bis dieser Schalter aktiviert ist). Standardmäßig deaktiviert.

Hinweis: socket.dev bietet keine Cargo-Unterstützung. Bei aktivierter socket.dev-Filterung liefert jedes crates.io-Artefakt kein Urteil und löst die unten beschriebene Haltestellung für nicht verifizierte Pakete aus — praktisch eine Abfrage pro Crate-Version. Deaktivieren Sie socket.dev für Rust-lastige Arbeitsbereiche, oder rechnen Sie damit, Abfragen zu beantworten.

Delpi

Wenn Delpi ausgewählt und ein API-Schlüssel eingegeben ist (der Link API-Schlüssel abrufen öffnet landh.tech), leitet der Proxy jede npm-Registry-Anfrage — Metadaten, Tarballs, Audit, alles, was an registry.npmjs.org gerichtet ist — an Delpis npm-kompatible sichere Registry unter depi-npm-proxy.landh.tech um und hängt Ihren Schlüssel als vom Host injiziertes Bearer-Token an. Delpi liefert vorab geprüfte Pakete, sodass statt einer paketbezogenen Abfrage die gesamte Registry ersetzt wird. Die übrigen Ebenen (Alterssperre, OSV, Skript-Entfernung) gelten weiterhin obendrauf: Delpi ersetzt socket.dev, nicht die lokale Richtlinie.

Solange das Schlüsselfeld leer ist, liest sich eine orange Warnung als Geben Sie einen API-Schlüssel ein — ohne einen bleibt Delpi deaktiviert. Wenn Delpi den Schlüssel ablehnt, schlägt die npm-Installation mit einem klaren Bromure-Fehler fehl, die Ablehnung wird im Sicherheitsprotokoll aufgezeichnet und eine einmalige Warnung ausgelöst. Delpi betrifft nur npm; andere Ökosysteme bleiben unberührt.

Installationsskripte

preinstall / install / postinstall / prepare aus npm-Tarballs im Flug entfernen entfernt die Hooks, die schädliche npm-Pakete verwenden, um Code zur Installationszeit auszuführen. Bromure schreibt den Tarball im laufenden Betrieb um — entfernt die Skript-Schlüssel aus der package.json des Pakets, berechnet die Tar-Prüfsumme neu, komprimiert erneut mit gzip — und bereinigt die Integritäts-Hashes aus den Registry-Metadaten, sodass npms eigene Verifizierung für ungepinnte Installationen weiterhin erfolgreich ist. Entfernungen werden orange im Sicherheitsprotokoll protokolliert; bei jedem Parsing-Fehler wird der ursprüngliche Tarball unverändert durchgelassen (diese Ebene versagt offen, statt eine wohlgeformte Installation zu unterbrechen).

Binding-Compiler, die Installationsskripte tatsächlich benötigen (better-sqlite3, node-canvas, …), gehören in Installationsskripte zulassen für, Format npm:better-sqlite3.

Standardmäßig deaktiviert; nur npm (PyPI-sdists werden niemals umgeschrieben — setup.py ist beliebiger Code).

Lockfile-gepinnte Installationen

Lockfile-gepinnte Installationen (npm ci, pip --require-hashes) pinnen die Integritäts-Hashes der Tarballs im Lockfile, sodass Bromure diese Tarballs nicht umschreiben kann, ohne die Verifizierung zu brechen. Standardmäßig werden sie unverändert und stillschweigend durchgelassen.

Aktivieren Sie Vor dem unveränderten Durchlassen von Lockfile-gepinnten Tarballs nachfragen (npm ci, pip --require-hashes), um stattdessen gefragt zu werden: Der erste Lockfile-gepinnte Abruf in einem Stapel öffnet einen Host-Dialog mit dem Titel Pass through npm ci (lockfile-pinned install) from workspace "<name>"? mit den Auswahlmöglichkeiten 15 Minuten lang zulassen, Einmal zulassen, Für den Rest der Sitzung zulassen und Nicht zulassen. Der gesamte Stapel folgt der Entscheidung (gleichzeitige Abrufe werden auf einer Abfrage zusammengefasst); eine Ablehnung blockiert mit einer 451 und wird 60 Sekunden lang gemerkt.

Hinweis: Obwohl die Beschriftung pip --require-hashes erwähnt, ist die Erkennung derzeit nur für npms npm ci implementiert — hash-gepinnte pip-Installationen lösen die Abfrage nicht aus.

Wenn eine Reputationsquelle nicht erreichbar ist

Wenn eine aktivierte Reputationsquelle (OSV oder socket.dev) kein Urteil liefern kann — Netzwerk ausgefallen, ratenbegrenzt, Authentifizierungsfehler, nicht unterstütztes Ökosystem — versagt Bromure geschlossen, statt stillschweigend zuzulassen. Der Download wird angehalten und ein Dialog fragt, pro Paket und Version, ob das nicht verifizierte Paket akzeptiert werden soll; eine Ablehnung blockiert mit einer 451. Genehmigungen werden pro package@version geführt, sodass eine einzelne Antwort nicht einen gesamten Abhängigkeitsgraphen abdecken kann.

Dies ist ein bewusster Schutz gegen einen Angreifer, der Ratenbegrenzungen herbeiführt, um Pakete einzuschleusen. Es bedeutet auch, dass vollständig offline durchgeführte Arbeit mit aktiviertem OSV oder socket.dev für jedes nicht zwischengespeicherte Paket eine Abfrage auslöst — deaktivieren Sie diese Ebenen für die Offline-Nutzung. In Headless-SSH/CLI-Sitzungen wird dieselbe Frage innerhalb des tmux des Arbeitsbereichs gestellt; keine Antwort bedeutet Ablehnung.

Einstellungsreferenz

Hier eingegebene API-Schlüssel liegen in der profile.json des Arbeitsbereichs auf dem Host (niemals in der VM); alle Reputationsaufrufe stammen vom Host-Proxy. Für das Sicherheitsprotokoll, die ökosystemspezifischen Interception-Details und den Kompromittierungserkennungs-Alarm, der mit diesen Richtlinien einhergeht, siehe das Kapitel zum Lieferketten-Schutz.