Lieferketten-Schutz

Ein autonomer Coding-Agent installiert ständig Pakete — das Aufsetzen eines Projekts zieht Hunderte von Abhängigkeiten heran, ohne dass ein Mensch jemals einen Namen liest, geschweige denn ein Changelog. Damit ist die Paket-Registry der mit Abstand breiteste Kanal, über den feindseliger Code in die Sandbox gelangen kann: ein Tippfehler-Squat-Name, ein frisch gekaperter Release oder ein bösartiges postinstall-Skript läuft mit den vollen Berechtigungen des Agenten in dem Moment, in dem npm install abgeschlossen ist. Bromure Agentic Coding behandelt jeden Paketabruf als nicht vertrauenswürdige Eingabe und wendet darauf eine Richtlinie pro Arbeitsbereich auf dem Host an, bevor auch nur ein Byte die VM erreicht.

Dieses Kapitel erklärt, was abgefangen wird, jede Prüfung in der Pipeline, was geschieht, wenn eine Prüfung anschlägt, und wie sich die Ergebnisse im Sicherheitsprotokoll lesen lassen. Die feldweise Einstellungsreferenz für den Bereich findet sich unter Lieferketten-Einstellungen.

Warum Paketinstallationen die Angriffsfläche sind

Die Sandbox enthält den Agenten bereits: Er kann Ihren Mac nicht berühren, und seine Zugangsdaten sind Köder (siehe Zugangsdaten). Was die Sandbox von sich aus nicht kann, ist die Herkunft des Codes zu beurteilen, den der Agent hereinzieht. Lieferkettenangriffe nutzen genau diese Lücke aus:

• Kaperungen frischer Releases. Das Konto eines Betreuers wird kompromittiert und eine bösartige Version veröffentlicht. Solche Versionen werden in der Regel innerhalb von Stunden bis Tagen erkannt und zurückgezogen — deshalb weist die Altersgrenze Versionen zurück, die jünger als ein Schwellenwert sind.
• Bekannt verwundbare Versionen. Der Agent löst eine Abhängigkeit zu einer Version mit einer veröffentlichten Warnmeldung auf. Die OSV-Prüfung fängt diese ab.
• Malware, Tippfehler-Squats und bösartige Installationsskripte. Pakete, die von Anfang an bösartig konzipiert sind. Die Anbieter socket.dev und Delpi melden oder filtern diese, und das Entfernen von Installationsskripten beseitigt den häufigsten Ausführungsweg gänzlich.

Die Durchsetzung erfolgt konzeptbedingt auf der Host-Seite. Der Proxy wendet die Richtlinie auf die Antwort an, bevor der Agent sie sieht, sodass nichts, was innerhalb der VM läuft — einschließlich eines vollständig kompromittierten Agenten — die Regeln lockern kann. Die .npmrc und pip.conf innerhalb der VM können nur weiter einschränken, was der Proxy bereits ausgeliefert hat, niemals ausweiten. API-Schlüssel für Reputationsdienste (socket.dev, Delpi) werden ausschließlich auf dem Host gehalten und niemals in die VM exportiert.

Wie das Abfangen funktioniert

Jede Netzwerkanfrage, die die VM stellt, durchläuft den host-seitigen MITM-Proxy (siehe Konzepte). Der Proxy erkennt Anfragen an die großen Paket-Registries und klassifiziert jede einzelne:

• Metadaten — die Versionsauflistung eines Pakets (ein npm-Packument, PyPIs JSON-API oder /simple/-Index, ein Cargo-Sparse-Index-Eintrag usw.). Die Altersgrenze wirkt hier, indem sie die Auflistung umschreibt.
• Artefakt — die herunterladbare Datei für eine bestimmte Version: ein npm-.tgz, ein Python-Wheel oder -sdist, ein .crate, .gem, .nupkg oder ein Go-Modul-.zip. OSV-Abfragen, socket.dev-Prüfungen, das Entfernen von Skripten und harte Blockaden geschehen allesamt zum Zeitpunkt des Artefaktabrufs.
• Durchleitung — alles Übrige auf diesen Hosts (Suche, Authentifizierung). Unberührt.

Das Abfangen erfolgt automatisch, sobald mindestens eine Lieferketten-Ebene für den Arbeitsbereich aktiviert ist (oder der Arbeitsbereich bei bromure.io registriert ist, in welchem Fall Abrufe für Telemetrie beobachtet werden, selbst wenn jede Durchsetzungsebene ausgeschaltet ist). Innerhalb der VM gibt es nichts zu installieren oder zu konfigurieren.

