ISGroup Cybersicherheitsberatung

Devin von Cognition: Wie man die Sicherheit von Code überprüft, der von KI-Agenten erstellt wurde

[Callforaction-WAPT]

Devin von Cognition und autonome Softwareentwicklung: Wie man von End-to-End-Agenten erstellten Code überprüft

Devin hebt das Thema KI-Coding auf eine andere Ebene als klassische Assistenten. Er beschränkt sich nicht darauf, Code zu vervollständigen oder Änderungen in einer Datei vorzuschlagen: Er kann vollständige Engineering-Aufgaben übernehmen, in einer dedizierten Cloud-Umgebung arbeiten, Terminal, Browser und Dateisystem nutzen, Abhängigkeiten installieren, Tests ausführen, Fehler beheben und Pull Requests vorbereiten.

Für CTOs, Engineering Manager und Softwarehäuser stellt sich nicht nur die Frage, ob Devin funktionierenden Code produziert. Es geht darum zu verstehen, wie man ein Ergebnis überprüft, das von einem Agenten generiert wurde, der den gesamten Aufgabenzyklus durchlaufen hat: Tickets, Repository, Umgebung, Befehle, Tests, Logs, Integrationen und Pull Requests. Vor dem Merge oder Deploy ist der Punkt konkret: Was hat Devin am Code, an den Tests, den Abhängigkeiten, den Secrets, den Konfigurationen, den APIs und am Verhalten der Anwendung geändert?

Warum autonome Softwareentwicklung das Review verändert

Bei einem traditionellen Assistenten sieht der Reviewer oft einen begrenzten Vorschlag. Bei Devin kann das Ergebnis ein vollständiger PR sein: Der Agent hat geplant, die Codebase erkundet, Befehle ausgeführt, Dateien geändert, Tests aktualisiert, Pakete installiert und seine eigene Arbeit überprüft. Dies macht das Review strukturell schwieriger, da das finale Diff nicht immer die ganze Geschichte erzählt: Es zeigt weder die ausgeführten Befehle, die aufgetretenen Fehler, die gelesenen Logs, die im Browser gesehenen Daten, die ausprobierten und verworfenen Pakete, noch die Annahmen, die getroffen wurden, um die Test-Suite bestehen zu lassen.

Ein PR kann fertig aussehen, weil die Tests grün sind, aber dennoch eine Autorisierungs-Regression, eine nicht genehmigte Abhängigkeit oder ein zu permissives Fallback enthalten. Das Hauptrisiko besteht nicht darin, dass Devin den Code falsch schreibt: Es besteht darin, einen autonomen Zyklus so zu akzeptieren, als wäre er gleichwertig mit einem vollständigen menschlichen Review. Das Team muss in der Lage sein, zu rekonstruieren, was zwischen Ticket und PR passiert ist.

Cloud-Workspace, Terminal und Browser

Devin arbeitet als autonomer Agent in einer dedizierten Umgebung. Die offizielle Dokumentation beschreibt die Fähigkeit, Code zu schreiben, auszuführen und zu testen; die Enterprise-Version spricht von Workspaces mit Shell, Browser und Code-Editor sowie von Deployment-Modellen mit Cloud-Komponenten und Devboxen. Diese Architektur ist nützlich, weil der Agent die Arbeit auch dann fortsetzen kann, wenn der Entwickler nicht anwesend ist, aber sie ist auch eine Angriffsfläche, die sorgfältig verwaltet werden muss.

Ein Shell-Befehl kann Pakete installieren, Umgebungsvariablen lesen, Dateien ändern, Migrationen starten, Tests ausführen, Dienste starten oder mit Cloud-CLIs interagieren. Der Browser kann Dashboards, interne Bildschirme, Testdaten, Monitoring-Tools und Anwendungsabläufe sehen. Bevor Devin in Unternehmens-Repositories eingesetzt wird, muss explizit entschieden werden, welche Umgebungen er erreichen darf. Test-Accounts, synthetische Daten, erlaubte Repositories und eingeschränkte Secrets reduzieren das Risiko; Produktions-Secrets, Dashboards mit echten Daten, Live-APIs und sensible Cloud-Umgebungen sollten standardmäßig nicht verfügbar sein.

