In diesem Beitrag
README ZIP Schadsoftware: Was deckt deine Freigabe ab?
Du hast einen KI-Skill freigegeben. Später verweist seine README auf ein Archiv, das du nie geprüft hast. Die SKILL.md ist unverändert, der alte Dateicheck besteht weiterhin. Deine Installationsfreigabe hängt jetzt von einer Datei ab, die dieser Check nie erfasst hat.
Ein Schadsoftware-Köder über README und ZIP kann die Skill-Anweisungen unverändert lassen und trotzdem die Installation umlenken. Prüfe zusammen, wer das Repository betreibt, welchen Commit du verwendest, wohin die README verweist, was im Archiv steckt und welche Rechte benötigt werden. Halte diese Eingaben in einem geschützten Prüfprotokoll fest. Prüfe die Freigabe erneut, sobald sich Quelle, heruntergeladene Bytes, kopierte Dateien oder Ausführungsrechte ändern.
Eine Installationsfreigabe gilt für bestimmte Softwaredateien unter festgelegten Berechtigungen. Unser Offline-Versuch macht die Grenzen dieser Entscheidung sichtbar. Auch ein harmlos neu verpacktes Archiv kann eine neue Prüfung verlangen, ohne deshalb Schadsoftware zu sein.
Recherche geprüft: 5. November 2026. Die Einordnung der Kampagne stützt sich auf veröffentlichte Forschungsergebnisse. Der ausgeführte Vergleich nutzt erzeugte Textdateien, ZIPs und lokale Git-Commits. Er stellt keine Netzwerkanfragen und führt keinen zu prüfenden Installer aus.
Unabhängigkeit und Marken: Wavect veröffentlicht diese Seite und ist selbst Anbieter, wir haben also ein wirtschaftliches Interesse daran. Mit den hier genannten anderen Unternehmen sind wir weder verbunden noch von ihnen beauftragt oder empfohlen, und alle Firmennamen, Marken und Warenzeichen Dritter gehören ihren jeweiligen Inhabern. Aussagen über andere Anbieter stammen aus öffentlich zugänglichen Quellen, vor allem aus deren eigenen veröffentlichten Seiten, mit Stand des auf dieser Seite genannten Prüfdatums, und können sich seither geändert haben. Bitte prüfe sie vor einer Entscheidung selbst. Diese Seite wurde nach bestem Wissen und Gewissen erstellt, mit dem Ziel, möglichst objektiv zu bleiben. Wenn dir etwas falsch oder unfair erscheint, schreib uns und wir korrigieren es: [email protected]
Was belegt der Bericht über 73 Repositories?
Am 4. November 2026 veröffentlichte Thomas Roccia von SecurityBreak eine IOC-Liste mit 73 GitHub-Repositories, die sich als Tools für KI-Agenten ausgaben. Bei seiner erneuten Prüfung an diesem Tag waren laut Liste 51 erreichbar; 22 lieferten einen 404-Fehler. Diese Zahlen beschreiben beobachtete Repositories. Daraus lassen sich weder Infektionen noch die heutige Erreichbarkeit ableiten.
Roccia beschrieb Kopien von Projekten wie mcp-superset, hermes-agent und ContinuousClaude. Die untersuchten Skill- und Einstellungsdateien wirkten unauffällig. Die README-Anweisungen führten dagegen zu eingecheckten ZIP-Dateien. Windows-Nutzer sollten laut Anleitung außerdem eine Sicherheitswarnung übergehen. Ein Archiv lag unter .claude/hooks/config/. Die beschriebenen Windows-Pakete kombinierten einen Batch-Launcher, eine LuaJIT-Laufzeit und verschleierten Lua-Code, der als Textdatei getarnt war.
Die Ankündigung nennt SmartLoader, das häufig mit StealC in Verbindung steht. Die Belege zeigen nicht, dass jedes Repository diesen Payload auslieferte. Die IOC-Liste trennt bestätigte Indikatoren der untersuchten Samples von weiteren Indikatoren, die für diese Builds unbestätigt sind. Wie viele Betroffene es gibt und wer hinter jedem Konto steht, bleibt offen. Eine Kompromittierung der legitimen Ursprungsprojekte ist damit nicht belegt.
Warum kann eine unauffällige SKILL.md den README-ZIP-Köder übersehen?
Ein unauffälliger Befund für SKILL.md gilt für die untersuchte Datei. Eine Installation kann weitere Anweisungen, mitgelieferte Skripte, heruntergeladene Archive und Startkonfigurationen verwenden. Endet deine Prüfung bei der Skill-Datei, rechtfertigt sie nicht die Ausführung dieser zusätzlichen Komponenten. Du musst wissen, welche Dateien und Aktionen die Freigabe tatsächlich abdeckt.
Die Agent-Skills-Spezifikation definiert einen Skill als Verzeichnis. Der vorgeschriebene Einstiegspunkt ist die SKILL.md. Daneben dürfen Skripte, Referenzen, Assets und weitere Dateien liegen. Daraus ergibt sich ein sinnvoller Prüfumfang: Erfasse das Verzeichnis und verfolge die Abhängigkeiten, die es für die Installation einführt. Die Einstiegsdatei ist nur ein Teil des Pakets.
Angenommen, du prüfst Anweisungen zur Dokumentformatierung. Du findest keine verdächtigen Befehle und gibst sie frei. Eine separate README fordert anschließend dazu auf, eine Laufzeitumgebung herunterzuladen. Diese Abhängigkeit braucht eine eigene Begründung: Warum genau diese Laufzeit, von diesem Herausgeber, in dieser Revision und mit diesen Zugriffsrechten? Vertraute Formulierungen in der ersten Datei beantworten keine dieser Fragen.
Auch der Ausführungskontext zählt. In Netskopes Analyse verwandter SmartLoader-Samples übergibt ein Batch-Launcher eine Textdatei mit Lua-Code an einen Interpreter. Wer nur auf die Dateiendung schaut, übersieht, was der Befehl mit dem Inhalt macht. Eine Textdatei kann Code liefern, den ein legitimer Interpreter ausführt.
Formuliere das Ergebnis deiner Prüfung deshalb genau: „Diese Anweisungen wurden geprüft“ ist ein brauchbarer Nachweis. Überträgst du diese Aussage auf jeden späteren Download oder Befehl, entsteht die Lücke. Dieselbe Frage nach dem Prüfumfang stellt sich, wenn sich gemeinsam genutzte Skill-Anweisungen mit der Zeit ändern. Dieser andere Workflow braucht allerdings eigene Evaluationskontrollen.
Was sollte eine Installationsprüfung abdecken?
Eine Installationsprüfung sollte den Herausgeber und den gewählten Quellstand mit den Dateien, dem Startvorgang und den Berechtigungen verbinden, die du freigeben willst. Wir empfehlen ein Prüfprotokoll außerhalb des Verzeichnisses, in das die zu prüfende Software schreiben darf. Jeder Eintrag sollte benennen, was geprüft wurde und welche spätere Änderung eine neue Entscheidung der zuständigen Person verlangt.
| Gegenstand der Prüfung | Aufzubewahrender Nachweis | Beantwortete Frage |
|---|---|---|
| Herausgeber und Repository | Exakte Kombination aus Eigentümer und Repository sowie die unabhängige Referenz zu ihrer Identifikation. | Prüfen wir das beabsichtigte Projekt? |
| Quellstand | Vollständige Commit-ID und die in die Prüfung einbezogenen Quelldateien. | Welche Revision hat die prüfende Person untersucht? |
| Ziel der README-Anweisung | Aufgelöster Archivpfad oder endgültige Download-URL einschließlich relevanter Weiterleitungen. | Was wählt die Installationsanweisung aus? |
| Archiv | SHA-256 des Archivs, enthaltene Dateipfade und geprüfte Inhalte. | Sind das die geprüften Bytes und Dateien? |
| Installierte Kopie | Manifest der erwarteten installierten Pfade und Datei-Hashes. | Hat Kopieren oder Verpacken verändert, was geladen wird? |
| Startvorgang | Exakter Befehl, Argumente, Arbeitsverzeichnis und Konfiguration. | Was wird beim Aktivieren des Tools ausgeführt? |
| Berechtigungen | Benötigte Dateisystemzugriffe, Netzwerkziele und Zugangsdaten. | Worauf kann der ausgeführte Prozess zugreifen? |
| Verantwortung für die Freigabe | Prüfende Person, Datum, erlaubter Einsatz und Begründung möglicher Ausnahmen. | Wer darf eine geänderte Eingabe freigeben? |
Beginne mit dem tatsächlichen Installationsweg. Eine ZIP-Datei, die im Repository eingecheckt ist, gehört zu diesem Quellstand. Verweist die README auf einen anderen Speicherort, kommt ein separat abgerufenes Objekt hinzu. Ein Release-Name, Download-Button oder Archivdateiname belegt noch nicht, dass die ausgewählten Bytes von der Prüfung erfasst waren.
Die erwarteten Werte müssen unter der Kontrolle deines Teams bleiben. Ein Archiv mit einer Prüfsumme zu vergleichen, die derselbe unbekannte Herausgeber daneben bereitstellt, kann interne Übereinstimmung zeigen. Es belegt nicht, dass deine prüfende Person eines von beiden freigegeben hat. Halte den erwarteten Hash nach der Prüfung fest und schütze dieses Protokoll vor der zu prüfenden Software und ihrem Installer.
Unser MCP Install Risk Scanner hilft bei einer ersten Einordnung eingefügter Befehls- oder Konfigurationsmuster. Er ruft kein Repository ab und untersucht keine Archivdateien. Nutze sein Ergebnis für den Teil, den er prüft. Die übrigen Nachweise musst du separat festhalten.
Welche Änderungen machten die alte Freigabe im Offline-Test ungültig?
Der Vergleich aller protokollierten Eingaben stimmte in unserem Offline-Test mit sechs Fällen nur beim unveränderten Fall überein. Der Hash der SKILL.md allein passte in jedem Fall. Ein Commit-Vergleich erkannte die beiden eingecheckten Repository-Änderungen, übersah aber Änderungen außerhalb dieses Quellstands. Die Ergebnisse messen Übereinstimmung mit einem früheren Prüfprotokoll. Ob Dateien schädlich sind, sagen sie nicht aus.
Der Versuch bestand 24 protokollierte Prüfungen mit Python 3.12.14 und Git 2.51.1. Er erzeugt harmlose Repositories mit einer Skill-Datei, einer README und zwei identischen ZIPs, die nur Text enthalten. Ein externer Download wird durch eine lokale Datei dargestellt. Außerdem kopiert das Skript eine bekannte Textdatei aus dem Archiv in ein separates Installationsverzeichnis.
Jeder Fall beginnt mit demselben Ausgangszustand und verändert eine Eingabe. Das Protokoll enthält den Commit, Hashes der Quelldateien, des Archivs und seiner Inhalte sowie Hashes der installierten Dateien. Die Identität des Herausgebers und Ausführungsrechte prüft dieser Versuch nicht. „Gleich“ bedeutet Übereinstimmung mit dem Ausgangsprotokoll. Bei „Anders“ müsste die Änderung erklärt werden, bevor die frühere Prüfung wieder als Freigabegrundlage dienen kann.
| Unabhängiger Fall | SKILL.md-Hash | Git-Commit | Alle Versuchseingaben | Was sich geändert hat |
|---|---|---|---|---|
| Unveränderter Ausgangszustand | Gleich | Gleich | Gleich | Nichts. |
| README verweist auf das andere eingecheckte ZIP | Gleich | Anders | Anders | Nur README-Inhalt und neuer Commit; beide ZIPs enthalten bereits denselben harmlosen Text. |
| Inhalt des eingecheckten ZIPs ändert sich | Gleich | Anders | Anders | Archivbytes und enthaltene Datei, als neue Revision eingecheckt. |
| Externe URL-Bezeichnung bleibt gleich; nachgebildeter Download ändert sich | Gleich | Gleich | Anders | Bytes des externen Archivs und seiner enthaltenen Datei. |
| Kopierte Installationsdatei ändert sich | Gleich | Gleich | Anders | Die installierte Textdatei. |
| Harmloses Neuverpacken des externen ZIPs | Gleich | Gleich | Anders | Nur der Archivkommentar; die enthaltene Datei bleibt identisch. |
Der README-Fall bleibt bewusst eng gefasst. Ein echter relativer Markdown-Link wechselt zwischen zwei bereits eingecheckten Archiven. Keines enthält Schadsoftware. Wer nur die Skill-Datei prüft, übersieht die geänderte Anweisung. Der Commit-Vergleich erkennt sie. So vermittelt der Versuch nicht den falschen Eindruck, eine korrekt festgelegte Commit-ID könne ein eingechecktes Archiv nicht binden.
Die Fälle mit externem Download und neu verpacktem Archiv sind hypothetische Erweiterungen des Prüfproblems. Daraus folgen keine zusätzlichen Befunde zu Roccias Repositories. Es wird keine URL aufgerufen: Eine lokale Datei steht für die heruntergeladenen Bytes.
Das Neuverpacken ist eine nützliche Negativkontrolle. Der Archiv-Hash ändert sich, obwohl der enthaltene Text gleich bleibt. Wer daraus sofort „Schadsoftware“ macht, behauptet mehr, als die Belege hergeben. Öffne die Prüfung erneut, untersuche die geänderte Verpackung und entscheide, ob ein neues Prüfprotokoll ausgestellt werden kann.
Pro Fall laufen vier Prüfungen: auf die exakt geänderten Felder, die Vergleichsergebnisse, das unveränderte Ausgangsprotokoll und einen sauberen Git-Arbeitsbaum. Sechs Fälle mal vier Prüfungen ergeben 24. Die Lücken des reinen Commit-Vergleichs entstehen also nicht dadurch, dass unbemerkt nicht eingecheckte Quelldateien verändert wurden.
Wie wiederholst du den Vergleich, ohne einen Installer auszuführen?
Lies zuerst den eigenständigen Quelltext des Versuchs. Danach kannst du den Vergleich mit seinen erzeugten Beispieldaten über Python und Git ausführen. Das Skript erstellt eigene harmlose Prüfobjekte und schreibt ein JSON-Ergebnis unter das gewählte Arbeitsverzeichnis. Du kannst weder ein Ziel-Repository noch eine Download-URL übergeben. Die erzeugten Dateien werden nie gestartet.
Lade den lesbaren Python-Quelltext des Versuchs und das protokollierte Ergebnis als JSON herunter. Du brauchst Python ab Version 3.10 und Git, aber keine zusätzlichen Python-Pakete. Nach der Quelltextprüfung führst du diese Befehle in dem Verzeichnis aus, in dem du die Datei gespeichert hast:
python3 readme-zip-review-lab.py \
--work-dir .agent-cache/readme-zip-review-lab
python3 -m json.tool \
.agent-cache/readme-zip-review-lab/results.jsonVergleiche für jeden Fall observed_controls mit expected_controls. Das Ergebnis enthält außerdem die tatsächlich geänderten Felder, Dateiinventare, Werkzeugversionen und den SHA-256 des Versuchsquelltexts. Eine fehlgeschlagene Prüfung bricht den Lauf ab. Eine alte Erfolgsdatei wird entfernt, bevor der nächste Lauf beginnt.
Das Ausgangsprotokoll liegt außerhalb der Verzeichnisse für Prüfobjekt und installierte Kopie. In einem eingesetzten System müsstest du diese Trennung zusätzlich durch Schreibschutz erzwingen. Dieser Versuch prüft lediglich, ob sein eigenes Protokoll während des Ablaufs unverändert bleibt.
Die Dateiinventare erfassen reguläre Pfade und Inhalte. Berechtigungen, Symlinks, das Entpacken beliebiger Archive, Signaturen, Agentenverhalten oder Änderungen zwischen Prüfung und Ausführung werden nicht bewertet. Der Fall mit der installierten Datei folgt auf das sichere Kopieren bekannten Texts. Er ist kein Grund, erst einen unbekannten Installer auszuführen und hinterher nach Schäden zu suchen.
Was beweisen eine feste Commit-ID und eine passende Prüfsumme?
Eine festgelegte Commit-ID identifiziert den ausgewählten Quellstand. Eine passende Prüfsumme belegt Byte-Übereinstimmung mit einer vertrauenswürdigen Referenz. Was das wert ist, hängt davon ab, was du geprüft hast und was die Installation verwendet. Ein korrekter Treffer kann eine schlechte Entscheidung fortschreiben. Eine harmlose Verpackungsänderung kann dagegen eine erklärungsbedürftige Abweichung erzeugen.
Unterscheide drei Objekte: eine im Repository gespeicherte ZIP-Datei, das von GitHub erzeugte Quellcodearchiv und einen Download von einem anderen Speicherort. Die erste Datei gehört zum ausgewählten Commit. Das zweite Objekt verpackt die Quellinhalte. Für das dritte brauchst du eigene Nachweise zum heruntergeladenen Artefakt.
Laut GitHubs Dokumentation zur Archivstabilität bewahren commitbasierte Archive ihre Dateiinhalte, solange der Commit verfügbar ist und der Repository-Name unverändert bleibt. Branches und Tags können auf andere Stände verschoben werden. GitHub trennt außerdem stabile entpackte Inhalte von komprimierten Archivbytes: Ändern sich die Komprimierungseinstellungen, können sich diese Bytes ändern.
Deshalb speichert der Versuch sowohl den Archiv-Hash als auch das Inventar seiner Inhalte. Ersetze einen abweichenden erwarteten Hash nicht stillschweigend durch den Wert des neuesten Downloads. Bewahre das alte Protokoll auf, kläre die Änderung und lasse die zuständige prüfende Person den Ersatz annehmen oder ablehnen. Sonst hält der Vergleich nur fest, was zuletzt angekommen ist.
Herkunftsnachweise beantworten einen anderen Teil der Prüfung. GitHubs Anleitung zu Artefakt-Attestierungen erklärt, wie verifizierte Attestierungen ein Artefakt mit seiner Quelle und seinen Build-Anweisungen verbinden. Die Anleitung stellt auch klar, dass eine Attestierung keine Sicherheit garantiert. Ob Herausgeber, Build-Prozess und Softwareverhalten deine Anforderungen erfüllen, musst du weiterhin entscheiden.
Binde die Verifikation schließlich an das Objekt, das tatsächlich gestartet wird. Löst der Launcher nach der Prüfung eine veränderliche Referenz erneut auf, beschreibt der frühere Vergleich diesen Abruf nicht mehr. Wir empfehlen, geprüfte Artefakte unter Kontrolle des Hosts bereitzustellen und ihren Austausch vor dem Start zu verhindern. Diese Durchsetzung prüft der Offline-Versuch nicht.
Wie setzt du die Freigabe außerhalb der Agentenanweisungen durch?
Nutze Kontrollen, die Abrufe, Dateiänderungen und Ausführung unabhängig von den Anweisungen der zu prüfenden Software steuern. Die Suche darf einen Vorschlag liefern. Welche Eingaben und Berechtigungen aktiviert werden dürfen, bestimmt eine geschützte Entscheidung. Halte Prüfprogramm und erwartetes Protokoll außerhalb der Schreibrechte des Prüfobjekts. Teste auf dem tatsächlichen Host, ob unerlaubte Aktionen abgewiesen werden.
„Installiere nur geprüfte Tools“ in eine Anweisungsdatei zu schreiben, kann deine Regel erklären. Durchgesetzt wird sie erst, wenn Client oder Laufzeitumgebung eine widersprechende Aktion stoppen. Die Berechtigungsdokumentation von Claude Code trennt ausdrücklich zwischen Regeln, die der Host durchsetzt, und Prompts oder CLAUDE.md. Letztere beeinflussen das Modellverhalten, ohne die vom Host gewährten Zugriffe zu ändern.
Ein Feld wird leicht falsch verstanden: Die Skill-Einstellung allowed-tools von Claude Code gibt die aufgeführten Tools für den aufrufenden Turn vorab frei. Das macht sie nicht zu den einzig aufrufbaren Tools. Für die übrigen gelten weiterhin die normalen Berechtigungen. Wer das Feld als einschränkende Allowlist liest, baut seine Prüfung auf einer falschen Annahme auf.
Prüfe auch die Prozessgrenze. Die Dokumentation zur Bash-Sandbox von Claude Code beschreibt Shell-Befehle und ihre Kindprozesse. Dort werden auch Hooks, lokale MCP-Server und weitere Hilfsprozesse genannt, die außerhalb dieser Sandbox laufen. Eine Grenze um den gesamten Prozess ist eine separate Deployment-Entscheidung. Unser Überblick zu Claude Mods und Function Hooks behandelt die Fähigkeiten solcher Erweiterungen genauer.
Bei Codex sind Freigaberegeln und Sandbox-Modus getrennte Einstellungen. Wenn Rückfragen entfallen, verschwindet dadurch nicht automatisch eine aktive Sandbox. Eine Freigabe belegt außerdem keine Unbedenklichkeit des Artefakts. Prüfe die wirksame Konfiguration der Umgebung, in der das Tool laufen wird.
Auch die MCP-Konfigurationsreferenz von Codex trennt Tool-Filter und Freigaben je Tool von Befehl, Argumenten, Umgebung und Arbeitsverzeichnis eines lokalen Servers. Die Namen aufrufbarer MCP-Tools einzuschränken, bewertet den Serverstart nicht und sperrt ihn auch nicht in eine Sandbox. Gib diesen Prozess frei, bevor du entscheidest, welche Methoden der Agent aufrufen darf.
Die MCP-Sicherheitshinweise zur Ein-Klick-Konfiguration lokaler Server verlangen, den exakten Befehl samt Argumenten anzuzeigen und eine ausdrückliche Zustimmung einzuholen. Außerdem empfehlen sie eine Sandbox mit möglichst geringen Rechten. Das sind Anforderungen an die implementierenden Clients. Diese Vorgaben belegen nicht, dass jeder Installationsweg sie bereits erfüllt.
Diese Grenzen stammen aus der Dokumentation. Unser Python-Versuch hat die Funktionen der Anbieter nicht getestet. Für die separate Prüfung der Laufzeitisolation nutze die Sicherheitscheckliste für Agenten-Sandboxes. Ein Dateivergleich vor der Installation ersetzt diese Prüfung nicht.
Welche Nachweise braucht dein Team vor der Aktivierung?
Halte eine Installationsentscheidung fest, die Eingaben, Ausführungsumfang, prüfende Person und Anlässe für eine erneute Prüfung benennt. Füge die Vergleichsnachweise und die Tests der Ablehnungsfälle auf dem Host hinzu. Ein anderer Engineer sollte daraus erkennen können, warum die installierte Version freigegeben ist. Die Selbstauskunft des Agenten darüber reicht als Grundlage nicht aus.
Für den Anfang genügt ein kleines Prüfprotokoll. Die folgenden Felder beschreiben Nachweise, die du selbst liefern musst. Das ist weder eine produktive Konfiguration noch eine Ausgabe des Versuchs:
decision: reviewed-for-local-test
source: <owner/repository and full commit>
artifact: <reviewed relative path or final URL>
archive_sha256: <digest of reviewed archive bytes>
installed_inventory: <protected file-manifest reference>
launch: <exact command, arguments and working directory>
scope: <filesystem, network and credential policy>
reviewer: <responsible person and review date>
recheck_on: [source, artifact, installed-files, launch, scope]Teste die Entscheidung dann dort, wo installiert wird. Die folgenden Abnahmenachweise sind unsere Empfehlung. Es handelt sich um vorgeschlagene Deployment-Prüfungen, getrennt von den beobachteten Offline-Ergebnissen.
| Vorgeschlagene Prüfung | Aufzubewahrender Nachweis |
|---|---|
| Der geprüfte Ausgangsstand kann seine vorgesehene Aufgabe erfüllen. | Ein positives Ergebnis ausschließlich mit den vereinbarten Zugriffsrechten. |
| Eine geänderte Eingabe erreicht die Installationskontrolle. | Der Host verweigert vor dem Start die Wiederverwendung der alten Entscheidung und benennt das geänderte Feld. |
| Das Prüfobjekt versucht, das erwartete Protokoll zu ersetzen. | Ein unabhängig durchgesetztes Schreibverbot bei unverändertem Protokoll. |
| Ein Launcher verlangt ein neues Ziel, neue Zugangsdaten oder einen neuen Dateisystempfad. | Eine Ablehnung oder separate autorisierte Entscheidung samt der wirksamen Regel, die dazu geführt hat. |
| Dateien ändern sich nach der Verifikation, aber vor der Ausführung. | Ein Nachweis, dass das bereitgestellte Objekt nicht ersetzt werden kann oder ein erneuter Vergleich den Start stoppt. |
Ordne jedem Fehlerfall eine verantwortliche Person zu. Bei abweichenden Bytes muss vielleicht ein Engineer ein neu verpacktes Archiv untersuchen. Bei neu angeforderten Zugangsdaten muss möglicherweise der Systemverantwortliche entscheiden, ob die Verwendung zulässig ist. Beides darf nicht hinter einem pauschalen „Fortfahren“ verschwinden.
Wenn dein Team diese Kontrollen in den Entwicklungsablauf einbauen will, deckt unser DevSecOps-Service Repository-, Build- und Release-Kontrollen ab. Das Abnahmekriterium bleibt konkret: Aktiviere die geprüfte Installation im vereinbarten Umfang. Ändert sich eines von beidem, braucht es eine neue Entscheidung.