Shift Left scheiterte: Sicherheit muss sich im Stack bewegen, um Geschwindigkeit zu erreichen, ohne Kontrolle zu opfern

Seit Jahren haben wir ein Mantra wiederholt: Sie müssen "die Sicherheit nach links bewegen" und die Entwickler bitten, mehr Sicherheitsaufgaben beim Schreiben und Testen von Code zu übernehmen. Die Idee war verführerisch: Probleme früh zu beheben ist billiger, und wenn Entwicklungsteams von Anfang an überprüfen, wird alles schneller und sicherer. Die Realität zeigt jedoch, dass diese "linke Verschiebung" Wette das zentrale Problem nicht löste. In vielen Umgebungen hat sich die Spannung zwischen Geschwindigkeit und Sicherheit verstärkt und vor allem die Entwickler haben eine untragbare kognitive Belastung beendet.

Das Problem ist nicht die Faulheit der Entwickler; es ist das Anreizmodell und der Druck schnell zu liefern. Wenn Unternehmen Funktionalitäten, kurzfristige und messbare Ergebnisse erfordert, ist es Lieferung, die eine Prämie ist. Wenn eine Sicherheitsüberprüfung Stunden dauert und den Bau blockiert, erscheint der Druck, um ihn zu ziehen natürlich. In diesem Zuchtbestand ermöglichen pragmatische Lösungen wie das Ziehen von öffentlichen Bildern aus Registen Fortschritte, aber auch Risiken, die schwer zu kontrollieren sind.

Ein gutes Beispiel dafür ist die eigene Analyse der Branche. Das Qualys-Forschungsteam untersuchte Zehntausende von öffentlichen Containerbildern und fand alarmierende Ergebnisse: aus einer sehr breiten Probe präsentierten Tausende von Bildern schädliches Verhalten oder sensible Inhalte eingebettet. Unter diesen Erkenntnissen wurden Kryptominery in einen großen Teil der böswilligen und geheimen Proben (AWS-Tasten, GitHub-Token, Datenbank-Berechtigungen) innerhalb der Bildschichten integriert. Sie können den Bericht und technische Details im Qualys Blog über diese Studie lesen Hier..

Der konzeptionelle Fehler besteht darin, öffentliche Repositories als kuratierte und zuverlässige Bibliotheken standardmäßig zu behandeln. Plattformen wie Docker Hub, Cloud-Anbieter-Aufzeichnungen und andere öffentliche Dienste erleichtern die Verbreitung, aber die bloße Präsenz eines Bildes in diesen Räumen garantiert nicht, dass es sicher ist. Download eines offenen Bildes ist im Wesentlichen eine Entscheidung des Vertrauens; und dieses Vertrauen kann falsch platziert werden.

Und was machst du? Die Antwort ist, die Sicherheit in eine andere Richtung zu bewegen: nicht mehr "links verschieben" nur auf der Schulter des Entwicklers, sondern eine Strategie, die Verantwortung reduziert und Kontrollen an die Infrastruktur und Plattformschicht. Anstatt jeden Ingenieur zu bitten, sich manuell an das Scannen, Härten und Vorsprechen zu erinnern, müssen wir sichere Wege anbieten, die einfach und schnell zu folgen sind.

Ein Schlüsselstück ist die Erstellung eines internen Repository, das als Quarantäne externer Artefakte fungiert. Alle externen Bilder sollten durch eine Proxy oder interne Registrierung gehen, die Artefakte inspiziert, markiert und genehmigt, bevor sie in die Pipeline gelangen. Gerätemanagement-Tools wie Harbor können helfen, diese Art von Zwischenschicht zu bauen und Akzeptanzpolitiken zu automatisieren; siehe mehr im Projekt Harbor.

In der Praxis ist es auch wert, einen "goldenen Pfad" für Entwickler zu definieren: Standardvorlagen, genehmigte Basisbilder und offizielle Pipelines, die Standardsicherheit garantieren. Wenn die Teams diesem Weg folgen, wird Sicherheit etwas transparent für sie. Wenn jemand aus dem Muster herauskommen muss, dann erfordert es zusätzliche Bewertungen und manuelle Prozesse, die dieses Risiko für das Unternehmen rechtfertigen.