Hinweis: Pakete, die bereits im lokalen Cache von npm oder pip vorhanden sind, erreichen niemals das Netzwerk, sodass für sie nichts geprüft — oder protokolliert — wird. Ein stilles Sicherheitsprotokoll während einer Installation kann schlicht bedeuten, dass alles aus dem Cache kam.

Verdikte: erlauben, umschreiben, blockieren, halten

Lieferketten-Ebenen sind einzelne An/Aus-Schalter, jeweils mit einer festen Aktion — es gibt für diesen Bereich keinen globalen Blockieren-/Warnen-/Erlauben-Modus. (Der dreistufige Protokoll-/Fragen-/Blockieren-Auswahlknopf, den Sie vielleicht aus Prompt-Injection kennen, und die Durchsetzungsmodi in Schutzmechanismen sind getrennte Systeme.) Jeder Abruf endet in einem von vier Ergebnissen:

Eine 451-Blockade trägt einen Klartext-Rumpf, der mit Bromure Supply-Chain Security blocked this request: beginnt, gefolgt von dem genauen Grund, zum Beispiel:

Bromure Supply-Chain Security blocked this request: npm package [email protected]
published 4 hours ago — policy requires 2 days minimum

npm, pip, cargo und die anderen Paketmanager geben diesen Rumpf wortwörtlich in ihrer Fehlerausgabe aus, sodass sowohl der Agent als auch Sie genau sehen, warum eine Installation fehlschlug — und der Agent kann dies oft selbstständig umgehen (etwa, indem er eine ältere Version pinnt). Der Status 451 wurde bewusst gewählt, damit sich Lieferketten-Blockaden auf einen Blick von den 403ern unterscheiden lassen, die Schutzmechanismen verwenden.

Abdeckung nach Ökosystem

Der Proxy fängt acht Paket-Ökosysteme ab. Nicht jede Prüfung unterstützt jedes Ökosystem:

Zwei erwähnenswerte Lücken:

• Altersgrenze — Maven, NuGet, Go. Diese drei Ökosysteme führen in ihren Standard-Metadatenantworten keine Veröffentlichungszeitstempel pro Version, sodass ihre Metadaten ungefiltert durchgeleitet werden und die Artefakt-Absicherung keine Daten hat, mit denen sie agieren könnte. Die Altersgrenze blockiert sie heute faktisch nicht; npm, PyPI, Cargo, RubyGems und Packagist sind vollständig abgedeckt.
• socket.dev — Cargo. socket.dev bietet keine Cargo-Unterstützung. Bei aktivierter socket.dev-Filterung liefert jedes crates.io-Artefakt kein Verdikt und löst daher den Zustimmungshinweis für ungeprüfte Pakete aus (siehe Offline- und eingeschränktes Verhalten). Wenn Ihr Arbeitsbereich viel Rust-Arbeit leistet, beantworten Sie entweder die Hinweise oder wählen Sie einen anderen Anbieter.

Die Altersgrenze

Die Altersgrenze weist Paketversionen zurück, die jünger als eine konfigurierbare Anzahl von Tagen sind, nach der Überlegung, dass ein frisch veröffentlichter Release am ehesten ein gerade eben gekapertes Paket ist — bösartige Versionen werden in der Regel schnell gemeldet und zurückgezogen, und das Abwarten dieses Zeitfensters kostet die reguläre Entwicklung fast nichts. Es ist die einzige standardmäßig aktivierte Ebene, mit einem Minimum von 2 Tagen.

Sie arbeitet über zwei zusammenwirkende Mechanismen:

• Umschreiben der Metadaten. Der Proxy entfernt zu frische Versionen aus der Versionsauflistung der Registry und richtet latest und andere Dist-Tags auf die neueste verbleibende Version neu aus. Fließende Referenzen — pkg@latest, Semver-Bereiche — werden daher niemals hart blockiert: Der Paketmanager löst stillschweigend zur neuesten Version auf, die alt genug ist, um durchzukommen. Aus Sicht des Agenten existieren Versionen, die jünger als der Schwellenwert sind, schlicht noch nicht.
• Absicherung beim Artefaktabruf. Jede Veröffentlichungszeit pro Version, die der Proxy in den Metadaten sieht, wird im Speicher zwischengehalten (bis zu 50.000 Einträge). Wenn der Agent dann direkt eine gepinnte, zu frische Version anfordert, wird der Abruf mit einer 451 blockiert, die das tatsächliche Alter des Pakets und das erforderliche Minimum angibt. Für pip — dessen standardmäßiger PEP-503-HTML-Index keine Zeitstempel trägt — führt Bromure eine bedarfsgesteuerte Abfrage von https://pypi.org/pypi/<pkg>/<version>/json durch, um die Veröffentlichungszeit zu ermitteln.

