Wann sollten Updates von Agent-Binärdateien ihr Vertrauen verlieren?

Eine Freigabe für einen lokalen Agenten sollte für die ausführbare Datei gelten, die du geprüft hast, im Prozess, den du genehmigt hast, und für den Zugriff, den sie in diesem Moment angefordert hat. Sobald sich die ausführbare Datei ändert, ist die alte Freigabe praktisch abgelaufen, auch wenn Dateiname, Bundle-Identifier und Symbol unverändert bleiben.

Das klingt streng, bis du eine Freigabe untersuchen musst, die für Version 1.8 erteilt und unbemerkt von Version 1.9 genutzt wurde. Die meisten schlechten Entscheidungen beginnen mit einer zu weit gefassten Identitätsprüfung: einem Pfad, einem Produktnamen oder einer vertrauten signierenden Team-ID. Diese Merkmale können als Nachweise dienen. Keines davon sollte allein privilegiertes Vertrauen über eine Codeänderung hinweg übertragen.

Vertrauen gehört zu einer beobachteten ausführbaren Datei

Ein lokaler Agent ist keine Herausgeberidentität. Er ist ein bestimmtes signiertes Programm, das an einem bestimmten Pfad mit einem bestimmten übergeordneten Prozess, bestimmten Argumenten und Umgebungsvariablen sowie einer bestimmten Gruppe angeforderter Aktionen geladen wird. Ein Herausgeber kann viele Programme veröffentlichen. Ein einzelnes Programm kann sich zwischen Releases stark verändern. Ein stabiler Name sagt über beides fast nichts aus.

Diese Unterscheidung ist besonders wichtig, wenn der Agent kostenpflichtige APIs aufrufen, SSH-Zugangsdaten verwenden, ein Repository ändern oder Daten aus dem Rechner heraus senden kann. Eine Freigabe ist kein Kompliment an den Anbieter. Sie ist die Erlaubnis für einen Prozess, Aktionen mit konkreten Folgen auszuführen.

Halte diese Identitäten getrennt:

• Die Dateiidentität besteht aus dem signierten Code und seinem Digest auf der Festplatte.
• Die Signaturidentität ist die Autorität, die macOS für diesen Code meldet.
• Die Herkunft des Herausgebers ist der Nachweis, dass die Datei über den erwarteten Release-Weg zu dir gelangt ist.
• Die Laufzeitidentität umfasst den Prozess, der den Agenten gestartet hat, und den Zugriff, den er verwenden möchte.

Teams fassen alle vier oft zu «Das ist unser Agent» zusammen. So erbt ein Ersatz am selben Pfad Zugriff, den er sich nie verdient hat. Die sichere Regel ist einfach: Der Austausch einer ausführbaren Datei startet eine neue Vertrauensentscheidung.

Ein Hash erkennt einen Austausch, sagt aber nicht, wer den Ersatz signiert hat. Eine Signatur identifiziert den Signierenden, beweist aber nicht den Download-Kanal. Ein sauberer Download zeigt nicht, ob die neue Version einen umfassenderen Zugriff braucht. Du benötigst alle drei Prüfungen, weil jede einen anderen Fehler auffängt.

Mach nicht den umgekehrten Fehler und pinne jedes Byte für immer fest. Builds ändern sich berechtigt, Zertifikate werden erneuert und Releases müssen aktualisiert werden. Es geht nicht um Dauerhaftigkeit. Es geht darum, dass jemand die Änderung sieht, feststellt, was sich geändert hat, und ausdrücklich entscheidet, ob die angeforderte Autorität weiterhin sinnvoll ist.

Codesignaturen beantworten eine engere Frage als viele denken

Mit der macOS-Codesignatur kann das Betriebssystem prüfen, ob sich signierter Code verändert hat, seit der Signierende die Signatur erzeugt hat. Bei der Verteilung über Developer ID bewertet Gatekeeper außerdem die Entwickleridentität und das Ergebnis seiner Prüfung des Elements. Das sind nützliche Nachweise. Sie ersetzen aber kein vollständiges Urteil über die Lieferkette.

