Sichere Entwicklung on .kais blog

Quellcode-Gläubigkeit

Wed, 09 Sep 2026 07:35:00 +0200

🔍 Was beobachte ich?

Code-Review, SAST, Dependency-Scan: Die gesamte Prüfarbeit richtet sich auf den Quelltext. Nach Compiler, Build-Image und Pipeline-Plugins frage ich meist vergeblich. Sie gelten als Werkzeug, nicht als Angriffsfläche.

🎯 Was soll eigentlich erreicht werden?

Ausgeliefert werden soll nur, was geprüft wurde. Der Quelltext ist dafür der naheliegende Ort: lesbar, versioniert, nachvollziehbar.

⚠️ Warum funktioniert das nicht?

Ken Thompson hat 1983 in seinem Turing-Award-Vortrag „Reflections on Trusting Trust“ vorgeführt, warum das nicht reicht. Er präparierte einen C-Compiler: Beim Übersetzen des Login-Programms baute dieser eine Hintertür ein. Und beim Übersetzen seiner selbst gab er genau diese Fähigkeit an die nächste Compiler-Fassung weiter. Danach ließ sich der Compiler-Quelltext säubern: Die Hintertür lebte im Binary weiter – sichtbar war sie in keiner einzigen Zeile. Ausgeliefert wird nicht, was man liest, sondern was das Werkzeug daraus macht.

Nichts Neues seit 1975

Mon, 07 Sep 2026 07:35:00 +0200

📜 Ein Papier mit langem Bart

Jerome Saltzer und Michael Schroeder formulierten acht Prinzipien für den Bau von Schutzmechanismen. Entstanden sind sie bei der Arbeit an Multics, einem Betriebssystem, das heute niemand mehr betreibt. Wer sie zitiert, wirkt wie jemand, der zur Cloud-Migration ein Lochkartenhandbuch aufschlägt. Die acht Sätze reden aber nicht über Technik, sondern darüber, wer im System entscheiden darf. Das hat sich nicht geändert.

Die fremde Gewichtung

Fri, 14 Aug 2026 07:35:00 +0200

🔍 Was beobachte ich?

Schwachstellen bekommen einen CVSS-Wert, Bedrohungen eine DREAD-Summe, Risiken eine Farbe in der Matrix. Danach streiten alle über die Zahl, nie über den Weg dorthin. Ich habe früher selbst nach Score sortiert und das für Priorisierung gehalten.

🎯 Was soll eigentlich erreicht werden?

Vergleichbarkeit. Aus vielen Einzelmerkmalen soll eine Reihenfolge werden, an der sich Aufwand, Budget und Termine festmachen lassen.

Die KI hat's geprüft

Fri, 07 Aug 2026 07:35:00 +0200

🔍 Was beobachte ich?

Ich sehe Pull-Requests, in denen jede Zeile aus einem Modell stammt – auch das Review darunter. Ein Agent generiert, ein zweiter prüft, ein dritter schreibt die Zusammenfassung. Wer freigibt, liest meist nur diese Zusammenfassung.

🎯 Was soll eigentlich erreicht werden?

Die Prüfung soll mit der Produktion Schritt halten. Wenn KI den Code-Ausstoß vervielfacht, wird das menschliche Review zum Engpass – und dieser Engpass ist real, nicht wegzuorganisieren. NIST SSDF verlangt ohnehin nur, dass geprüft wird, nicht dass ein Mensch prüft.

Eins hochzählen genügt

Fri, 03 Jul 2026 07:35:00 +0200

🔍 Was beobachte ich?

Eine App sammelt Ausweise zur Altersprüfung und legt die Bilder an URLs ab, die schlicht durchnummeriert sind. Wer eine Mitglieds-ID um eins erhöht, sieht den nächsten Pass. Keine Anmeldung, keine Prüfung, wer da zugreift. Genau das ist im Juni beim Cannabis-Club-Dienstleister Nefos bekannt geworden.

🎯 Was soll eigentlich erreicht werden?

Das Ziel ist legitim: Altersverifikation und Mitgliederverwaltung. Schon das Mittel ist fragwürdig – vollständige Ausweise zu sammeln, setzt in Deutschland etwa das Personalausweisgesetz enge Grenzen, und für den reinen Altersnachweis gäbe es längst die eID. Doch das eigentliche Versagen liegt woanders.

Die Datenmonokultur

Fri, 05 Jun 2026 07:35:00 +0200

🔍 Was beobachte ich?

Viele Schwachstellen-Prozesse hängen an einer einzigen Quelle: der National Vulnerability Database. Werkzeuge gleichen Software gegen NVD-Daten ab, das Ergebnis landet ungeprüft im Report. Fehlt dort ein Eintrag, gilt die Komponente als unauffällig.

