Willkommen zu allesnurgecloud.com – Ausgabe #237

bei Samsung wurde in dieser Woche ein 18-tägiger Streik abgewendet und Samsung hat sich mit der Gewerkschaft auf eine Einmalzahlung von umgerechnet 291.000 € pro Mitarbeitendem geeinigt. Aufgrund des Chipmangels ist die Kohle dafür wohl da und kein Problem – verrückt – aber bei einem Jahresgewinn von 189 Milliarden Euro kann man das wohl auch locker zahlen.

Ansonsten war die Woche voll mit GitHub-News und Security-Themen – wir kommen da einfach nicht zur Ruhe. Vor gerade mal 4 Wochen hatte ich ja die „Zero Day Clock“ verlinkt gehabt – Ende April war das. Da stand bei „Time-to-Exploit“ bei „1 Minute“ noch 2028 – wurde mittlerweile auf 2027 korrigiert. Wenn das so weitergeht, muss ich doch die BitCoins auf ein HW Wallet umziehen und mir Silber in den Tresor legen? Na hoffentlich nicht.

Diese Woche war ich dann noch außerhalb der Komfortzone, auf dem „Zwetschke Community Day“ in Augsburg unterwegs. Dort habe ich einen Vortrag mit dem Thema „Kein Budget, aber geile Ideen“ gehalten – mit vielen Marketing- und Vertriebsideen aus meinen Podcast-Learnings – zusammengesfasst. Die Kim von den Digitallotsen hat eine tolle Zusammenfassung zum Event geschrieben und für nächstes Jahr gibt es aktuell Early-Bird-Tickets.

In eigener Sache: Aktuell baue ich selbst ein kleines SaaS-Produkt – etwas, bei dem ich die ganzen Learnings von hier und aus dem Podcast mal anwenden kann. Es geht um eine komplett in Deutschland betriebene StatusPage – das Projekt heißt Statuswerk. Alle Daten werden in Deutschland verarbeitet, verschickt (E-Mail, SMS) oder verwaltet. Und dazu wird der Preis noch super attraktiv – falls du da was suchst, meld dich gerne auf der Warteliste an – dann gibts zum Launch im Juni ein Early-Bird-Angebot. Und der Fokus ist wirklich „nur“ Status Page – und das halt richtig machen.

So, und nun viel Spaß mit Ausgabe #237 und ein schönes Pfingstwochenende!

Happy Bootstrapping Podcast

In der aktuellen Podcast Folge 173 habe ich mit Christian Kirsch und Stefan Kirsch von amaiko.ai über ihren KI-Buddy für den Mittelstand gesprochen. Die beiden Brüder haben im Mai 2025 die amaiko GmbH zu 50/50 gegründet – eigenfinanziert, ohne Investoren. Heute 200 Anwender, bis Jahresende sollen es 3.000 Seats werden.
Wir reden über das Bruder-Co-Founding, zwei Reisen ins Silicon Valley und warum sie trotzdem im Bayerischen Wald geblieben sind, wie drei Senior-Entwickler mit Claude Code den Output von 20 bis 30 Leuten ersetzen und 140 Leads von der OMR. Gerne kannst du die Folge auf YouTube schauen oder wie immer bei Spotify, Apple und allen anderen Playern anhören.

allesnurgecloud.com ist ein kuratierter Newsletter mit Inhalten aus der Open-Source, Cloud und IT-Welt.
Für weiteren Content folge mir gerne auf Twitter, Mastodon oder LinkedIn.

Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren:

Supply-Chain-Doppelschlag: Nx Console und Megalodon

Der 18. Mai war für die Software-Lieferkette ein schlechter Tag – gleich zwei voneinander unabhängige Kampagnen liefen parallel und zeigen, wo die Goldadern für Angreifer mittlerweile liegen.

