Sicherheitsrisiken autonomer KI-Agenten und Agentic AI
Ein Entwickler installiert schnell ein kleines npm-Paket, weil es nach Hilfsfunktion klingt. Im Hintergrund arbeitet zugleich ein KI-Assistent, der Dateien, Uploads und generierte Artefakte in einem lokalen Arbeitsbereich ablegt. Genau diese Kombination macht den aktuellen Fall „Malware-Slop“ intere
Viele Unternehmen bauen derzeit interne KI-Werkzeuge mit erstaunlich ähnlichem Muster: ein FastAPI-Service vor einem LLM-Gateway, ein vLLM- oder LiteLLM-Endpunkt, ein MCP-Server für Tool-Zugriffe, dazu ein paar Middleware-Regeln für Admin-Pfade, Metriken oder Modellverwaltung. Genau diese pragmatisc
Viele Security-Programme sind darauf optimiert, Schwachstellen überhaupt zu finden: Scanner ausrollen, CVEs priorisieren, Findings in Tickets überführen. Das war lange der Engpass. Die jüngsten Zahlen aus Anthropics Project Glasswing zeigen, dass sich dieser Engpass verschiebt. Wenn KI-Modelle in ku
Ein moderner Software-Build lädt selten nur eigenen Code. Er zieht Pakete aus öffentlichen Registries, startet Installationsskripte, baut Container und verteilt Artefakte automatisch weiter. Genau darin liegt das Praxisproblem: Wenn ein legitimes Paketkonto, ein CI-Workflow oder ein Publishing-Token
Ein Linux-Server ist selten allein dadurch sicher, dass ein Angreifer „nur“ ein unprivilegiertes Konto besitzt. In modernen Umgebungen gibt es viele Wege zu einem solchen ersten Zugriff: ein kompromittierter Entwickler-Account, ein fehlkonfigurierter CI-Runner, ein schwaches Service-Konto, ein Conta
Viele Unternehmen testen KI-Coding-Agenten noch wie ein produktiveres Autocomplete. In der Praxis verschiebt sich der Einsatz aber schnell in eine andere Risikoklasse: Ein Agent soll nicht nur Code vorschlagen, sondern Repositories lesen, Tests ausführen, Datenbankmigrationen vorbereiten, Cloud-APIs
In vielen Sicherheitsprogrammen gilt noch immer eine unausgesprochene Priorität: Erst Identitäten härten, dann Phishing trainieren, danach Patch-Management verbessern. Das war lange plausibel, weil gestohlene Zugangsdaten und Social Engineering in vielen Breach-Analysen dominierten. Der neue Verizon
Viele Unternehmen haben ihre klassischen Software-Abhängigkeiten inzwischen besser im Griff: Paketmanager werden gescannt, Container-Images signiert, CI/CD-Pipelines härter konfiguriert. Ein Bereich bleibt in der Praxis aber oft erstaunlich unkontrolliert: die Entwicklungsumgebung selbst. VS-Code-Ex
Für viele Unternehmen ist GitHub längst nicht mehr nur ein Code-Archiv. Dort liegen Build-Workflows, Deployment-Skripte, Infrastrukturdefinitionen, Paketveröffentlichungen, Security-Scans und zunehmend auch KI-gestützte Entwicklungsprozesse. Wer in dieser Umgebung einen leistungsfähigen Token erbeut
Viele Unternehmen testen derzeit KI-Agenten nicht mehr nur im Chatfenster, sondern als kleine Dienste: ein Agent liest Tickets, ein zweiter ruft interne APIs auf, ein dritter fasst Ergebnisse zusammen. Genau an dieser Stelle entsteht ein neues Betriebsrisiko. Aus einem lokalen Experiment wird schnel
Viele Unternehmen haben sich an ein unbequemes Muster gewöhnt: Code wird schnell gebaut, Abhängigkeiten werden automatisch aktualisiert, Security-Scans laufen später in der Pipeline – und am Ende landet eine lange Liste potenzieller Schwachstellen bei Teams, die ohnehin unter Zeitdruck stehen. Das P
Viele Security-Programme verlassen sich inzwischen stärker auf technische Vertrauenssignale in der Software-Lieferkette: signierte Builds, Provenance-Attestierungen, reproduzierbare Pipelines und automatisierte Dependency-Scanner. Das ist richtig und überfällig. Der aktuelle Mini-Shai-Hulud-Vorfall
