@ansiblegames not really tbh; given the current landscape of leaks, I'm still concerned about the dual-use case, especially regarding "black-n-white usage", or the fine line between defensive and offensive ('redsec') usage if that fits better...
that being said, I plan to release some of my tools on GitHub pretty soon to allow for audits and 'am I compromised?' self-checks, featuring full network traffic analysis and smart instant shielding by using your local ollama/ vLLM on ya own.
the actual tool set I use by myself is described on malick.cloud :3
@isaaclyman Youâre actually hitting on a very real dilemma. Itâs not heresy; itâs a survival instinct. With 'Software Supply Chain Failures' (OWASP A03) becoming a top-tier threat, blind updates are genuinely scary.
The problem is the sheer scale we're seeing this year. Weâre hit with over 130 new CVEs every single day, and AI-driven reconnaissance has shrunk the window to find an open flank from days to minutes. Weâre essentially stuck in a 'Security Paradox': Updating might compromise your supply chain, but staying obsolete makes you a sitting duck for bots that find you in seconds. Thereâs no easy win anymore I guess đ«
#Anthropics #Claude hat völlig autonom einen Root-Exploit fĂŒr #FreeBSD gebaut. In exakt vier Stunden. Wir reden hier nicht von einem simplen "Schreib mir ein #Python-Skript"-Prompt, sondern von echtem, iterativem #hacking Das Modell hat die #Schwachstelle im Netzwerk-Login gefunden, sich selbstĂ€ndig ein Lab hochgezogen, den #Payload smart in mehrere Pakete gesplittet und den eigenen Code knallhart gedebuggt, wenn der erste Versuch gecrasht ist.
Der ganze Bericht unter
Wir befinden uns aktuell in einer ziemlich toxischen Beschleunigungsspirale.
Alle wollen "shippen", schnell iterieren und in Rekordzeit live gehen. Ist ja auch erstmal verlockend, wenn einem der AI-Companion die halbe Codebase runtertippt und die Pipeline das Ganze in Minuten auf den Server schiebt.
Aber wĂ€hrend wir uns ĂŒber die gewonnene Zeit freuen, bauen wir kollektiv eine gigantische technische Schuld auf Seiten der Security auf.
Es ist lĂ€ngst nicht mehr DIE EINE kritische LĂŒcke, die einem schlaflose NĂ€chte bereitet. Es ist die schiere Masse an Einfallstoren entlang der kompletten Kette; vom hastigen Package-Install bis zum finalen Deployment.
Proof me wrong, aber wir reiten uns akut von zwei Seiten extrem rapide rein:
đ„ïž Die Infrastruktur-Ignoranz: Admins und DevOps-Konzepte, die aus reiner Bequemlichkeit (oder schlichtem Zeitdruck?) Server und Datenbanken nicht konsequent limitieren. Everything open, Firewalls auf Durchzug, Protokolle nicht abgeriegelt.
đ€Ż Der Verlust der Fundamentals: Eine Developer-Kultur, die Code dank AI oft nur noch orchestriert, aber nicht mehr zwingend versteht. Wer die Basics unter der Haube nicht mehr greifen kann, erkennt eben auch die Security-Implikationen eines generierten Snippets nicht.
Ich denke, ich lehne mich gar nicht so weit aus dem Fenster, wenn ich behaupte, dass dieser Umstand- gepaart mit der aktuellen Entwicklung- eine ziemlich explosive Mischung ist.
AI ist eben nicht nur unser Katalysator, sondern auch der der Gegenseite. Die Angreifer nutzen exakt dieselben Wunderwaffen zur automatisierten Schwachstellensuche. Neue Zero-Days, Exploit-Injections in die CDN-Pipe und kritische CVEs fliegen uns fast tÀglich um die Ohren.
FrĂŒher haben ein paar etablierte Best-Practices und Standards gereicht, um das System zumindest mal mittelfristig abzusichern. Spoiler: Das war mal đ« Durch die rohe, automatisierte Rechenpower da drauĂen ist das Zeitfenster zwischen "Deploy" und "Exploit" massiv geschrumpft. Die EinschlĂ€ge passieren oft schon dann, wenn der Kaffee nach dem Push noch warm ist.
Security als lÀstiges "machen wir im nÀchsten Sprint"-Ticket oder ein "Security by Obscurity"-Gedanke reichen einfach nicht mehr. Wenn das Fundament bröckelt, bringt die schnellste Pipeline nichts.
Ryan @ Ansible Games & CDF