🎯 Was soll eigentlich erreicht werden?

Das Ziel ist legitim: maschinenlesbare, angereicherte Schwachstellendaten – CPE, CWE, CVSS – als Fundament für automatisiertes Scanning und SBOM-Abgleich. Über Jahre war die NVD dafür der De-facto-Standard.

Wenn jeder alles findet

Fri, 22 May 2026 07:35:00 +0200

🔍 Was beobachte ich?

In M365-Umgebungen wächst Oversharing still: Zugriffsrechte werden breit geteilt und kaum je zurückgenommen. Jedes Projekt erstellt eine Teams-Site, jede Abteilung ihre SharePoint-Gruppe. Wer einmal Zugriff bekommt, behält ihn – nach Projektende, nach Rollenwechseln, nach Jahren. Die Organisation fokussiert sich auf privilegierte Zugänge und Admin-Accounts. Auf Endnutzerberechtigungen schaut niemand.

🎯 Was soll eigentlich erreicht werden?

Das Least-Privilege-Prinzip: Zugriff nur auf das, was gerade gebraucht wird. In der Praxis fragt man schneller nach neuem Zugriff, als Governance-Prozesse hinterherkommen.

Vibe Coding als Methode

Fri, 15 May 2026 07:35:00 +0200

🔍 Was beobachte ich?

In Kickoffs höre ich neuerdings: „Das vibe-coden wir mit Lovable." Zwei Sätze später ist der Prototyp live, ohne Threat-Model, ohne Code-Review, ohne Dependency-Liste. Was die KI vorschlägt, gilt als gebaut, sobald das Gefühl stimmt.

🎯 Was soll eigentlich erreicht werden?

Schnellere Wertschöpfung. Wer in natürlicher Sprache prototypen kann, springt direkt von Idee zu Demo – ohne sechs Tickets, drei Reviews und eine SAST-Pipeline.

Gut genug war gestern

Mon, 20 Apr 2026 07:35:00 +0200

📌 Die bequeme Wahrheit

„Gut genug" galt lange als Pragmatismus, nicht als Versagen. Wer Security als Qualitätskriterium über den gesamten Entwicklungszyklus forderte, galt als weltfremd. Schließlich lief Software seit Jahrzehnten – kritische Systeme inklusive –, ohne dass das Schlimmste regelmäßig eintrat. Sicherheitslücken wurden gefunden und irgendwann geschlossen. Prävention war teuer, die Nachfrage nach ihr begrenzt. Die Kosten für mehr Sorgfalt standen in keinem vernünftigen Verhältnis zum erlebten Nutzen. Zumindest schien es so.

Magic Security Dust

Wed, 15 Apr 2026 07:35:00 +0200

🔍 Was beobachte ich?

Features werden entwickelt, dann kommt Security als letzter Schritt. WAF davor, TLS drauf, Audit-Log angehängt – fertig. Design-Entscheidungen wie hartcodierte Credentials, fehlende Authentifizierung oder unnötige Netzwerkzugriffe sind dabei bereits in Stein gemeißelt.

🎯 Was soll eigentlich erreicht werden?

Sicherheit. Compliance. Vertrauen. CISA fordert in seinen Secure-by-Design-Prinzipien genau das: Security muss eingebettet sein – nicht als Schicht obendrauf. Die Idee ist richtig. Die Umsetzung kommt meist zu spät.

Die Auferstehung

Mon, 06 Apr 2026 07:35:00 +0200

🟡 Der erste Riss

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, “Stubborn Weaknesses” – 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.

Der Agent darf alles

Fri, 03 Apr 2026 07:35:00 +0200

🔍 Was beobachte ich?

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.

🎯 Was soll eigentlich erreicht werden?

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.

Das SBOM-Feigenblatt

Fri, 27 Mar 2026 07:35:00 +0100

🔍 Was beobachte ich?

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.

🎯 Was soll eigentlich erreicht werden?

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.

Das abgeschlossene Bedrohungsmodell

Fri, 13 Mar 2026 07:35:00 +0100

🔍 Was beobachte ich?

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.

🎯 Was soll eigentlich erreicht werden?

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.

CRA – die stille Revolution ab September 2026

Mon, 09 Mar 2026 07:35:00 +0100

🌍 Ein Déjà-vu aus den Achtzigern

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.

🔬 Dieselbe Logik, digital

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.

Vertrauen ist gut, Review ist besser

Mon, 23 Feb 2026 07:35:00 +0100

🤝 Das starke Argument

“KI-generierter Code durchläuft denselben Review-Prozess wie jeder andere Code.” 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?

⚖️ Was daran stimmt

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.