Nx Console: 18 Minuten, 3.800 GitHub-Repos. Eine kurz veröffentlichte manipulierte Version 18.95.0 der Nx-Console-Extension im VS-Code-Marketplace hat eine Kette ausgelöst, an deren Ende GitHub selbst stand: Rund 3.800 interne Repositories wurden laut TechCrunch von der Gruppe TeamPCP abgezogen. Die Mechanik: Tanstack-Kompromittierung leakt GitHub-Credentials eines Nx-Entwicklers über die gh-CLI, Angreifer pushen einen Orphan-Commit ins offizielle nrwl/nx-Repo, veröffentlichen 18.95.0, und beim ersten Workspace-Öffnen lädt die Extension einen 498-KB-Stealer nach – Ziel: Vault-, npm-, AWS-, GitHub- und 1Password-Tokens, ausgeleitet via HTTPS, GitHub-API und DNS-Tunneling. Microsoft meldete initial 28 Installs, Nx‘ Telemetrie sieht rund 6.000 Aktivierungen – die Marketplace-Statistiken kann man getrost vergessen. Bemerkenswert: Der Payload enthält volle Sigstore-Integration mit SLSA-Provenance-Generierung, also kryptografisch signierte Schadpakete inklusive.

Megalodon: 5.561 Repos in sechs Stunden. Parallel dazu lief eine zweite Operation, die Safedep-Forscher als Megalodon beschreiben: Zwischen 13:36 und 19:48 Uhr wurden 5.561 Repositories durch 5.718 bösartige Commits mit GitHub-Actions-Workflows samt Base64-Bash-Payload bestückt. Geerntet werden AWS-/GCP-Credentials, SSH-Keys, API-Keys, GitLab-/Bitbucket-/OIDC-Tokens, CI-Variablen und Docker-/Kubernetes-Configs. Betroffen ist unter anderem Tiledesk-Server (2.18.6 bis 2.18.12) mit einer ruhenden Backdoor, die via workflow_dispatch aktiviert werden kann. Die Commits stammen von Pseudo-Bots build-bot, auto-ci, ci-bot und pipeline-bot mit Fake-Mailadressen.

Zwei Vorfälle, ein Muster: CI-Token und Editor-Extensions sind die neuen Hochwertziele. Beide Kampagnen profitieren davon, dass Entwickler-Tooling laxere Reviews durchläuft als Produktionscode – ein Punkt, der bereits beim Polyfill-Vorfall in Ausgabe 148 und dem Amazon-Q-Debakel in Ausgabe 198 sichtbar wurde. Konkret jetzt: Nx auf 18.100.0 aktualisieren, betroffene Tiledesk-Versionen ablösen, Actions-Tab auf unerwartete workflow_dispatch-Runs prüfen, sämtliche erreichbaren Secrets rotieren.

Irgendwie kommt das Ökosystem gar nicht mehr zur Ruhe. Täglich überschlagen sich die Ereignisse, macht die KI die Software schneller sicherer, als dass die bösen Buben zuschlagen können?

GitHub says hackers stole data from thousands of internal repositories

---

Schufa zieht in die AWS European Sovereign Cloud

Die Schufa migriert nach eigener Pressemitteilung ihre Anwendungen in die seit 15. Januar 2026 betriebene AWS European Sovereign Cloud in Brandenburg – Dr. Klaus Kolitz, CTO der Schufa Holding, spricht von „maximaler Kontrolle, Transparenz und Sicherheit“. Konkret zieht zunächst der im März gestartete kostenlose Schufa-Account um, dazu Hilfeportal und der Service zur 100-Tage-Regelung. Im Datenbestand: Bonitätsinformationen zu 69 Millionen Privatpersonen und 6,6 Millionen Unternehmen.

Die Souveränitäts-Argumentation steht und fällt mit ein paar Kernzusagen: Betrieb, Governance und Support ausschließlich in der EU, Personal mit EU-Wohnsitz, vollständige Entkopplungsfähigkeit vom US-Mutterkonzern. BSI-Vizepräsident Thomas Caspers wird zitiert mit der Einschätzung, das werde ein „zukünftiges Standardbetriebsmodell“ – Na dann!

Schön und gut, aber die Gretchenfrage bleibt unbeantwortet, wie schon bei Ankündigung der Region in Ausgabe 122 diskutiert: Solange die Muttergesellschaft ein US-Konzern ist, gilt der CLOUD Act – und Microsofts Chefjustiziar Anton Carniaux hat unter Eid vor dem französischen Senat eingeräumt, US-Zugriffe nicht garantiert ausschließen zu können (Ausgabe 198). Bei AWS ist die rechtliche Konstruktion grundsätzlich identisch.