Zum Konfigurieren öffnen Sie den Lieferkette-Bereich des Arbeitsbereichs und verwenden Sie die Gruppe Altersgrenze:

1. Schalten Sie Pakete zurückweisen, die jünger als der Schwellenwert sind um.
2. Legen Sie Mindestalter: mit dem Schrittzähler fest (0–90 Tage).
3. Wenn ein bestimmtes Paket sofort installierbar sein muss — etwa, weil Ihr eigenes Team es veröffentlicht — fügen Sie es unter Ausgenommene Pakete mit der Schaltfläche Eintrag hinzufügen hinzu. Einträge verwenden das Allowlist-Format: npm:axios beschränkt die Ausnahme auf ein Ökosystem, ein bloßes axios passt auf den Paketnamen in jedem Ökosystem. Der Abgleich unterscheidet nicht zwischen Groß- und Kleinschreibung.

Tipp: npm-Metadatenanfragen werden stillschweigend auf das vollständige Packument hochgestuft, damit die Grenze Veröffentlichungszeiten sehen kann — für npms abgekürztes Metadatenformat müssen Sie nichts weiter tun.

OSV-Schwachstellenprüfung

Die OSV-Prüfung schlägt das Ökosystem, das Paket und die Version jedes heruntergeladenen Artefakts auf api.osv.dev nach — der kostenlosen Open-Source-Vulnerabilities-Datenbank, die die GitHub Advisory Database, PyPI-Advisories, Gos Schwachstellendatenbank, RubySec und weitere zusammenführt. Wenn eine Warnmeldung für genau diese Version auf oder über Ihrem gewählten Schweregrad liegt, wird der Download mit einer 451 blockiert. Sie deckt alle acht Ökosysteme ab und erfordert keinen API-Schlüssel.

Der Schweregrad wird aus dem GHSA-Label übernommen, wenn die Warnmeldung eines hat; andernfalls berechnet Bromure den CVSS-v3-Basiswert aus der Vektor-Zeichenkette der Warnmeldung.

In der Gruppe OSV-Schwachstellenprüfung:

1. Schalten Sie Pakete auf api.osv.dev nachschlagen (kostenlos, kein Schlüssel erforderlich) um.
2. Wählen Sie Blockieren ab Schweregrad: — Niedrig und höher, Mittel und höher, Hoch und höher oder Nur kritisch.

Die Prüfung ist standardmäßig ausgeschaltet, und der Schweregrad-Schwellenwert ist standardmäßig Hoch und höher — wie der Bereich selbst anmerkt, sollte ein CVE mit niedrigem Schweregrad in einem transitiven Unterpaket keinen Arbeitsablauf unterbrechen. Abfragen laufen nur bei Artefakt-Downloads (nicht bei Metadatenabrufen), Ergebnisse werden für die Laufzeit der App im Speicher zwischengehalten, es laufen höchstens 16 Abfragen parallel, und vorübergehende Netzwerkfehler werden bis zu 5 Mal mit Backoff wiederholt. Wenn OSV überhaupt nicht erreichbar ist, wird das Paket zu Ihrer Zustimmung gehalten, statt es stillschweigend zu erlauben — siehe Offline- und eingeschränktes Verhalten.

Paketfilterung: socket.dev und Delpi

Die Gruppe Paketfilterung wählt über einen sich gegenseitig ausschließenden Auswahlknopf einen Reputationsanbieter aus: Keiner, socket.dev oder Delpi. Die beiden Anbieter arbeiten grundlegend verschieden — socket.dev ist eine Vorab-Abfrage, die der Proxy konsultiert, bevor er einen Abruf durchlässt; Delpi ersetzt die npm-Registry vollständig. Konzeptbedingt kann nur einer gleichzeitig aktiv sein (beide auszuführen würde jede Installation doppelt filtern), und die Auswahl von Keiner deaktiviert beide, während gespeicherte Schlüssel erhalten bleiben. Welchen Anbieter Sie auch wählen, die anderen Ebenen dieses Kapitels — Altersgrenze, OSV, Skript-Entfernung — greifen weiterhin obendrauf.

Die Voreinstellung ist Keiner. Arbeitsbereiche, die vor Einführung des Auswahlknopfes erstellt wurden und bereits einen socket.dev-Schlüssel besitzen, werden automatisch als socket.dev abgeleitet.

socket.dev