Apples Technical Note TN2206, «macOS Code Signing In Depth», trennt die Codeidentität von den umfassenderen Bedingungen, unter denen das System Code akzeptiert. Besonders relevant ist die Erklärung der Designated Requirements: macOS kann eine Anforderung verwenden, um eine zukünftige Version als Teil derselben Codeidentität zu erkennen. Diese Kontinuität hilft bei gewöhnlichen App-Updates. Als einzige Bedingung ist sie für einen Agenten, der Geld ausgeben oder private Infrastruktur verwenden kann, zu schwach.

Eine gültige Signatur beantwortet diese Fragen nicht:

• Wollte der Herausgeber genau dieses Release auf deinem Rechner bereitstellen?
• Wurde es mit einem kompromittierten Release-Zugang des Herausgebers signiert?
• Hat die neue Version eine Fähigkeit hinzugefügt, die ihr Risiko verändert?
• Haben ein Installationsprogramm, ein Updater oder ein Startskript eine Komponente ersetzt, ohne den von dir geprüften Teil zu ändern?

Gatekeeper und Notarisierung senken die Wahrscheinlichkeit, dass macOS offensichtlich nicht vertrauenswürdige Software ausführt. Sie machen einen gültig signierten Agenten aber nicht automatisch zu einem genehmigten Träger deiner betrieblichen Autorität. Behandle die Zulassung durch das Betriebssystem und die Freigabe privilegierter Aktionen als getrennte Entscheidungen.

Das gilt auch für die Erneuerung eines Zertifikats. Ein erneuertes Zertifikat kann ein normaler Verwaltungsvorgang sein. Trotzdem verändert es die Nachweise, auf die du dich stützt. Wenn Team-ID, Identifier und der erwartete Herausgeberweg konsistent bleiben, kann ein Betreiber das Update nach der Prüfung freigeben. Wenn die Signaturautorität zu einer anderen Organisation wechselt, halte an und verlange eine klare Erklärung des Herausgebers. Akzeptiere keinen überraschenden Identitätswechsel nur deshalb, weil die App ohne Warnung startet.

Die Herkunft des Herausgebers ist von der Signatur getrennt

Die Herkunft fragt, wie die Binärdatei zu dir gelangt ist und ob dieser Weg der üblichen Release-Praxis des Herausgebers entspricht. Eine Signatur auf einer Datei, die aus einem unbekannten Chat-Anhang kopiert wurde, sagt dir, wer diese Kopie signiert hat. Sie erklärt nicht, warum du sie dort erhalten hast.

Erstelle für einen Produktionsagenten bei der Installation oder Aktualisierung einen kleinen Release-Nachweis. Das kann eine Textdatei im Repository sein, das den Agenten verwaltet, ein Änderungsdatensatz oder ein Eintrag in einem internen Release-Log. Der Nachweis sollte Version, Installationsquelle, beobachtete Signaturautorität, Team-ID, Digest, Prüfdatum und die Person festhalten, die das Release angenommen hat. Wenn der Herausgeber einen Release-Digest bereitstellt, speichere auch diesen.

Der Release-Kanal verdient eine kurze Prüfung durch einen Menschen. Stammt der Updater aus der erwarteten Anwendung? Hat der Herausgeber Versionshinweise für diese Version veröffentlicht? Stimmen Archivname, Paketsignatur und Zielpfad mit der üblichen Installationsmethode überein? Ein überraschendes Update über einen neuen Kanal verdient dasselbe Misstrauen wie ein überraschender Signierender.

Verwechsle ein öffentliches Quell-Repository nicht mit einem Release-Artefakt. Ein Repository kann die Quellcodehistorie zeigen, während eine Release-Pipeline eine andere Binärdatei erstellt. Umgekehrt kann eine signierte Binärdatei legitim sein, auch wenn du ihren Build nicht reproduzieren kannst. Das sind unterschiedliche Vertrauensniveaus. Benenne das Niveau, das du tatsächlich hast, statt so zu tun, als würde eines das andere beweisen.

Der Vergleich eines Digests hilft, wenn der Herausgeber dir eine authentifizierte Prüfsumme gibt. Er hilft nicht, wenn du Prüfsumme und Binärdatei von derselben nicht vertrauenswürdigen Seite kopierst. Der aussagekräftige Vergleich kommt aus einem unabhängigen, vom Herausgeber kontrollierten Release-Datensatz, einem vertrauenswürdigen Paketmanager-Datensatz oder einer zuvor festgelegten internen Quelle.