NextCloud-CEO Frank Karlitschek hatte das schon zum Launch knapp formuliert: „Souveränität ist die Abwesenheit starker Abhängigkeiten von Dritten. Die Souveräne Cloud von AWS ist hier Etikettenschwindel.“ Ob „Entkopplungsfähigkeit“ als technisches Versprechen die juristische Realität aushebelt, wird sich erst bei der ersten konkreten US-Anfrage zeigen – bis dahin ist das ein Marketing-Konstrukt mit BSI-Stempel.

Ausgerechnet ein Unternehmen, das wie kaum ein anderes auf Vertrauen seiner 69 Millionen Datensubjekte angewiesen ist, geht zu einem US-Hyperscaler – und nennt es Souveränität. Echte europäische Alternativen wie Scaleway, STACKIT, Ionos, UpCloud oder Gridscale standen offenbar nie zur Debatte. Muss ja eine wahnsinning komplexe Applikation sein.

SCHUFA geht als eines der ersten Unternehmen in Deutschland in AWS European Sovereign Cloud

---

---

Stress am Arbeitsplatz: 60 Jahre Forschung mit ironischer Pointe

Eine Metaanalyse von Forschenden der Auburn University, Old Dominion University und University of Illinois Urbana-Champaign hat mehr als 500 Studien aus 60 Jahren zusammengefasst – Daten von rund 800.000 Beschäftigten. Das Ergebnis: Drei Faktoren treiben das Stresslevel im Büro nach oben.

Da ist zum einen die Role Overload – schlicht zu viel Arbeit. Lösbar, indem Last abgenommen wird. Zweitens die Role Ambiguity: Wer nicht weiß, was er eigentlich tun soll, leidet bei Performance, Stimmung und Zugehörigkeit. Hilft nur Klärung durch Vorgesetzte. Hauptverdächtiger Nummer eins ist aber der Role Conflict – widersprüchliche Anweisungen, etwa wenn eine Führungskraft das eine sagt, die andere etwas Gegensätzliches. Studienleiterin Gargi Sawhney bringt es auf den Punkt: Arbeit wird mehrfach erledigt, der anhaltende Konflikt frisst sich rein. Role Conflict ist laut Metaanalyse die primäre Ursache für Kündigungen und Burnout.

Und genau hier kommt eine aktuelle Bitkom-Umfrage ins Spiel, fast schon ironisch passend. Befragt wurden 550 Erwerbstätige in Deutschland: 29 Prozent halten ihren Chef für durch KI ersetzbar, sich selbst hingegen nur 23 Prozent – Zwinkerslimie. Anders gesagt: Die Belegschaft hält ausgerechnet die Funktion für am ehesten automatisierbar, die laut der Metaanalyse für den meisten Stress sorgt. Weitere 22 Prozent geben an, im eigenen Unternehmen würden bereits Stellen wegen KI nicht mehr nachbesetzt.

Beim KI-Zugriff sieht es nüchterner aus: 38 Prozent haben Werkzeuge bereitgestellt bekommen, 27 Prozent nutzen sie aktiv, 11 Prozent ignorieren das Angebot. 57 Prozent arbeiten ohne firmenseitige KI-Lösung.

Susanne Dehmel von der Bitkom-Geschäftsleitung verweist auf die demografische Lücke und sieht KI als Antwort auf den Arbeitskräftemangel. Die Kombination beider Studien legt allerdings eine andere Lesart nahe: Wenn widersprüchliche Anweisungen der Hauptburnout-Treiber sind und ein Drittel der Belegschaft die eigene Führungsebene für automatisierbar hält, ist das weniger eine technische Frage als eine Management oder Kultur Frage. Auch im KI Zeitalter „isst Kultur Strategie zum Frühstück“ – manche Dinge ändern sich dann doch nicht.

Daten von 800.000 Angestellten zeigen: Das sind die größten Stressfaktoren am Arbeitsplatz

---

„I was laid off by Atlassian“ – acht Jahre Know-how in 40 Minuten