socket.dev ist ein kommerzieller Paket-Reputationsdienst. Mit ausgewähltem socket.dev und eingegebenem API-Schlüssel prüft der Proxy jeden Artefakt-Download gegen socket.devs Issue-API, bevor er ihn ausliefert. Er unterstützt npm, PyPI, Go, Maven, RubyGems, NuGet und Packagist — aber nicht Cargo (siehe Abdeckung nach Ökosystem).

Sie bringen Ihren eigenen Schlüssel mit: Klicken Sie neben dem Feld API-Schlüssel: auf Einen API-Schlüssel besorgen (es öffnet socket.dev/dashboard/settings/api-tokens), erstellen Sie ein Token und fügen Sie es in das sichere Feld ein. Beide Blockier-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 host-seitig in der profile.json des Arbeitsbereichs gespeichert und gelangt niemals in die VM; alle Abfragen gehen von Ihrem Mac aus.

Zwei unabhängige Blockaden stehen zur Verfügung:

• Kompromittierte Pakete blockieren (bösartige Installationsskripte, als Malware markiert, Tippfehler-Squats, verdächtige Telemetrie) — schlägt bei socket.devs angriffsförmigen Lieferketten-Risiko-Issues an. Eindeutige Malware-Signale (Malware, bekannte Malware, per GPT erkannte Malware, Troll-Pakete, kompromittierte SSH-Schlüssel) blockieren bei jedem Schweregrad. Verrauschtere angriffsförmige Signale — verschleierter Code, verdächtige Zeichenketten, Installationsskripte, Tippfehler-Squatting, Shell-Zugriff, ungewöhnliche HTTPS-Nutzung — blockieren nur, wenn socket.dev sie als hoch oder kritisch einstuft, sodass ein Paket mit einem harmlosen postinstall nicht erfasst wird. Reine Qualitäts- und Attributsignale (neuer Autor, Lesen von Umgebungsvariablen, Netzwerkzugriff, Telemetrie) blockieren bewusst niemals.
• Pakete mit bekannten CVEs blockieren — schlägt bei socket.devs Schwachstellen-Kategorie auf oder über dem Auswahlfeld CVE-Blockierschwelle: an (dieselben vier Stufen wie OSV; Voreinstellung Hoch und höher).

Beide Blockaden sind standardmäßig ausgeschaltet. Ergebnisse werden für die Laufzeit der App zwischengehalten, es laufen höchstens 16 Aufrufe parallel, und vorübergehende Fehlschläge werden 5 Mal mit Backoff wiederholt. Authentifizierungsfehler werden im Sicherheitsprotokoll mit dem HTTP-Status und einer Vorschau des Antwort-Rumpfs sichtbar gemacht.

Hinweis: Wenn Sie OSV und socket.devs CVE-Blockade zusammen aktivieren, prüfen beide jedes Artefakt — das ist zulässig (es sind unterschiedliche Ebenen), nur redundant für die CVE-Abdeckung. Viele Benutzer koppeln stattdessen socket.devs Blockade kompromittierter Pakete mit der kostenlosen OSV-Prüfung.

Delpi

Delpi ist eine einsatzfertige sichere npm-Registry von Lupin & Holmes (landh.tech), die vorab geprüfte Pakete ausliefert. Statt Pakete nachzuschlagen, leitet Bromure jede npm-Registry-Anfrage — Metadaten, Tarballs, Audit, alles, was an registry.npmjs.org oder *.npmjs.org adressiert ist — an Delpis npm-kompatible Filter-Registry unter depi-npm-proxy.landh.tech:443 um, hängt Ihren Schlüssel als Authorization: Bearer-Header an und entfernt jeden Authorization-Header, den der Gast gesendet hat. Delpi schreibt Tarball-URLs in seinen Packuments so um, dass sie auf sich selbst zeigen, sodass diese Folgeaufrufe den Schlüssel ebenfalls host-seitig injiziert bekommen.

Zum Aktivieren wählen Sie Delpi im Auswahlknopf und fügen Ihren Schlüssel in das sichere Feld API-Schlüssel: ein. Solange das Feld leer ist, lautet eine orangefarbene Warnung Geben Sie einen API-Schlüssel ein — Delpi bleibt ohne einen aus. Jede umgeleitete Anfrage wird im Sicherheitsprotokoll protokolliert:

[delpi] GET registry.npmjs.org/… → https://depi-npm-proxy.landh.tech

Die Fehlerbehandlung ist explizit statt still:

