Das große Ganze absichern
Sie können eine Anwendung pentesten und jedes Finding beheben — und trotzdem kompromittiert werden, weil die Build-Pipeline gehackt wurde oder ein Dependency-Auto-Update ein bösartiges Paket eingezogen hat. Security hört nicht beim Anwendungscode auf.
Um die Sicherheitslage eines Projekts oder Unternehmens wirklich zu verbessern, müssen sowohl die Anwendung als auch die Architektur adressiert werden — aber eben auch der Software-Entwicklungsprozess (SDLC) selbst. Er braucht Security Controls auf Prozess- und funktionaler Ebene:
Tools sind gut, aber was passiert mit deren Ergebnissen?
Dieses Muster sehe ich regelmäßig: Ein Team integriert SAST- und SCA-Scanner in die CI/CD-Pipeline, wird von der initialen Flut an Findings überwältigt und ignoriert dann entweder die meisten davon oder schaltet die Scanner komplett ab. Die Tools waren in Ordnung. Der Prozess darum herum nicht.
Nachdem Build-Pipelines um DevSecOps-Elemente erweitert wurden, sind prozessbezogene Fragen wie Finding-Konsolidierung, False-Positive-Management, Baseline-Handling und vieles mehr entscheidend dafür, ob Security Scanning tatsächlich als fester Bestandteil des Entwicklungs-Workflows bestehen bleibt.
Herausforderungen agiler Organisationen
Agile Teams haben die Möglichkeit, dedizierte Security Sprints einzuplanen und die dringendsten Security-Themen anzugehen. Das erfordert auch die Unterstützung von Management und Product Ownern. An dieser Stelle hilft Awareness-Training dabei, alle Stakeholder für eine Security-Kultur zu gewinnen und den Raum für gezielte nicht-funktionale Verbesserungen zu schaffen. Dazu gehört auch, Fortschritte unternehmensweit über Dashboards sichtbar zu machen und Trends zu erkennen, um Verbesserungen auf die Bereiche mit dem größten Hebel auszurichten.
Verteilte Entwicklungsteams
Für geographisch verteilte Entwicklungsteams (einschließlich Off- und Nearshore) und besonders bei den heutigen Home-Office-basierten Teamaufteilungen ist es entscheidend, die Wege abzusichern, auf denen Code entsteht und wie er in die Produktion fließt. Ziel ist es, die Angriffsfläche für Supply-Chain-Angriffe ganzheitlich zu betrachten, einschließlich Entwicklungsumgebungen, Build-Pipelines und verwendeter Base-Images.
Cloud & Container
Selbst Kleinigkeiten — manchmal auch Überbleibsel — wie fehlende automatisierte Checks gegen versehentliches Einchecken von Secrets oder versehentlich ungeschützten Cloud-Storage-Buckets reichen Hackern oft aus. Korrektes und sicheres Management von Secrets (wie Keys, Passwörtern, Tokens, Zertifikaten usw.) in Produktionssystemen umfasst nicht nur technische Elemente wie Vaults. Neben komplexeren technischen Aspekten müssen auch organisatorische Aspekte adressiert werden, insbesondere wenn Cloud-Umgebungen und Container-Plattformen im Einsatz sind.
Forensische Bereitschaft
Was passiert, wenn tatsächlich ein Sicherheitsvorfall eintritt?
Diese Antwort sollte vor dem Vorfall existieren, nicht mittendrin. Ihre Organisation muss ihre DFIR-Readiness (Digital Forensics & Incident Response) bewerten: Können Sie kompromittierte Systeme schnell identifizieren und isolieren und dabei Beweismaterial sichern? Haben Sie die Fähigkeit, diese forensisch zu analysieren, Indicators of Compromise (IoC) zu sammeln, kompromittierte Keys und Zertifikate zu rotieren? Und können Sie feststellen, ob Daten exfiltriert wurden — auch über weniger offensichtliche Kanäle wie DNS-basierte Out-of-Band-Exfiltration?
Review-Ziel
Wie die Beispiele oben zeigen, geht die tatsächliche Sicherheitslage einer Organisation weit über technische Aspekte hinaus…
Sie umfasst auch Menschen und Prozesse sowie deren Zusammenspiel als Teil einer starken Security-Strategie. Genau darum geht es bei diesem Review: Stellen finden, an denen Verbesserungen möglich sind, und Orientierung in Form einer Roadmap liefern.
Da jede Organisation einzigartig ist, erstelle ich den Audit-Katalog üblicherweise in enger Zusammenarbeit mit dem Security-Team des Kundenunternehmens. Dieser dient als Grundlage für einen strukturierten Projekt-Review- und Verbesserungsprozess, um Stufen (oder Belts) festzulegen, ein Scorecard-Schema aufzubauen und Roadmap-Schritte zu definieren, die ein hohes Security-Niveau erreichen und halten. Da die meisten Process Reviews sehr individuell auf Ihr Unternehmen und Ihre aktuellen Anforderungen zugeschnitten sind: Lassen Sie uns sprechen
Diese Leistung unterstützt auch technische Security-Anforderungen, die in modernen Cybersecurity-Regulierungen häufig gefordert werden.