Ein 40-minütiges YouTube-Video eines anonymen Engineers hat seit dem 10. Mai 1,5 Millionen Aufrufe gesammelt. Der Inhalt ist auf den ersten Blick unspektakulär: Ein Senior Engineer, der nach acht Jahren bei Atlassian von der jüngsten Layoff-Welle erwischt wurde, erzählt, was er gebaut hat. Auf den zweiten Blick ist es ein Lehrstück über die Tiefe institutionellen Wissens, das in solchen Wellen entsorgt wird.

Worum geht es technisch? Der Engineer hat innerhalb seiner ersten zwei Jahre einen Open Service Broker in Python/FastAPI gebaut – Self-Service-Provisioning für interne Atlassian-Developer. Darauf aufbauend folgte eine Envoy-basierte Edge-Plattform als Ersatz für die teuren Enterprise-Loadbalancer, inklusive eigenem Control Plane (Open Source unter dem Namen „Sovereign“), AMI-Pipeline via Packer/Salt und CloudFormation-Templates für rund 2.000 Proxies über 13 Regionen. Anschließend die Migration von Jira, Confluence, Bitbucket und Statuspage hinter diese Infrastruktur, dazu Edge-Logik für Authentifizierung, Rate Limiting und Access Logs – teils nativ in Envoy, teils via Rust-Sidecars.

Die nicht-technischen Passagen sind ehrlicher und interessanter als das übliche Layoff-Postmortem. Er reflektiert über Diplomatie-Skills, Persönlichkeitskonflikte mit Vorgesetzten und die Schwierigkeit, einen Praktikanten zu betreuen, ohne selbst je mentored worden zu sein. Besonders pointiert: Code zu bauen ist einfach, Code über Jahre wartbar halten ist schwer. Er sieht skeptisch zu, wie Vibe-Coding-Apps und KI-Assistenten diese Last verschärfen werden, wenn niemand mehr versteht, was er gebaut hat.

Die Ironie ist nicht zu übersehen: Atlassian zwingt nach Ausgabe 203 seine eigenen Kunden mit der „Ascend“-Initiative bis 2029 vom Datacenter in die Cloud – und schmeißt parallel die Engineers raus, die die Cloud-Edge-Infrastruktur überhaupt erst gebaut haben. Dazu passt AWS-CEO Matt Garmans Warnung aus Ausgabe 217: Wer bei Mitarbeitern spart, zahlt später drauf – bei Atlassian fängt das offenbar nicht erst bei Junior-Devs an. Es trifft die Senioren, die die Plattform tragen. Auch das passt zur größeren Oracle-Welle aus Ausgabe 230 – nur dass es bei Atlassian ein einzelnes Gesicht und einen YouTube-Account bekommt.

I was laid off by Atlassian (YouTube)

---

Mythos bei Cloudflare: Vom Modell zum Harness

Cloudflares CSO Grant Bourzikas zieht im Blog eine Bilanz zu Anthropics Security-Modell Mythos Preview – dem gleichen Modell, das curl-Maintainer Daniel Stenberg in Ausgabe 236 eher nüchtern bewertet hatte. Anders als bei curl, das mit OSS-Fuzz und Coverity durchkämmt ist, lief Mythos hier gegen über fünfzig hauseigene Cloudflare-Repos.

Zwei Fähigkeiten heben sich laut Bourzikas ab. Exploit Chain Construction bedeutet, dass Mythos mehrere kleine Bugs zu einem funktionierenden Angriff verkettet – etwa Use-after-free zu Read/Write-Primitive zu ROP-Chain. Proof Generation geht weiter: Das Modell schreibt PoC-Code, kompiliert ihn in einer Sandbox, führt ihn aus, liest Fehler und passt die Hypothese an. Findings kommen mit Reproduktionsschritten statt Vermutungen.

Die zentrale Erkenntnis ist allerdings eine andere: Das Modell allein reiche nicht. Cloudflare hat eine mehrstufige Pipeline gebaut – ein Recon-Agent erstellt das Architekturbild, fünfzig Hunter laufen parallel, ein Gegenagent prüft jede Meldung mit dem Ziel, sie zu entkräften, danach folgen Dedupe, Trace und Report. Ein generischer Coding-Agent, einfach auf ein Repo angesetzt, bringe wenig: Vulnerability Research braucht viele schmale Fragen gleichzeitig, während Coding-Agents eine Hypothese nach der anderen abarbeiten. Finde ich eine interessante, wenn sicherlich auch sehr aufwendige Herangehensweise.