Agentische PRs: Der grüne Test reicht nicht aus

Devin kann PRs generieren, die Tickets, Bugs oder Backlog-Aufgaben lösen. Der PR ist der Punkt, an dem das Team die Kontrolle zurückgewinnt, und wenn sich diese Kontrolle darauf beschränkt, zu prüfen, ob der Code kompiliert und die Tests bestehen, wird der Wert der Autonomie zu ihrer Schwachstelle.

Die manuell zu prüfenden Bereiche umfassen Auth, Autorisierungen, Mandantentrennung (Tenant Isolation), APIs, Middleware, Eingabevalidierung, Fehlerbehandlung, Logging, Secrets, Abhängigkeiten, Pipelines und Deployment-Konfigurationen. Eine Änderung, die einen Login-Bug behebt, kann eine Prüfung ins Frontend verschieben; ein Fix an einer API kann einen Client-seitigen Parameter akzeptieren, der zuvor vom Server abgeleitet wurde; ein zusammen mit dem Code generierter Test kann das neue Verhalten bestätigen, anstatt es herauszufordern. Jeder von Devin generierte PR in sensiblen Bereichen sollte explizite Reviewer, Branch-Protection, negative Tests und eine Diff-Analyse pro Changeset haben. Wenn die Änderung eine Web-App oder eine API exponiert, muss das reale Verhalten mit einem WAPT-Ansatz getestet werden, nicht nur mit Unit-Tests.

Autorisierungen und Geschäftslogik

Viele Schwachstellen, die von autonomen Agenten eingeführt werden, unterbrechen die Funktionalität nicht: Die App tut weiterhin das, was das Ticket verlangte, verliert aber eine Einschränkung. Ein Benutzer kann Daten eines anderen Mandanten lesen, eine Rolle kann eine nicht vorgesehene Route aufrufen, ein Workflow kann einen Status überspringen, eine serverseitige Validierung kann als redundant betrachtet und entfernt werden.

Deshalb muss das Review eines Devin-PRs Missbrauchsfälle (Abuse Cases) beinhalten. Ein Account mit niedrigen Privilegien muss versuchen, administrative Endpunkte aufzurufen; ein Benutzer eines anderen Mandanten muss versuchen, Datensätze zu lesen oder zu ändern, die ihm nicht gehören; eine abgelaufene Einladung muss wiederverwendet werden; eine Anfrage außerhalb der Sequenz muss versuchen, den Status einer Bestellung, eines Vorgangs oder eines Workflows zu ändern. Die Geschäftslogik ist nicht immer für automatische Scanner sichtbar: Es bedarf einer Domänenkenntnis. Welche Vorgänge erfordern eine Genehmigung? Welche Daten sind nach Kunde, Rolle, Gruppe oder Land getrennt? Welche Bedingungen dürfen nicht vom Client steuerbar sein?

Secrets im autonomen Workflow

Wenn ein Agent End-to-End arbeitet, können Secrets an mehreren Stellen auftauchen: Repositories, .env-Dateien, Shell-History, Test-Logs, Build-Outputs, Prompts, Code-Kommentare, PR-Beschreibungen, CI/CD-Artefakte, Browser und Monitoring-Tools. Die Enterprise-Dokumentation von Devin weist auf die Verwendung einer Secrets-Funktion hin, um Zugangsdaten bei Bedarf zu teilen, aber dies eliminiert nicht das Anwendungsrisiko: Der generierte Code kann dennoch einen Wert ausgeben, ihn an das Frontend weitergeben, in einen Test einfügen oder in eine Beispieldatei kopieren.

Vor dem Merge ist ein Secret-Scanning auf Diffs und relevanter History erforderlich. Wenn ein Schlüssel in Prompts, Logs, Artefakten oder PRs gelandet ist, muss er rotiert werden. Die Devin gewährten Zugriffe müssen auf die Aufgabe beschränkt sein: Dev-Token, minimale Scopes, separate Repositories und Umgebungen, keine Produktions-Secrets, sofern nicht unbedingt erforderlich und genehmigt.

Abhängigkeiten, Skripte und Supply Chain