Politik- und Kontrollinstrumente in der Infrastruktur sind Teil der Lösung. Declarative Richtlinien, die mit Terraform-Modulen, Crossplane-Zusammensetzungen oder Regeln in Open Policy Agent angewendet werden, verhindern repetitive menschliche Fehler: z.B. verhindern Sie unversionierte S3-Bucket oder weigern Sie sich, mit Bildern anzuzeigen, die keine Mindestanforderungen erfüllen. Open Policy Agent bietet einen Rahmen für die Kodierung dieser Arten von Einschränkungen und kann in Pipelines und Zulassungsregler integriert werden; Beratung Open Policy Agent für weitere Informationen.

Ebenso muss die Automatisierung sowohl die Erkennung als auch die Reaktion abdecken. Containerscans müssen innerhalb der CI / CD ausgeführt werden und Kubernetes' Zulassungsregler sollten verhindern, dass Behälter mit kritischen Sicherheitslücken den Cluster erreichen. In der Laufzeit sollten die Werkzeuge nicht auf die Generierung von Warnungen beschränkt sein; angesichts des bewährten schädlichen Verhaltens sollte das System in der Lage sein, kompromittierte Belastungen zu isolieren und zu töten, und sogar Markierungsknoten für automatische Eindämmung. Die offizielle Dokumentation zu Zulassungskontrollern in Kubernetes erklärt, wie diese Mechanismen funktionieren: Kubernetes Zulassungsregler.

Es ist auch intelligent, Ansätze zu übernehmen, die die Korrektur automatisieren: Wenn eine Schwachstelle in einem Basisbild erkannt wird, kann die Plattform eine Pull Request generieren, um sie automatisch zu aktualisieren und nach der Validierung die sichere Version zu fördern. Diese Art von Fluss reduziert die Belichtungszeit und reduziert die Belastung von Geräten, die nicht ihre Zeit auf repetitive Wartungsaufgaben verbringen sollten.

Dies bedeutet nicht, dass die Sicherheit die Arbeit mit der Entwicklung stoppen wird; im Gegenteil, es erfordert eine nähere und proaktivere Beziehung. Sicherheit und Plattform müssen die Geschäftsanforderungen verstehen und arbeiten, um eine sichere Lieferung der schnellsten und wirtschaftlichsten Option zu machen. Dies vermeidet den Konflikt zwischen der Erfüllung von Geschäftszielen und der Einhaltung von Sicherheitskontrollen, da beide in derselben Infrastruktur ausgerichtet sind.

Der kulturelle Wandel ist auch relevant: Stoppen Sie Entwickler für Shortcuts und Start-Designing-Systeme, die Shortcuts verhindern. Modelle wie DevSecOps bleiben gültig, aber ihre Umsetzung muss auf Vereinfachung und effektive Automatisierung ausgerichtet werden. Ressourcen von Agenturen wie OWASP oder NIST bieten Anleitungen und Frameworks, um Risiken in der Software-Versorgungskette zu verstehen und zu mindern; siehe zum Beispiel das OWASP SAMM-Projekt und NIST-Publikationen zur Supply Chain Security: OWASP SAMM und NIST - Software Supply Chain Security.

Die Schlussfolgerung ist klar: Wenn wir weiterhin Verantwortung über die Schultern bereits überlasteten Entwicklern tragen, werden wir Ausweichungen und Aussetzung erhalten. Stattdessen benötigen wir Plattformen, die die Option sicher auch die einfache Option machen. Die Sicherheit muss im Stapel "abfahren", in die Infrastruktur integriert und automatisiert werden, so dass das Geschäft Geschwindigkeit bekommt, ohne Kontrolle oder Schutz zu opfern. Für diejenigen, die in bestimmten Analysen und Empfehlungen vertiefen wollen, ist die Qualys-Studie ein guter Ausgangspunkt und ist auf ihrem technischen Blog verfügbar Hier. und wenn Lösungen für Cloud-native Umgebungen ausgewertet werden, ist Forresters Bericht über CNAPP eine weitere nützliche Referenz verfügbar über Qualys.