Überraschend ist dann Bourzikas‘ Hinweis zu Model Refusals. Mythos verweigerte teilweise legitime Security-Arbeit – derselbe Task in anderem Kontext bringt dann teilweise unterschiedliche Antworten. Die eingebauten Guardrails seien real, aber inkonsistent, was bedeutet: Externe Safeguards bleiben Pflicht.

Die Konsequenz für Security-Teams ist unbequem. Patches schneller ausrollen reicht nicht, wenn KI-gestütztes Bug-Finding den Angreifern denselben Hebel gibt. Das deckt sich mit der These vom Agent-zu-Agent-Krieg aus Ausgabe 233: Architektur muss Exploitation erschweren, selbst wenn Bugs existieren – statt das Zeitfenster zwischen Disclosure und Patch immer weiter zu verkleinern. Cloudflare kündigt entsprechende Produktankündigungen an. Spannend wird, ob sich die Harness-Methodik auf weniger gut ausgestattete Teams überträgt.

Project Glasswing: what Mythos showed us

---

Open Source Resistance: OSS auf Arbeitszeit, ohne zu fragen

Mike McQuaid, Homebrew-Project-Leader und Mit-Erfinder von GitHub Sponsors und Open Source Friday, hat ein Manifest namens „Open Source Resistance“ veröffentlicht – mit einer simplen Forderung: Maintainer, die in Firmen arbeiten, deren Geschäftsmodell auf Open Source läuft, sollen die nötige Pflege schlicht während der Arbeitszeit erledigen. Kein Antrag, kein Meeting, kein Manager-Segen.

Die Argumentation ist scharf. Open Source ist Infrastruktur, nicht Hobby – Unternehmen extrahieren täglich Wert daraus und bitten Maintainer dann, am Freitagnachmittag eine Bounty oder eine nette Erwähnung im All-Hands zu erbetteln. McQuaid zitiert Samba-Mitschöpfer Jeremy Allison aus 2012: „It’s the duty of all Free Software developers to steal as much time as they can from their employers for software freedom.“ Die übliche Kritik – das sei Zeitdiebstahl, Quiet Quitting, Risiko für den Job – pariert er ohne Umschweife: Wer Pull Requests reviewt, Dependencies aktualisiert und Bugs in Code fixt, von dem der Arbeitgeber lebt, der arbeitet, statt zu stehlen.

Das Manifest ist explizit ein Komplement, kein Ersatz für existierende Initiativen. Der Open Source Pledge von Sentry – 2.000 Dollar pro Entwickler und Jahr – bleibt ein begrüßenswerter Weg, und Sentry selbst hat 2024 750.000 Dollar verteilt. Nur: Die meisten Firmen machen nichts dergleichen. McQuaid spricht das aus, was core-js-Maintainer Denis Pushkarev schon 2023 mit „I’m fucking tired“ formuliert hatte: Das Modell ist kaputt, wenn 250 Millionen Monthly Downloads niemand bezahlt.

Die Caveats sind allerdings dick. McQuaid weist selbst darauf hin, dass Arbeitsverträge in vielen Ländern Code, der während der Arbeitszeit entsteht, automatisch dem Arbeitgeber zuschlagen. Die Empfehlung: IP-Carve-out vor Unterschrift verhandeln und GitHubs Balanced Employee IP Agreement als Vorlage nennen (kannte ich bisher nicht, du?). Der Ansatz ist außerdem stark für Senior-Maintainer, die etablierte Projekte pflegen – schwach für Junior-Stellen ohne Verhandlungsmasse.

Bleibt die ehrliche Variante: „Behandle Open-Source-Wartung als Engineering-Arbeit“ – das ist weniger Rebellion als Realität, der nur das Label fehlt. Wie läuft das bei dir so?

Keep OSS alive on company time

---