Ein autonomer Agent, der ein Ticket schließen will, kann Bibliotheken hinzufügen, Lockfiles aktualisieren, Build-Skripte ändern oder Tools installieren, um einen Bug zu reproduzieren. Dies kann aus funktionaler Sicht korrekt und aus Sicht der Supply Chain riskant sein. Jede Änderung an package.json, requirements.txt, pyproject.toml, go.mod, Cargo.toml, Lockfiles oder postinstall-Skripten muss überprüft werden: Man muss verstehen, warum die Abhängigkeit eingeführt wurde, ob sie gewartet wird, welche Lizenz sie hat, welche transitiven Abhängigkeiten sie mitbringt, ob bekannte Schwachstellen existieren und ob die Skripte unerwarteten Code ausführen.

Die Dependency-Review ist besonders wichtig, wenn Devin Build- oder Testfehler behebt, da der Agent in diesen Fällen den schnellsten Weg wählen kann: eine Bibliothek ersetzen, eine Version herabstufen, eine Prüfung deaktivieren oder ein Hilfspaket hinzufügen. Das Team muss entscheiden, ob diese Wahl für das Produkt akzeptabel ist, nicht nur, ob sie das unmittelbare Problem löst.

Integrationen: GitHub, Slack, Linear, Datadog, AWS

Devin kann sich durch Ticketing-Tools, Repositories, Chats und Monitoring in den Workflow des Teams einfügen, wodurch es natürlich wird, Aufgaben von Linear oder Jira zu delegieren, in Slack zu kommentieren, PRs auf GitHub oder GitLab zu öffnen, Logs einzusehen und bei echten Issues einzugreifen. Jede Integration erweitert jedoch den Kontext und die dem Agenten zur Verfügung stehenden Berechtigungen.

Eine zu weit gefasste GitHub-Integration kann Zugriff auf unnötige Repositories gewähren; ein Slack-Thread kann Kundendaten oder Token enthalten; ein Observability-Tool kann sensible Payloads, Stack-Traces, Header, Queries oder interne Endpunkte anzeigen; ein AWS-Zugriff kann Änderungen an Ressourcen ermöglichen, die nichts mit dem Ticket zu tun haben. Die Konfiguration der Integrationen muss dem Prinzip der geringsten Rechte (Least Privilege) folgen. Erlaubte Repositories, dedizierte Kanäle, Read-Only-Berechtigungen, wo diese ausreichen, separate Token pro Umgebung und regelmäßige Zugriffskontrollen reduzieren das Risiko erheblich.

Deploy, Pipelines und Konfigurationen

Devin kann verwendet werden, um CI zu reparieren, Dockerfiles zu aktualisieren, Konfigurationen zu korrigieren, Pipelines zu ändern oder Deployments vorzubereiten. Diese Änderungen sind nicht neutral: Sie verändern, wie der Code in die Produktion gelangt. Ein PR, der “die Pipeline repariert”, kann Berechtigungen erweitern, Secrets in Logs offenlegen, Sicherheits-Schritte deaktivieren, Branch-Protection ändern, ein Dockerfile permissiver machen, Umgebungsvariablen ändern oder Tests überspringen. Ein Fix am Deployment kann Debug-Modus, offenes CORS, detaillierte Fehlermeldungen oder fehlendes Rate-Limiting einführen.

Änderungen an CI/CD, Containern, IaC, Cloud-Config, Env, Secrets, Feature Flags und Deploy-Skripten müssen separat überprüft werden. Wenn die Aufgabe Cloud, Netzwerk, IAM, Buckets, Datenbanken oder Pipelines berührt, verlässt der Perimeter das reine Code-Review und kann ein Cloud Security Assessment oder eine Secure Architecture Review erfordern.

Audit Trail: Das Warum rekonstruieren, nicht nur das Was