Der angeforderte Zugriff muss mit dem Update neu geprüft werden

Eine Aktualisierung kann dieselbe Signaturautorität behalten und trotzdem weniger Zugriff verdienen als das alte Release hatte. Der Grund für die Prüfung ist nicht nur die Angst vor schädlichem Code. Neues Verhalten kann eine alte Berechtigung unangemessen machen.

Frage, welche externen Aktionen der Prozess nach dem Update ausführt. Ein Agent, der bisher nur Metadaten zu Issues gelesen hat, kann nun Pull Requests erstellen. Einer, der ein Wegwerf-Testtoken verwendet hat, kann nun SSH-Befehle auf einem gemeinsam genutzten Host ausführen. Ein neues Plugin, ein geändertes Konfigurationsformat oder ein anderer Standardbefehl kann die praktische Reichweite des Prozesses verändern, ohne beim Betriebssystem eine neue Berechtigung anzufordern.

Die Prüfung des angeforderten Zugriffs sollte die tatsächliche Aktionsgrenze abdecken:

• Welche HTTP-Hosts, Kontobereiche und Zugangsdaten-Datensätze wird der Prozess verwenden?
• Welche SSH-Ziele und Remote-Befehle kann er erreichen?
• Welches Arbeitsverzeichnis, welche Repository-Hooks, Argumente und Umgebungsvariablen starten ihn?
• Erhält er jetzt Eingaben aus einer anderen Quelle, etwa einem Pull-Request-Kommentar oder einem Build-Log?
• Kann er eine andere lokale ausführbare Datei aufrufen, die nicht Teil der vorherigen Prüfung war?

Hier versagt eine pauschale dauerhafte Freigabe. Eine Entscheidung wie «Diesen Agenten erlauben» verschweigt den entscheidenden Teil: Was darf er tun, mit wessen Zugangsdaten und als Reaktion auf welche Eingabe?

Bei Agent-Prozessen verdient die Herkunft der Eingaben ebenso viel Aufmerksamkeit. Ein Update, das einem Coding-Agenten erlaubt, auf nicht vertrauenswürdigen Issue-Text zu reagieren, kann aus gewöhnlichem Repository-Zugriff einen Weg für Prompt Injection machen. Codesignaturen prüfen nicht die Anweisungen, die der Prozess erhält. Sie decken nur das Programm ab, das diese Anweisungen interpretiert.

Halte Freigabedialoge und interne Datensätze konkret. Benenne die Prozessautorität, das Ziel, die Zugangsdatenklasse und die Frage, ob die Aktion den Zustand eines entfernten Systems verändert. Ein Betreiber kann keine fundierte Entscheidung aus einer Meldung treffen, die nur sagt: «Agent fordert Zugriff an.»

Beende die alte Sitzung, bevor der neue Code handeln kann

Die klarste Regel ist, die Freigabe an einen laufenden Prozess zu binden und sie zu beenden, sobald dieser Prozess endet. Eine ersetzte Binärdatei läuft in einem neuen Prozess und erhält deshalb eine neue Freigabe. So entfällt der spröde Versuch, zu bestimmen, welches Paketupdate klein genug ist, um eine frühere Freigabe zu übernehmen.

Lass einen Prozess nicht selbstständig eine Aktualisierung durchführen und danach die Autorisierung weiterverwenden, die er vor dem Austausch erhalten hat. Manche Updater tun genau das: Der alte Prozess lädt ein Archiv herunter, schreibt eine neue ausführbare Datei über den alten Pfad und startet anschließend einen Helfer oder führt sich selbst erneut aus. Wenn die Autorisierungsschicht nur einen Pfad oder einen langlebigen Client-Datensatz prüft, läuft der neue Code unter der alten Entscheidung weiter.

Ein praktischer Entscheidungsdatensatz kann so aussehen:

process path: /Users/dev/tools/agent/bin/agent
observed digest: 8a4b...e19c
identifier: dev.example.agent
TeamIdentifier: A1B2C3D4E5
parent: interactive shell in approved repository
requested actions: issue API read, test-host SSH command
approval scope: this process only
expires: process exit

Behandle den Digest nicht als dauerhaften Allowlist-Eintrag. Speichere ihn, damit du erkennen kannst, dass sich die nächste Freigabe auf anderen Code bezieht. Wenn der Prozess nach einem Update neu startet, vergleiche die aktuelle Beobachtung mit der letzten und zeige dem Betreiber die relevanten Unterschiede.

Auch ein Neustart derselben Version kann eine Prüfung erfordern, wenn sich der Startkontext ändert. Eine Binärdatei, die von einer interaktiven Shell in einem ausgecheckten Repository gestartet wird, ist nicht dasselbe wie dieselbe Binärdatei, die unbeaufsichtigt von einem Build-Job mit einer größeren Umgebung gestartet wird. Die ausführbare Datei ist nur ein Teil des Prüfobjekts. Der Prozesskontext vervollständigt es.

Prüfe macOS-Nachweise, bevor du einen Ersatz freigibst

Du kannst eine Kandidaten-Datei mit den integrierten macOS-Werkzeugen prüfen, bevor du sie einen privilegierten Aufruf ausführen lässt. Führe die Befehle gegen die ausführbare Datei aus, die tatsächlich gestartet wird, nicht gegen eine ähnlich benannte Kopie in Downloads und nicht gegen ein äußeres Application Bundle, von dem du annimmst, dass es sie enthält.

codesign -d -vvv /Users/dev/tools/agent/bin/agent 2>&1
spctl -a -t exec -vv /Users/dev/tools/agent/bin/agent
shasum -a 256 /Users/dev/tools/agent/bin/agent

Die Ausgabe von codesign enthält typischerweise Felder wie diese:

Identifier=dev.example.agent
Authority=Developer ID Application: Example Publisher (A1B2C3D4E5)
TeamIdentifier=A1B2C3D4E5
CDHash=8a4b9c0d...

spctl meldet seine Bewertung und gibt bei akzeptierter Developer-ID-Software häufig eine Herkunft an. shasum gibt einen vollständigen SHA-256-Digest gefolgt vom Dateipfad aus. Speichere die relevanten Ausgaben mit dem Release-Nachweis. Der genaue Wortlaut unterscheidet sich je nach macOS-Version. Vergleiche deshalb Identitätsfelder und Bewertung, nicht Leerzeichen oder die Reihenfolge der Felder.

Prüfe bei einer gebündelten Anwendung auch den enthaltenen Code. Ein signiertes äußeres Bundle kann Helfer, Frameworks oder Kommandozeilenprogramme enthalten. Wenn der Agent einen Helfer direkt startet, prüfe auch diesen direkt. Die Datei, die Zugriff anfordert, ist die Datei, deren Identität du an die Entscheidung binden musst.

Eine erfolgreiche Prüfung mit codesign bedeutet nicht, dass eine ausführbare Datei notariert oder für deinen Einsatzzweck geeignet ist. Sie bedeutet, dass die Signatur nach den Prüfregeln des Befehls gültig ist. Diese Unterscheidung sollte in Vorfallnotizen erhalten bleiben. Sonst liest später jemand «Signatur gültig» als «Release geprüft und genehmigt». Das wäre eine deutlich weitergehende Aussage.

Ein stabiler Pfad ist ein einfacher Weg, den falschen Code freizugeben

Stell dir einen lokalen Wrapper unter /Users/dev/bin/agent vor. Ein Entwickler genehmigt ihn einmal, weil er eine schreibgeschützte Projekt-API aufruft. Später führt der Wrapper ein automatisches Update aus, lädt einen neuen Helfer herunter und behält denselben Pfad. Die Freigabekomponente erkennt den Pfad und gibt dem neuen Helfer die alte Berechtigung.

Für diesen Ablauf braucht es keinen böswilligen Angreifer. Das Release kann echt sein. Das Problem ist, dass der Freigabedatensatz sagt «Pfad entspricht erlaubtem Pfad», während die tatsächliche Entscheidung für ein älteres Programm mit engerem Verhalten getroffen wurde.

Noch problematischer wird es, wenn der Wrapper selbst ein Skript ist. Shell-Skripte rufen oft versionierte Binärdateien unter einem stabilen symbolischen Link auf, lesen Konfiguration aus einem beschreibbaren Verzeichnis oder wählen einen Helfer aus PATH. Eine Signaturprüfung des Wrappers sagt wenig über die endgültige ausführbare Datei aus, wenn der Wrapper die Ausführung nach der Prüfung umleiten kann.

Ändere die Reihenfolge der Vorgänge. Löse die endgültige ausführbare Datei auf. Prüfe ihre Signatur und ihren Digest. Erfasse den übergeordneten Prozess und die Argumente. Autorisiere dann diesen laufenden Prozess. Wenn ein Launcher nach der Freigabe eine andere ausführbare Datei einsetzen oder auswählen kann, binde das Aktions-Gateway an den Prozess, den es beim Verbindungsaufbau beobachtet, und lehne Abweichungen ab.

Die verbreitete Alternative ist, jedes Update freizugeben, das mit derselben Team-ID signiert wurde. Teams wählen diese Lösung, weil Nachfragen Entwickler stören und Release-Zertifikate normalerweise stabil bleiben. Für privilegierte Agenten ist sie falsch, weil sie eine Herausgeberberechtigung wie einen Blankoscheck für jedes künftige Verhalten behandelt. Verringere die Zahl der Nachfragen mit sitzungsbezogenen Freigaben, engem Zugriff und klaren Update-Hinweisen, nicht indem du Updates unsichtbar machst.

Änderungen des Herausgebers brauchen einen ausdrücklichen Migrationsdatensatz

Ein Wechsel der Signaturautorität kann legitim sein. Unternehmen übernehmen Produkte, wechseln zu einem anderen Developer-ID-Konto oder ersetzen einen alten Verteilungsprozess. Behandle solche Ereignisse als Migrationen, nicht als gewöhnliche Updates.

Verlange einen ausdrücklichen Datensatz mit der bisherigen Identität, der neuen Identität, der Version, in der die Änderung erfolgt ist, und den Nachweisen, auf deren Grundlage du sie akzeptiert hast. Gute Nachweise sind eine signierte Ankündigung im etablierten Release-Kanal des Herausgebers, übereinstimmende Versionshinweise im erwarteten Repository und ein Paket aus dem normalen Bereitstellungsweg. Ein ungeklärtes Pop-up ist kein Nachweis.

Eine geänderte Team-ID sollte standardmäßig abgelehnt werden, bis jemand die Migration geprüft hat. Ein geändertes Zertifikat unter derselben Team-ID kann nach der üblichen Prüfung von Herkunft und Zugriff eine neue Freigabe erhalten. Ein geänderter Digest mit demselben Zertifikat braucht ebenfalls eine neue Freigabe, weil es sich um neuen Code handelt, auch wenn alle anderen Felder übereinstimmen.

Erteile keine großzügige Ausnahme wie «Akzeptiere alle zukünftigen Identitäten für diesen App-Namen». Diese Ausnahme verwandelt eine einmalige Migration in eine dauerhafte Lücke. Speichere die neue Identität erst, nachdem der Prüfer ein bestimmtes Release akzeptiert hat. Die nächste Änderung sollte dieselbe Prüfung erneut auslösen.

Wenn dein Team interne Agenten verteilt, veröffentliche die erwartete Signaturidentität, den Release-Digest und das Updateverfahren an einem Ort, den Betreiber finden können, ohne sich auf den Agenten selbst zu verlassen. Ein Agent kann seinen eigenen Ersatz nicht glaubwürdig bestätigen, solange dieser Ersatz Gegenstand der Prüfung ist.

Ein kleines Freigabeprotokoll ist besser als eine riesige Ausnahmeliste

Du brauchst keine komplizierte Regel-Engine, um Updateentscheidungen vorhersehbar zu machen. Du brauchst ein kurzes Protokoll, das immer angewendet wird, sobald sich die ausführbare Datei ändert.

1. Stoppe den alten Prozess und widerrufe seine aktive Sitzung.
2. Löse die endgültige ausführbare Datei auf, die eine Verbindung herstellen oder handeln wird.
3. Vergleiche Digest, Identifier, Signaturautorität und Team-ID mit dem bisherigen Release-Nachweis.
4. Prüfe den erwarteten Release-Kanal und halte den Grund für jede Identitätsänderung fest.
5. Prüfe Ziele und Zugangsdaten, genehmige dann die neue Prozesssitzung oder lehne sie ab.

Dieses Protokoll trennt ein normales Wartungsupdate von einer echten Auffälligkeit. Ein neuer Digest mit derselben Autorität und normaler Release-Herkunft ist ein Prüfereignis, kein Notfall. Eine unbekannte Autorität, ein unerwartetes Installationsprogramm und eine Anfrage nach einem SSH-Produktionszugang sollten den Rollout stoppen, bis jemand die Sache untersucht.

Sallyports Sitzungsautorisierung kann die Prozessgrenze sichtbar machen, weil sie einen neuen Agent-Prozess erkennt, bevor sie dessen Ausführung erlaubt. Die Freigabe pro Aufruf kann sensible Zugangsdaten zusätzlich an eine engere Entscheidung binden. Das macht die Prüfung eines aktualisierten Agenten nicht überflüssig, verhindert aber, dass ein alter Lauf seine Freigabe unbemerkt an einen späteren Lauf verleiht.

Halte den Datensatz kurz genug, damit Menschen ihn pflegen. Die nützlichen Nachweise sind die beobachtete Datei, ihr Signierender, ihre Quelle, ihr Startkontext und die genehmigten Aktionen. Wenn ein Release einen dieser Punkte verändert, muss die für das Risiko verantwortliche Person die Änderung sehen, bevor der Agent handelt.

Audit-Datensätze müssen den Handelnden vom Herausgeber unterscheiden

Ein Audit-Trail, der nur sagt «Agent hat Zugangsdaten verwendet», erschwert die Untersuchung nach einem Vorfall unnötig. Halte fest, welcher Prozess die Anfrage gestellt hat, welche Signaturautorität macOS gemeldet hat, welche Sitzung sie autorisiert hat und welche Aktion tatsächlich stattgefunden hat. Die Herausgeberidentität erklärt, wer den Code signiert hat. Der Prozessdatensatz erklärt, wer gehandelt hat.

Diese Unterscheidung ist wichtig, wenn ein Agent-Lauf schiefgeht. Du musst feststellen können, ob ein neues Release das Verhalten verändert hat, ob eine alte Binärdatei von einem unerwarteten Ort lief, ob eine Person eine andere Zugriffsanfrage genehmigt hat als angenommen oder ob nicht vertrauenswürdige Eingaben einen ansonsten erwarteten Prozess gesteuert haben. Ein Feld für den Herausgeber kann diese Fragen allein nicht beantworten.

Halte Integrität und Lesbarkeit getrennt. Ein manipulationssicherer Datensatz kann zeigen, ob frühere Einträge geändert wurden. Fehlende Fakten kann er nach dem Ereignis nicht erzeugen. Erfasse Digest und Entscheidungskontext der ausführbaren Datei zum Zeitpunkt der Freigabe, solange du sie noch beobachten kannst.

Sallyport erstellt seine Journale für Sitzungen und Aktivitäten aus einem einzigen verschlüsselten, hashverketteten Audit-Log. Mit sp audit verify kann diese Kette offline über dem Chiffretext geprüft werden. Nutze solche Nachweise, um den Datensatz zu verifizieren, und verknüpfe ihn mit einem Release-Nachweis, der erklärt, warum die ausführbare Datei überhaupt Zugriff erhalten hat.

Die erste betriebliche Änderung, die ich vornehmen würde, ist das Entfernen jeder Freigaberegel, die nur einen Pfad, einen Anzeigenamen oder einen Herausgeber abgleicht. Ersetze sie durch eine Freigabe für den aktuellen Prozess, lasse sie beim Prozessende ablaufen und verlange nach dem Austausch einer Binärdatei eine neue Entscheidung. Diese eine Grenze fängt den Update-Weg ab, den großzügige Allowlists regelmäßig übersehen.