<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Application-Security on .kais blog</title><link>https://blog.0x2e6b6169.de/tags/application-security/</link><description>Recent content in Application-Security on .kais blog</description><generator>Hugo</generator><language>de-de</language><lastBuildDate>Mon, 06 Apr 2026 07:35:00 +0200</lastBuildDate><atom:link href="https://blog.0x2e6b6169.de/tags/application-security/index.xml" rel="self" type="application/rss+xml"/><item><title>Die Auferstehung</title><link>https://blog.0x2e6b6169.de/posts/2026-04-06-die-auferstehung/</link><pubDate>Mon, 06 Apr 2026 07:35:00 +0200</pubDate><guid>https://blog.0x2e6b6169.de/posts/2026-04-06-die-auferstehung/</guid><description>&lt;h2 id="-der-erste-riss"&gt;🟡 Der erste Riss&lt;/h2&gt;
&lt;p&gt;SQL-Injection wurde 1998 dokumentiert. Sie steht seit mehr als 20 Jahren in den OWASP Top 10. MITRE nennt 15 Schwachstellen, die seit vielen Jahren in jeder CWE-Top-25 auftauchen, &amp;ldquo;Stubborn Weaknesses&amp;rdquo; – hartnäckige Schwachstellen. SQL-Injection (CWE-89) gehört dazu. Alle warnen davor. Und trotzdem ist sie Jahr für Jahr unter den häufigsten Schwachstellen in produktiven Systemen. Nicht weil niemand es weiß. Sondern weil Wissen nicht dasselbe ist wie Ausrotten.&lt;/p&gt;</description></item><item><title>Der Agent darf alles</title><link>https://blog.0x2e6b6169.de/posts/2026-04-03-agent-darf-alles/</link><pubDate>Fri, 03 Apr 2026 07:35:00 +0200</pubDate><guid>https://blog.0x2e6b6169.de/posts/2026-04-03-agent-darf-alles/</guid><description>&lt;h2 id="-was-beobachte-ich"&gt;🔍 Was beobachte ich?&lt;/h2&gt;
&lt;p&gt;KI-Agenten kommen mit Produktions-Credentials, Datenbankzugängen und Admin-Rechten ausgestattet. Die Argumentation: Einschränkungen kosten Zeit, und der Agent soll ja Dinge erledigen. Was ich sehe, sind Systeme, in denen ein autonomes System mit mehr Rechten läuft als die meisten menschlichen Beschäftigten.&lt;/p&gt;
&lt;h2 id="-was-soll-eigentlich-erreicht-werden"&gt;🎯 Was soll eigentlich erreicht werden?&lt;/h2&gt;
&lt;p&gt;Agenten sollen Aufgaben selbständig lösen – ohne ständige menschliche Intervention. Das ist legitim; KI-Agenten werden in Entwicklung, Betrieb und Security-Operations zunehmend eingesetzt.&lt;/p&gt;</description></item><item><title>Das SBOM-Feigenblatt</title><link>https://blog.0x2e6b6169.de/posts/2026-03-27-sbom-feigenblatt/</link><pubDate>Fri, 27 Mar 2026 07:35:00 +0100</pubDate><guid>https://blog.0x2e6b6169.de/posts/2026-03-27-sbom-feigenblatt/</guid><description>&lt;h2 id="-was-beobachte-ich"&gt;🔍 Was beobachte ich?&lt;/h2&gt;
&lt;p&gt;Zwei Versäumnisse, oft gleichzeitig: Ein SBOM wird einmalig erzeugt – nicht für jeden Build. Welche Komponentenversionen im letzten Release stecken? Unbekannt. Und selbst wo SBOMs existieren, werden sie nicht beobachtet. Ein neuer CVE für eine enthaltene Komponente bleibt unsichtbar – bis jemand zufällig nachschaut.&lt;/p&gt;
&lt;h2 id="-was-soll-eigentlich-erreicht-werden"&gt;🎯 Was soll eigentlich erreicht werden?&lt;/h2&gt;
&lt;p&gt;Zwei Dinge: wissen, was deployed ist – und wissen, ob das noch sicher ist. Der SBOM beantwortet die erste Frage: Er dokumentiert Komponentenversionen eines Builds. Die zweite beantwortet er nur, wenn er kontinuierlich gegen Schwachstellendatenbanken geprüft wird.&lt;/p&gt;</description></item><item><title>Das abgeschlossene Bedrohungsmodell</title><link>https://blog.0x2e6b6169.de/posts/2026-03-13-abgeschlossenes-bedrohungsmodell/</link><pubDate>Fri, 13 Mar 2026 07:35:00 +0100</pubDate><guid>https://blog.0x2e6b6169.de/posts/2026-03-13-abgeschlossenes-bedrohungsmodell/</guid><description>&lt;h2 id="-was-beobachte-ich"&gt;🔍 Was beobachte ich?&lt;/h2&gt;
&lt;p&gt;Die Threat-Modeling-Session liegt sechs Monate zurück. Damals war die Architektur überschaubar, die Abhängigkeiten bekannt. Seitdem kam ein neuer Cloud-Provider dazu, drei Bibliotheken wurden ausgetauscht, und die Auslieferungspipeline hat neue Wege in die Produktion bekommen. Das Bedrohungsmodell weiß davon nichts.&lt;/p&gt;
&lt;h2 id="-was-soll-eigentlich-erreicht-werden"&gt;🎯 Was soll eigentlich erreicht werden?&lt;/h2&gt;
&lt;p&gt;Threat Modeling soll Angriffsflächen sichtbar machen, bevor Angreifer sie finden. Das Threat Modeling Manifesto fordert Continuous Refinement: Das Bedrohungsmodell muss parallel zum System gepflegt, aktualisiert und verfeinert werden – nicht einmalig erstellt und abgelegt.&lt;/p&gt;</description></item><item><title>CRA – die stille Revolution ab September 2026</title><link>https://blog.0x2e6b6169.de/posts/2026-03-09-cra-stille-revolution/</link><pubDate>Mon, 09 Mar 2026 07:35:00 +0100</pubDate><guid>https://blog.0x2e6b6169.de/posts/2026-03-09-cra-stille-revolution/</guid><description>&lt;h2 id="-ein-déjà-vu-aus-den-achtzigern"&gt;🌍 Ein Déjà-vu aus den Achtzigern&lt;/h2&gt;
&lt;p&gt;Die EG-Produkthaftungsrichtlinie von 1985 war leise und folgenreich. Hersteller physischer Güter hafteten seitdem für Schäden ihrer Produkte. Wer Produkte baute, musste Sicherheit einplanen – nicht nachliefern. Die Autoindustrie nennt das heute selbstverständlich. Die Softwarewelt hat vier Jahrzehnte gebraucht, um denselben Gedanken zu Ende zu denken.&lt;/p&gt;
&lt;h2 id="-dieselbe-logik-digital"&gt;🔬 Dieselbe Logik, digital&lt;/h2&gt;
&lt;p&gt;Am 11. September 2026 beginnt Phase 1 des Cyber Resilience Act. Hersteller von Produkten mit digitalen Elementen müssen aktiv ausgenutzte Schwachstellen binnen 24 Stunden melden. Eine SBOM – eine maschinenlesbare Stückliste aller verbauten Softwarekomponenten – wird Pflicht. Hersteller stellen Sicherheitsupdates fünf Jahre lang kostenlos bereit. Die Sprache ist vertraut: Stückliste, Rückrufpflicht, Gewährleistungszeitraum. Nur das Produkt ist digital.&lt;/p&gt;</description></item><item><title>Vertrauen ist gut, Review ist besser</title><link>https://blog.0x2e6b6169.de/posts/2026-02-23-vertrauen-ist-gut/</link><pubDate>Mon, 23 Feb 2026 07:35:00 +0100</pubDate><guid>https://blog.0x2e6b6169.de/posts/2026-02-23-vertrauen-ist-gut/</guid><description>&lt;h2 id="-das-starke-argument"&gt;🤝 Das starke Argument&lt;/h2&gt;
&lt;p&gt;&amp;ldquo;KI-generierter Code durchläuft denselben Review-Prozess wie jeder andere Code.&amp;rdquo; Diesen Satz höre ich in fast jeder Diskussion über die Risiken von Copilot, Cursor und Co. Er klingt überzeugend, denn wer würde schon Code ohne Review in Produktion bringen?&lt;/p&gt;
&lt;h2 id="-was-daran-stimmt"&gt;⚖️ Was daran stimmt&lt;/h2&gt;
&lt;p&gt;Die meisten Teams haben tatsächlich Review-Prozesse etabliert, und statische Analyse fängt offensichtliche Fehler zuverlässig ab. KI-generierter Code ist syntaktisch sauber, oft sogar sauberer als menschlicher. Die Werkzeuge produzieren funktionierenden Code - das ist ihr Versprechen, und sie halten es oft.&lt;/p&gt;</description></item></channel></rss>