Buffer findet sieben vergessene Cronjobs – nach fünf Jahren

Buffer-Engineer Carlos Muñoz beschreibt im Blog, wie sein Team bei Routine-Wartungsarbeiten an SQS-Queues auf sieben Hintergrundprozesse stieß, die teils seit fünf Jahren still vor sich hin liefen – und absolut nichts Sinnvolles taten. Buffer betreibt als komplett verteiltes Team seinen Newsletter-Tooling-Stack auf AWS und hatte – wie viele andere – in den 2010ern den Microservices-Pfad eingeschlagen.

Das Highlight unter den Zombies: Ein Worker, der täglich die komplette Datenbank nach Geburtstagen scannte, um Glückwunsch-Mails zu verschicken. Beim Refactor 2020 wurde das Mail-Tool gewechselt, der Worker aber vergessen – und lief fünf weitere Jahre. Geschätzte Kosten allein für diesen Job: 360 bis 600 Dollar über die Laufzeit. Überschaubar finanziell, aber genau das ist nicht der Punkt.

Was Muñoz als eigentliches Problem identifiziert: Onboarding-Reibung und schleichende Wartungslast. Neue Engineers stolpern über mysteriöse Prozesse, trauen sich aber nicht, sie zu deaktivieren – „was, wenn es doch wichtig ist“. Security-Updates und Dependency-Bumps werden auf Code angewendet, der nichts mehr tut. Institutionelles Wissen verschwindet mit den Leuten, die es erzeugt haben.

Bemerkenswert ist Buffers Entdeckungsmechanismus. Das Team hatte den Microservices-Ansatz inzwischen wieder zugunsten eines Multi-Service-Monorepos aufgegeben – die Overhead-Kosten dutzender Repositories für ein Team dieser Größe waren zu hoch. Genau diese Konsolidierung machte das Finden der Zombies erst möglich: Eine zentrale Sicht auf alle Queues, Producer und Consumer zeigte sofort, welche Queues keine Abnehmer mehr hatten. Eine Erkenntnis, die Twilios „Goodbye Microservices“-Pfad aus Ausgabe 217 und die Diskussion zu versteckten Microservices-Kosten in Ausgabe 189 gut ergänzt.

Muñoz‘ Empfehlung ist pragmatisch: Jeder größere Refactor sollte als Archäologie-Übung verstanden werden – wer tief im System ist, soll fragen, was noch dranhängt und nicht mehr gebraucht wird. Beim Deprecaten eines Features bis zu den Hintergrundprozessen verfolgen, nicht nur den User-facing-Code. Und wenn jemand das Team verlässt, dokumentieren, was im Hintergrund läuft.

What We Learned After Finding 7 Forgotten Jobs Running for 5 Years

---

CISA leakt eigene AWS-GovCloud-Keys auf GitHub

Die Geschichte hat eine besondere Pointe: Ausgerechnet die US-Cybersicherheitsbehörde CISA ließ über ein Repository namens „Private-CISA“ wochenlang administrative Zugangsdaten zu drei AWS-GovCloud-Accounts sowie zahllosen internen Systemen öffentlich einsehbar – aufgespürt von GitGuardian-Researcher Guillaume Valadon, der laut Brian Krebs zunächst dachte, das Material sei eine Fälschung.

Die enthaltenen Dateien sprechen für sich. „importantAWStokens“ lieferte die GovCloud-Credentials, „AWS-Workspace-Firefox-Passwords.csv“ plaintext-Logins für dutzende interne Dienste, darunter „LZ-DSO“ – das Landing-Zone-DevSecOps-Environment der Agency. Philippe Caturegli von Seralys validierte, dass die Keys mit hohen Privilegien aktiv waren, und verweist auf besonders attraktive Ziele wie die interne Artifactory-Instanz: ein Einfallstor für persistente Backdoors in jedem zukünftigen Build.

Pikant sind die Detailbefunde. Der zuständige Admin – Mitarbeiter des Contractors Nightwing – hatte die GitHub-Funktion zur automatischen Secret-Erkennung explizit deaktiviert, etliche Passwörter folgten dem Schema „Plattformname + aktuelles Jahr“, und das Repository diente offenkundig als Sync-Mechanismus zwischen Arbeits- und Privatgerät. Nach der Benachrichtigung wurde der Account entfernt, die AWS-Keys blieben jedoch unerklärlicherweise weitere 48 Stunden gültig. Kann man sich nicht ausdenken.