In der autonomen Softwareentwicklung reicht das finale Diff nicht aus. Es wird ein Audit Trail benötigt, der Ticket, Prompt, Sitzung, Befehle, Tests, Logs, Fehler, PRs und Genehmigungen miteinander verknüpft: Ohne diese Kette ist es schwer zu verstehen, warum der Agent eine Lösung gewählt und welche Alternativen er verworfen hat. Der Audit Trail ist auch für das Incident Response nützlich: Wenn eine Schwachstelle in die Produktion gelangt, muss das Team verstehen können, welche Aufgabe sie eingeführt hat, welche Prüfungen bestanden wurden, wer den PR genehmigt hat, welche Tests fehlten und welche Daten oder Secrets dem Agenten zur Verfügung standen.

Das Speichern von Logs und Trajektorien bedeutet nicht, sensible Daten anzuhäufen. Es bedeutet zu definieren, was aufgezeichnet wird, wie Secrets geschwärzt werden, wer auf die Audit-Logs zugreifen kann, wie lange sie aufbewahrt werden und wie sie genutzt werden, um die Richtlinien im Laufe der Zeit zu verbessern.

Checkliste vor dem Merge

PR, Diff und Tests

  • Überprüfen Sie den PR auf kleine und verifizierbare Changesets.
  • Prüfen Sie die hinzugefügten oder geänderten Tests und stellen Sie sicher, dass sie negative Fälle enthalten, nicht nur den “Happy Path”.
  • Wenn der Agent Snapshots, Mocks oder Tests aktualisiert hat, um die Suite bestehen zu lassen, lesen Sie diese Änderungen aufmerksam durch.

Befehle und Umgebung

  • Kontrollieren Sie die ausgeführten Shell-Befehle, installierten Pakete, gestarteten Skripte, Migrationen, Builds und Tests.
  • Stellen Sie sicher, dass die Umgebung keine Produktions-Secrets oder Zugriffe auf reale Systeme enthielt, die nicht notwendig waren.
  • Wenn Browser oder Dashboards verwendet wurden, stellen Sie sicher, dass keine sensiblen Daten exponiert wurden.

Auth, Daten und APIs

  • Testen Sie serverseitige Autorisierungen, Rollen, Mandantentrennung, IDOR/BOLA, in der UI nicht sichtbare Endpunkte, abgelaufene Token, böswillige Eingaben und Missbrauch der Geschäftslogik.
  • Die von Devin geänderten Bereiche dürfen nicht nur deshalb akzeptiert werden, weil das Ticket als geschlossen gilt.

Secrets und Abhängigkeiten

  • Führen Sie Secret-Scanning auf Diffs, Logs, Artefakten und relevanter History durch.
  • Rotieren Sie alles, was exponiert wurde.
  • Überprüfen Sie neue Abhängigkeiten, Lockfiles, Install-/Build-/Test-Skripte, Lizenzen und bekannte Schwachstellen.

Pipelines und Deploy

  • Kontrollieren Sie Dockerfiles, CI/CD, Branch-Protection, Secrets in Pipelines, Env, Feature Flags, IaC, Cloud-Config und Deploy-Skripte.
  • Jede Änderung, die den Weg in die Produktion beeinflusst, muss einen Owner und eine dedizierte Genehmigung haben.

Wann reicht ein internes Review und wann ist eine unabhängige Prüfung erforderlich?

Ein internes Review kann ausreichen, wenn Devin an nicht exponierten Aufgaben gearbeitet hat, ohne echte Daten, ohne Auth, ohne neue Abhängigkeiten, ohne Pipelines und ohne operative Integrationen. Auch in diesem Fall sollte das Team Diffs, Tests und die wichtigsten Befehle aufbewahren.

Eine unabhängige Prüfung ist erforderlich, wenn Devin Authentifizierung, Autorisierungen, APIs, Daten, Abhängigkeiten, Secrets, Pipelines, Cloud, Deployments oder kritische Anwendungslogik geändert hat. Sie ist auch erforderlich, wenn agentische PRs stabil in den Entwicklungszyklus einfließen und das Team Richtlinien, Branch-Protection, Reviewer, Logging, Secret-Handling und Risikoschwellen definieren muss. Der Punkt ist nicht, Devin zu verlangsamen: Es geht darum, das zu trennen, was delegiert werden kann, von dem, was überprüft werden muss.

Wie ISGroup von Devin erstellten Code und Workflows überprüfen kann

Die Kontrolle ändert sich je nachdem, was Devin geändert hat. Wenn das Risiko im PR, im Anwendungscode, in der Autorisierungslogik, in den Secrets oder in den Abhängigkeiten liegt, hilft das Code Review dabei, Schwachstellen und Regressionen vor dem Merge zu identifizieren. Wenn das Ergebnis eine exponierte Web-App oder API ist, überprüft das Web Application Penetration Testing das reale Verhalten von außen.

Wenn Devin Folgendes berührt hat… Hauptrisiko Empfohlene Kontrolle
PR, Anwendungscode, Middleware, Auth, Rollen, Abhängigkeiten Schwachstellen oder Regressionen im Code Code Review
Web-App, API, öffentliche Routen, exponierte Benutzerflüsse Von außen missbrauchbare Verhaltensweisen Web Application Penetration Testing
Pipelines, Deploy, Cloud-Config, IaC, Secrets in CI/CD Fehlkonfigurationen oder übermäßige Privilegien Cloud Security Assessment
Architektur, Vertrauensgrenzen, Integrationen, sensible Daten Schwache architektonische Annahmen Secure Architecture Review
Kontinuierliche Nutzung von Devin im Engineering-Zyklus Nicht wiederholbare Kontrollen bei agentischen PRs Software Assurance Lifecycle

Die Wahl der Kontrolle hängt davon ab, was sich wirklich geändert hat: Code, exponiertes Verhalten, Pipelines, Integrationen oder der Entwicklungsprozess. Vor dem Go-Live ist es ratsam, diesen Perimeter abzugrenzen und das tatsächliche Risiko für die Anwendung zu überprüfen.

Vor dem Review vorzubereitende Nachweise

Bevor ein externes Team einbezogen wird, sollten Tickets, PRs, Branches, Diffs, Tests, ausgeführte Befehle, verfügbare Logs, hinzugefügte Abhängigkeiten, geänderte Konfigurationen, eine Liste der zugänglichen Repositories, aktive Integrationen und eine Beschreibung der von Devin verwendeten Umgebungen gesammelt werden. Ebenfalls nützlich sind Informationen über dem Agenten gewährte Secrets, Branch-Protection-Richtlinien, beteiligte Reviewer, CI/CD, Deploy-Skripte, Cloud-Config, verarbeitete Daten, konsultierte Monitoring-Systeme und bereits getroffene Entscheidungen zu akzeptierten Risiken oder geplanten Sanierungen.

FAQ

  • Devin testet seinen eigenen Code: Reicht das für den Produktionseinsatz?
  • Nein. Die Tests des Agenten können bestätigen, dass das Ticket gelöst wurde, beweisen aber nicht allein, dass Autorisierungen, Geschäftslogik, Secrets, Abhängigkeiten und Konfigurationen sicher sind.
  • Was ist das Hauptrisiko der von Devin generierten PRs?
  • Einen PR zu akzeptieren, weil er vollständig ist und die Tests besteht, ohne Befehle, Abhängigkeiten, Entscheidungen und Auswirkungen auf Auth, API, Daten und Pipelines zu rekonstruieren.
  • Kann Devin Secrets sicher verwalten?
  • Er kann dedizierte Mechanismen zum Teilen von Zugangsdaten anbieten, aber der generierte Code kann dennoch Secrets loggen, kopieren oder offenlegen. Es ist notwendig, Nutzung, Scope, Rotation und Artefakte zu kontrollieren.
  • Wann wird der Software Assurance Lifecycle benötigt?
  • Wenn Devin ein fester Bestandteil des Engineering-Zyklus wird: Tickets, PRs, Reviews, CI/CD, Deploy und Sanierung müssen wiederholbare Regeln haben, keine Einzelfallentscheidungen.
  • Wann wird ein Web Application Penetration Testing benötigt?
  • Wenn der von Devin produzierte oder geänderte Code Web-Apps, APIs oder Abläufe exponiert, die für externe Benutzer, Kunden, Partner oder Mitarbeiter erreichbar sind.

[Callforaction-WAPT-Footer]

Quellen und nützliche Referenzen

In

, , ,

Leave a Reply

Your email address will not be published. Required fields are marked *