• 401 (Schlüssel abgelehnt). Bromure setzt einen klaren Klartext-Fehler ein, den npm ausgibt („Bromure: the Delpi registry rejected the configured API key…“, mit dem Header X-Bromure-Block: delpi-auth), protokolliert ihn und löst pro Kombination aus Arbeitsbereich und Schlüssel einen einmaligen GUI-Hinweis aus: „Delpi rejected your API key“. Kopflose SSH-/TUI-Sitzungen erhalten den GUI-Hinweis nicht; sie verlassen sich auf die Protokollzeile und den umgeschriebenen npm-Fehler.
• 403 (Paket von Delpi blockiert oder Schlüssel dafür nicht berechtigt). Wird protokolliert und unverändert durchgeleitet, sodass npm Delpis eigenen Ablehnungstext meldet.

Delpi betrifft nur npm — die anderen sieben Ökosysteme bleiben davon unberührt. Delpi ersetzt socket.dev im Auswahlknopf, nicht Ihre lokale Richtlinie: Die Altersgrenze, die OSV-Prüfung und die Skript-Entfernung laufen weiterhin auf dem, was Delpi ausliefert.

Entfernen von Installationsskripten

npms preinstall-, install-, postinstall- und prepare-Hooks führen zur Installationszeit beliebigen Code aus und sind das Arbeitspferd realer npm-Malware. Mit aktiviertem preinstall / install / postinstall / prepare im laufenden Betrieb aus npm-Tarballs entfernen (in der Gruppe Installationsskripte) schreibt der Proxy jeden npm-Tarball im Durchlauf um: Er entpackt das .tgz per gunzip, lokalisiert die oberste package/package.json, entfernt diese vier Skript-Schlüssel, berechnet die Tar-Header-Prüfsumme neu und komprimiert erneut per gzip.

Da sich die Tarball-Bytes ändern, entfernt der Proxy außerdem dist.integrity und dist.shasum aus den Registry-Metadaten des Pakets, sodass npm den Hash selbst aus dem bereinigten Tarball berechnet und seine Verifizierung für ungepinnte Installationen weiterhin gelingt. Jede Entfernung wird protokolliert („stripped install scripts from“ das Paket und die Version, in Orange dargestellt); Tarballs, die inspiziert und für sauber befunden wurden, werden nur mit dem Header X-Bromure-Rewritten: supply-chain gekennzeichnet. Bei jedem Parse-Fehler wird der ursprüngliche Tarball unberührt durchgeleitet — diese Ebene versagt offen, weil sie niemals eine wohlgeformte Installation lahmlegen darf.

Manche Pakete benötigen tatsächlich Installationsskripte — native Binding-Compiler wie better-sqlite3 oder node-canvas. Fügen Sie diese unter Installationsskripte erlauben für hinzu (Format npm:better-sqlite3), und sie behalten ihre Hooks.

Der Schalter ist standardmäßig ausgeschaltet, und es gelten zwei Einschränkungen:

• Nur npm. PyPI-sdists werden nicht umgeschrieben — setup.py ist beliebiger Code, sodass eine Entfernung dort nicht machbar ist.
• Nur ungepinnte Installationen. Ein Tarball, dessen Integritäts-Hash in package-lock.json gepinnt ist, kann nicht umgeschrieben werden, ohne die Verifizierung fehlschlagen zu lassen. Dieser Fall wird von der nächsten Ebene geregelt.

Lockfile-gepinnte Installationen

Eine lockfile-gepinnte Installation — npm ci — pinnt den Integritäts-Hash jedes Tarballs in der Lockfile. Bromure kann diese Tarballs nicht umschreiben, ohne die Hash-Verifizierung zu brechen, sodass seine einzigen Optionen darin bestehen, sie unverändert durchzuleiten oder zu blockieren. Standardmäßig werden sie stillschweigend durchgeleitet.

Wenn Sie ein Mitspracherecht wünschen, aktivieren Sie Vor dem unveränderten Durchleiten lockfile-gepinnter Tarballs nachfragen (npm ci, pip --require-hashes) in der Gruppe Lockfile-gepinnte Installationen. Der erste lockfile-gepinnte Abruf in einem Stapel (für npm über den Anfrage-Header npm-command: ci erkannt) lässt dann einen Host-Zustimmungsdialog aufpoppen, betitelt mit Durchleitung von npm ci (lockfile-gepinnte Installation) aus Arbeitsbereich „…“?, mit den Schaltflächen 15 Minuten erlauben, Einmal erlauben, Für den Rest der Sitzung erlauben und Nicht erlauben. Der gesamte Schwall gleichzeitiger Abrufe fällt auf diesen einen Hinweis zusammen und folgt Ihrer Entscheidung; eine Ablehnung blockiert den Abruf mit einer 451, und die Ablehnung wird 60 Sekunden lang gemerkt, sodass Wiederholungen nicht erneut nachfragen.