CISA erklärt, es gebe „keine Hinweise auf kompromittierte Daten“ – eine Aussage, die bei einem seit November 2025 öffentlichen Repo schwer zu untermauern ist. Hintergrund: CISA hat seit Beginn der zweiten Trump-Administration knapp ein Drittel der Belegschaft verloren. Kann man sich nicht ausdenken (Wdh.).

Wer einen technischen Werkzeugkasten zum Auffinden solcher Leaks sucht: Tools wie Gitleaks und TruffleHog gehören in Pre-Commit-Hooks und CI-Pipelines, wie in Ausgabe 196 beschrieben – die Mechanik funktioniert ja in beide Richtungen.

CISA Admin Leaked AWS GovCloud Keys on Github

---

Turso beerdigt sein Bug-Bounty-Programm

Knapp ein Jahr lang zahlte das SQLite-Rewrite-Projekt 1.000 Dollar für jeden nachgewiesenen Bug, der zu Datenkorruption führt. In einem ungewöhnlich offenen Blog-Post erklärt CEO Glauber Costa, warum das Programm jetzt eingestellt wird: Die „Slop-Machine“ hat es unbenutzbar gemacht.

Anfangs lief es gut. Fünf Personen wurden ausgezahlt, einer wurde später angestellt, ein anderer fand mit formalen Methoden mehr als zehn Bugs in SQLite selbst. Der Anspruch lag hoch – Bug-Reports mussten den hauseigenen Deterministic Simulator erweitern, reines Finger-zeigen reichte nicht.

Dann kam der Schwall LLM-generierter PRs. Costas Beispiele sind unfreiwillig komisch: Ein Einreicher injizierte manuell Garbage Bytes in den Datenbank-Header und meldete dann eine korrupte Datenbank. Ein anderer modifizierte den Quellcode, um einen Out-of-Bounds-Array-Zugriff hinzuzufügen. Ein dritter PR „entdeckte“, dass eine SQL-Datenbank SQL-Statements ausführt. Ein implementiertes Vouching-System half kurz – bis Bots anfingen, Issues zu öffnen, die das automatische Schließen ihrer PRs anfechten.

Das Kernproblem bringt Costa nüchtern auf den Punkt: Ein Slop-PR kostet den Einreicher eine Minute, den Maintainer aber Stunden. Bei finanziellem Anreiz und beliebig skalierbarer Generierung kippt die Ökonomie.

Turso steht nicht allein. curl-Maintainer Daniel Stenberg hatte das HackerOne-Programm bereits im Januar beendet, weil die Quote bestätigter Reports von 15 % auf unter 5 % abgestürzt war. HackerOne selbst hat das Internet Bug Bounty im März pausiert.

The Wonders of AI: We Are Retiring Our Bug Bounty Program

---

Schmunzelecke

Das Alfred-Wegner-Institut sucht einen IT-Ingenieur für die Überwinterung an der Neumayer-Station III in der Antarktis – vielleicht hast du ja Bock?

Caching einfach erklärt – bei Instagram – da gibt es viele coole Videos von dem Dude.

---

💡 Link Tipps aus der Open Source Welt

Sessy – Open Source Email Observability für AWS SES

Sessy ist ein self-hosted Dashboard für AWS SES, das sichtbar macht, was nach dem Versand passiert: Zustellungen, Bounces, Complaints, Opens, Clicks und mehr. Gebaut von Marc Köhlbrugge (BetaList, WIP), bereits in Produktion bei mehreren Unternehmen.

Key Features:

• Echtzeit Event Tracking: Sends, Deliveries, Bounces, Complaints, Opens, Clicks, Rejects, Delays, Rendering Failures – alles durchsuchbar nach Empfänger oder Betreff, filterbar nach Typ und Zeitraum
• Bounce & Reputation Monitoring: Bounce-Raten nach Typ (permanent, transient, undetermined), Complaint-Spikes frühzeitig erkennen bevor AWS drosselt
• Engagement Analytics: Open/Click Tracking mit Unique Counts, 30-Tage Trend-Charts
• Multi-Source Management: Separate Email-Streams pro App oder Environment, jeweils eigene Webhook-URL, Dashboard und Retention Policy
• Keine AWS Credentials nötig: Einfach SNS Webhook in SES konfigurieren, Events fließen automatisch