Hinweis: Obwohl das UI-Label pip --require-hashes erwähnt, ist die Erkennung derzeit nur für npms npm-command: ci-Header implementiert — hash-gepinnte pip-Installationen lösen den Hinweis nicht aus. (Sie werden auch niemals umgeschrieben, da PyPI-Artefakte nie verändert werden.)

Zustimmungshinweise und Erteilungen

Alle Lieferketten-Wege, die den Benutzer fragen — die Lockfile-Durchleitung und das unten beschriebene Halten ungeprüfter Pakete — laufen über einen gemeinsamen Zustimmungs-Broker mit Schwall-Bündelung: gleichzeitige Anfragen für denselben Bereich warten auf einen einzigen Dialog, statt Hinweise zu stapeln. Jeder Hinweis bietet dieselben vier Entscheidungen:

Aktive Erteilungen und Ablehnungen werden als Lieferketten-Entscheidungen — getrennt von den Schutzmechanismus-Entscheidungen — in der Genehmigungs-Oberfläche aufgeführt (dem Bereich Fenster → Zugangsdaten-Genehmigungen…), wo Sie eine Erteilung vorzeitig widerrufen können. Erteilungen bestehen nur im Speicher und überdauern einen Neustart der App nicht.

In entfernten SSH-/CLI-Sitzungen gibt es keinen GUI-Dialog: dieselbe Frage wird als Auswahl innerhalb des tmux des Arbeitsbereichs dargestellt. Keine Antwort bedeutet Ablehnung. Siehe Fernzugriff.

Die Richtlinie konfigurieren

Die Lieferketten-Richtlinie wird pro Arbeitsbereich konfiguriert, im Lieferkette-Bereich des Fensters Arbeitsbereich bearbeiten (das gelbe Versandkarton-Symbol in der Seitenleiste). Die vollständige feldweise Referenz findet sich unter Lieferketten-Einstellungen; die Voreinstellungen auf einen Blick:

Drei betriebliche Details:

• Änderungen greifen live. Das Sichern des Arbeitsbereichs schiebt die neue Richtlinie sofort an laufende Sitzungen — der Proxy liest sie pro Anfrage, sodass niemals ein VM-Neustart nötig ist. Jede neue oder geänderte Richtlinie wird mit einer einzeiligen Zusammenfassung im Sicherheitsprotokoll bestätigt, zum Beispiel:

  [supply-chain] policy engaged for 1a2b3c4d: age-gate=2d osv=high socket.dev=compromised+cve=high strip-scripts
  

  Fehlkonfigurationen werden direkt in dieser Zusammenfassung benannt: socket.dev=key-set-but-no-toggle bedeutet, dass ein Schlüssel eingegeben ist, aber keine der beiden Blockaden aktiviert ist, und delpi=selected-but-no-key bedeutet, dass Delpi ausgewählt, aber mangels Schlüssel ausgeschaltet ist.

• Wo sie gespeichert wird. Die Richtlinie liegt in der profile.json des Arbeitsbereichs unter ~/Library/Application Support/BromureAC/profiles/<id>/ (nur Nicht-Standard-Felder werden geschrieben). Die API-Schlüssel für socket.dev und Delpi werden dort ebenfalls gespeichert — ausschließlich host-seitig, in der Oberfläche als sichere Felder dargestellt und niemals in die VM kopiert. Es gibt keine lieferkettenspezifischen Umgebungsvariablen oder Startargumente.

• Fernkonfiguration. Das SSH-/TUI-Fernmenü stellt denselben Lieferkette-Bereich mit denselben Feldern bereit, sodass eine kopflose Instanz ohne die GUI konfiguriert werden kann. Siehe Fernzugriff.

Das Sicherheitsprotokoll-Fenster

Alles, was die Lieferketten-Pipeline tut, ist im Sicherheitsprotokoll sichtbar — öffnen Sie Fenster → Sicherheitsprotokoll…. Es ist ein Live-Tail jedes Sicherheitsereignisses, das der Proxy ausgibt: Lieferketten-Abfragen und -Verdikte, 451-Blockaden, Skript-Entfernungen, Richtlinien-Aktivierungs-Bestätigungen und Delpi-Umleitungen, neben Prompt-Injection-Erkennungen, Fusion-Aktivierung/-Deaktivierung, LLM-Routing-Änderungen, Fernzugriffs-Ereignissen und Worktree-Zeilen. Ein Fenster bedient die gesamte App; erneutes Wählen des Menüpunkts holt es in den Vordergrund.

Zeilen sind farbcodiert, sodass Sie eine Installation auf einen Blick lesen können:

Das Fenster hat ein Feld Filter…, um die Ansicht einzugrenzen (geben Sie einen Paketnamen, ein Ökosystem oder einen beliebigen Text aus den Zeilen ein, die Sie interessieren), ein Ankreuzfeld Auto-Scroll (standardmäßig aktiviert; deaktivieren Sie es, um dem Tail beim Lesen nicht mehr zu folgen), eine Schaltfläche Leeren, die den Puffer löscht, und eine Fußzeile, die die Eintragsanzahl anzeigt („42 entries“ oder „7 of 42 entries“, während ein Filter aktiv ist). Eine Leerzustands-Meldung erklärt, wann Einträge erscheinen werden.

Um es in Aktion zu sehen: Öffnen Sie das Fenster, führen Sie eine beliebige Installation innerhalb einer Sitzung aus (npm install, pip install, cargo add, gem install, …) und beobachten Sie, wie die Einträge einströmen. Selbst eine vollständig saubere Installation erzeugt „inspecting“-Zeilen für jedes Artefakt — das ist gewollt, damit sich eine stille Pipeline von einer umgangenen unterscheiden lässt.

Hinweis: Der Puffer ist ein Ringpuffer im Speicher, der auf etwa 5.000 Zeilen begrenzt ist und Neustarts der App nicht überdauert. Jede Zeile wird zudem auf die stderr der App gespiegelt, sodass das Starten von bromure-cli aus einem Terminal (oder das Erfassen seiner Log-Ausgabe) Ihnen eine dauerhafte Kopie liefert. Das Fenster öffnet mit 820×460 und lässt sich auf 720×360 verkleinern.

Offline- und eingeschränktes Verhalten

Die Reputationsprüfungen der Pipeline hängen von ausgehenden Aufrufen von Ihrem Mac ab (niemals von der VM): api.osv.dev für OSV, api.socket.dev für socket.dev, pypi.org für die PyPI-Veröffentlichungszeit-Absicherung und depi-npm-proxy.landh.tech für Delpi. Wenn eine aktivierte Quelle kein Verdikt liefern kann — Netzwerk nach Wiederholungen ausgefallen, HTTP-Fehler, Rate-Limiting, ein Auth-Fehlschlag oder ein nicht unterstütztes Ökosystem — versagt Bromure geschlossen, statt stillschweigend zu erlauben.

Der Download pausiert, und ein Halten ungeprüfter Pakete fragt Sie, pro Paket und Version, mit einem System-Hinweis betitelt Ein ungeprüftes Paket aus Arbeitsbereich „…“ durchleiten?: Bromure konnte die Quelle nicht erreichen, um das Paket zu prüfen, und es zu installieren bedeutet, ein Paket zu akzeptieren, das nicht gegen Ihre konfigurierten Reputationsquellen geprüft wurde. Die vier standardmäßigen Zustimmungsentscheidungen gelten; eine Ablehnung (auch wenn keine GUI verfügbar ist und der Fern-Hinweis abläuft) blockiert mit einer 451. Haltevorgänge sind pro package@version verschlüsselt, sodass eine einzelne Genehmigung niemals den gesamten Abhängigkeitsgraphen pauschal abdecken kann.

Dies ist bewusster Schutz: ohne ihn könnte ein Angreifer, der Rate-Limiting beim Reputationsdienst auslösen kann, Pakete ungeprüft durchschmuggeln. Die praktischen Folgen:

• Vollständiges Offline-Arbeiten mit aktiviertem OSV oder socket.dev bedeutet einen Hinweis für jedes nicht zwischengespeicherte Paket. Deaktivieren Sie diese Ebenen für Offline-Phasen — die Altersgrenze arbeitet ohne Verbindung aus bereits zwischengespeicherten Metadaten weiter.
• socket.dev plus Cargo bedeutet einen Hinweis für jedes Crate, da socket.dev Cargo überhaupt nicht prüfen kann (Erteilungen gelten pro package@version, sodass eine Sitzungs-Erteilung nur diese eine Crate-Version abdeckt).
• Die PyPI-Veröffentlichungszeit-Absicherung ist die eine Ausnahme: bei einem reinen Netzwerkfehler versagt sie für diesen Abruf offen (der Fehlschlag wird nicht zwischengespeichert, sodass die Abfrage beim nächsten Mal wiederholt wird). Das Umschreiben der Metadaten durch die Altersgrenze ist davon unberührt.

Kompromittierungs-Erkennung

Lieferketten-Prüfungen verringern die Wahrscheinlichkeit, dass feindseliger Code in die Sandbox gelangt; die Kompromittierungs-Erkennung fängt den Moment ab, in dem feindseliger Code, der doch hineingelangt ist, zu handeln versucht. Sie ist Teil des Zugangsdaten-Systems und nicht der Paket-Pipeline — das vollständige Bild von Köder-Zugangsdaten und dem Token-Austausch findet sich unter Zugangsdaten — aber ihr Alarm ist hier dokumentiert, weil ein vergiftetes Paket sein wahrscheinlichster Auslöser ist.

Jede ausgehende Anfrage aus der VM wird in einem einzigen Durchgang auf die Köder-Token („fake“) durchsucht, die die Zugangsdaten-Austauschebene geprägt hat. Ein Köder, der auf einen Host beschränkt ist (sagen wir, github.com) und in einer Anfrage auftaucht, die an irgendeinen anderen Host gerichtet ist, ist die Signatur einer Zugangsdaten-Exfiltration. Wenn das geschieht:

1. Der Proxy blockiert die Anfrage mit einer 451 — das Ziel empfängt niemals ein Byte.
2. Die VM wird augenblicklich pausiert. War die Sitzung abgekoppelt, wird sie zwangsweise wieder angekoppelt und angezeigt. Der eingefrorene Sitzungsrahmen färbt sich rot.
3. Ein kritischer Hinweis erscheint, betitelt mit Diese Umgebung könnte kompromittiert worden sein, der erklärt, dass Bromure einen ausgehenden Versuch erkannt hat, ein Sitzungs-Zugangsdatum aus dem genannten Arbeitsbereich an einen Host zu leaken, für den es nicht geprägt wurde, und dass die VM pausiert wurde — mit einer Detailzeile pro Leak: eine Token-Vorschau (wie sk-a…f9q3), der Name des Zugangsdatums, der Host, für den es geprägt wurde, und der Host, zu dem es unterwegs beobachtet wurde.

Der Hinweis bietet drei Reaktionen:

• Herunterfahren (die Voreinstellung) — stoppt die VM und markiert den Arbeitsbereich als kompromittiert.
• Für Untersuchung sichern — Sie wählen einen Ordner; Bromure exportiert disk.img (eine Kopie der VM-Systemplatte), home.tar.gz (das Home-Verzeichnis des Arbeitsbereichs) und shares/<name>.tar.gz für jeden freigegebenen Ordner, fährt dann herunter und markiert den Arbeitsbereich als kompromittiert. Der RAM-Zustand wird verworfen.
• Fortfahren — das Risiko akzeptieren und fortsetzen; der Detektor schlägt erneut an, falls es wieder geschieht. Esc und Cmd-. sind bewusst nicht auf Fortfahren abgebildet — das Fortsetzen einer möglicherweise feindseligen VM muss ein expliziter Klick sein.

Ein als kompromittiert markierter Arbeitsbereich weigert sich, erneut zu booten, bis Sie ihn ausdrücklich löschen, und der Löschablauf warnt, dass freigegebene Ordner nicht gelöscht werden — sie könnten immer noch kontaminierte Dateien enthalten, prüfen Sie sie also von Hand.

Es gibt nichts zu konfigurieren: die Erkennung ist für Zugangsdaten, die einen Host-Bereich deklarieren, stets aktiv. Manuelle Zugangsdaten ohne einen gepinnten Host („beliebiger Host“) können sie niemals auslösen, und Claude-/Codex-Token verwenden einen entspannten Abgleich derselben registrierten Domain (ein für api.anthropic.com geprägtes Token, das auf einem anderen anthropic.com-Host gesehen wird, löst keinen Alarm aus). Es wird jeweils nur ein Hinweis angezeigt; wiederholte Ereignisse, während er geöffnet ist, werden verworfen.

Unternehmens-Sichtbarkeit

Für Arbeitsbereiche, die bei bromure.io registriert sind, gibt jeder Metadaten- und Artefaktabruf zudem ein supply_chain.fetch-Ereignis an den Unternehmens-Ereignisstrom aus, das das Ökosystem, das Paket, die Version, die Anfrageart, das Ergebnis (allowed, rewritten, blocked oder stripped) und die Grundart (age_gate, osv, socket_compromised, socket_cve, verify_unavailable, lockfile_denied, scripts_stripped) trägt. Die Registrierung allein gibt Administratoren organisationsweite Sichtbarkeit über Paket-Downloads — ein Inventar von allem, was jeder Agent installiert hat — selbst auf Arbeitsbereichen, bei denen jede Durchsetzungsebene ausgeschaltet ist.

Wie die Registrierung funktioniert und was Administratoren am anderen Ende sehen, wird unter Enterprise behandelt.