Setup in 3 Schritten: Docker deployen, Webhook-URL in AWS SES eintragen, fertig. SQLite by Default, PostgreSQL optional. Keine externen Dependencies.

Kostenvergleich: 100k Emails/Monat kosten mit SES+Sessy ~10$, bei Postmark 177 $, bei Resend ~35$. Die teuren Services sind oft SES-Wrapper mit Dashboard-Aufpreis – genau das liefert Sessy kostenlos.

Tech Stack: Ruby on Rails 8.1, SQLite/PostgreSQL, Solid Queue. Deployment via Docker, Kamal oder Dokku.

Wer AWS SES nutzt und bisher blind ins Blaue sendet oder zu teuren Wrapper-Diensten wie Postmark oder Resend greift, bekommt mit Sessy genau das fehlende Puzzlestück. Das Setup ist erfrischend simpel – ein Docker-Befehl, ein Webhook, fertig. Inspiriert von 37signals‘ Fizzy, aber open-source. Eine gehostete Cloud-Variante ist angekündigt – mal schauen, was die dann kostet.

https://github.com/marckohlbrugge/sessy

LynxDB – Log Analytics in einem Single Binary

LynxDB ist eine leichtgewichtige Log-Analytics-Engine in einem einzigen Binary – ohne Dependencies, mit eigener Pipeline-Query-Sprache (Lynx Flow), Full-Text-Index und optionalem Cluster-Mode. Inspiriert von Splunk, ClickHouse und der Unix-Philosophie.

Key Features:

• Pipe Mode: Logs direkt aus stdin verarbeiten wie grep – kubectl logs deploy/api | lynxdb query '...' funktioniert ohne Server und Config
• Lynx Flow Query Language: Pipeline-Syntax von links nach rechts mit parse, let, where, group by, order by, take, join, CTEs. Teilweise SPL2-kompatibel
• Full-Text Search: FST Inverted Index + Roaring Bitmaps, Bloom Filters für Segment Skipping
• Columnar Storage: Custom .lsg Format mit Delta-Varint Timestamps, Dictionary Encoding, Gorilla XOR, LZ4 Kompression
• Materialized Views: Vorberechnete Aggregationen mit automatischem Query Rewrite – bis zu ~400x Speedup
• Drop-in Ingestion: Elasticsearch _bulk, OpenTelemetry OTLP, Splunk HEC kompatibel
• Sigma Rules: rsigma-generiertes SPL2 direkt ausführen
• Cluster Mode: --cluster.seeds für verteilten Betrieb mit S3-backed Shared Storage
• ~50 MB Idle Memory vs. Splunk (~12 GB) oder Elasticsearch (~1 GB+)

Geschrieben in Go (95%). Zero Config nötig, sensible Defaults für alles.

LynxDB trifft einen Nerv: Splunk-artige Analytics-Power, aber als einzelnes Binary ohne JVM, ohne Cluster-Pflicht, ohne Lizenzkosten. Der Pipe Mode macht es sofort nutzbar für Ad-hoc-Analyse, der Server Mode für persistente Nutzung. Die SPL2-Kompatibilität und Sigma-Rule-Support senken die Migrationshürde für Splunk-erfahrene Teams. Noch sehr früh (v0.1.8, 2 Contributors, nicht production-ready), aber als Konzept extrem vielversprechend.

https://github.com/lynxbase/lynxdb

❓ Feedback & Newsletter Abo

Vielen Dank, dass du es bis hierhin geschafft hast!
Kommentiere gerne oder schicke mir Inhalte, die du passend findest.

Falls dir die Inhalte gefallen haben, kannst du mir gerne auf Twitter folgen.
Gerne kannst du mir ein Bier ausgeben oder mal auf meiner Wunschliste vorbeischauen – Danke!

Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren: