Security nach links zu verlagern bedeutet Kultur, nicht nur Tools

Dies ist der zweite Teil einer vierteiligen Reihe zum Aufbau Ihrer Kubernetes-AppSec-Strategie. Den ersten Teil finden Sie hier.

Während Unternehmen DevOps-Praktiken einführen und die Entwicklung und Wartung von Anwendungen verändern, wandeln sich viele Aspekte der Anwendungsentwicklung.

Die traditionelle Systemadministration hat sich in vielen Unternehmen verändert: Sie setzen zunehmend auf Site Reliability Engineering und die Philosophie „You build it, you run it“. Netzwerke werden immer häufiger in Software beschrieben, insbesondere mit dem Aufkommen von Service-Meshes. Bei Monitoring verlagert sich der Fokus von der Lösung bekannter Unbekannter auf Observability und unbekannte Unbekannte. Das Muster ist klar: Immer mehr Aspekte des Anwendungsbetriebs werden in die Verantwortung von Entwicklerinnen und Entwicklern übertragen. Was Security betrifft, steht diese Verlagerung noch ganz am Anfang. Damit Security diesen Wandel erfolgreich mitvollziehen kann, müssen wir die Tools sorgfältig auswählen und die Kultur bewusst weiterentwickeln.

Container als Softwareeinheit

Betrachten wir Container, um die Themen Tooling und Kultur zu untersuchen. Wie im vorherigen Beitrag erwähnt, entwickeln sich Container zunehmend zur Standard-Softwareeinheit. Wir erstellen Images, tauschen uns teamübergreifend darüber aus, formulieren Anforderungen an sie und nutzen sie allgemein, um uns von plattform- oder sprachspezifischen Paketformaten zu abstrahieren.

Die Idee eines einheitlichen Paketformats, eines Paket-Repositorys und eines Mechanismus zur Installation dieser Pakete in der Produktionsumgebung ist nicht neu. RPM-Pakete und -Repositorys sowie Tools wie Yum entsprechen beispielsweise durchaus diesem Modell. Bei Containern gibt es jedoch zwei wichtige Unterschiede, die eher organisatorischer als technischer Natur sind:

1. Die Verwaltung von Betriebssystempaketen wurde häufig von einem separaten Team innerhalb der übergeordneten Betriebsorganisation übernommen.

2. Nur wenige Unternehmen verwenden ausschließlich ein Paketformat. Jedes Betriebssystem und jede Programmiersprache hat eine eigene Toolchain für die Paketverwaltung.

Neu bei Container-Images ist, dass die Verantwortung für das Packaging fast immer auf Entwicklerinnen und Entwickler sowie Entwicklungsteams übergeht. Deshalb finden Sie beispielsweise mehr als 2 Millionen Dockerfiles öffentlich auf GitHub. Test- und Security-Tools, die für eine frühere Generation von Paketformaten und frühere Organisationsstrukturen entwickelt wurden, passen nicht gut in moderne Developer-Workflows und Toolchains. So verlagert sich beispielsweise das Patchen zunehmend davon, direkte Änderungen in der Produktionsumgebung vorzunehmen, hin zum Neuerstellen und erneuten Bereitstellen unveränderlicher Artefakte.

Interessieren Sie sich für das Management von Container-Schwachstellen? Erfahren Sie mehr darüber, wie Snyk Sie dabei unterstützen kann, Ihre Container zu schützen.

Developer-zentriertes Tooling

Die Standardisierung von Images bietet zahlreiche Möglichkeiten, wirklich Developer-zentrierte Tools zu entwickeln, die den Wandel unterstützen, den wir beobachten. Welche Eigenschaften zeichnen diese neue Tool-Generation aus?

• Lokal nutzbar – die meisten Entwicklerinnen und Entwickler schreiben und lesen Code auf ihren lokalen Rechnern. Lokal nutzbare Tools helfen ihnen, sich in ein neues Themengebiet einzuarbeiten.

• In IDEs integriert – Entwicklerinnen und Entwickler, die integrierte Entwicklungsumgebungen verwenden, sollten Tools nutzen, die integriert sind.

• Direkte Interaktion mit Versionskontrollsystemen – Versionskontrollsysteme, zunehmend auf Git basierend, prägen den Arbeitsalltag von Entwicklerinnen und Entwicklern. Developer-Tools müssen Teil des Teams werden, insbesondere da immer mehr Entwicklerinnen und Entwickler Ansätze wie GitOps übernehmen.

• In CI/CD-Pipelines konfigurierbar – Continuous Integration ist eine Voraussetzung für eine effiziente Softwarebereitstellung und der ideale Ort, um Qualitätskontrollen einzubinden, solange die Feedback-Schleife für Entwicklerinnen und Entwickler noch kurz ist.

Ein Vorteil von Tools, die den gesamten Softwareentwicklungszyklus (SDLC) abdecken: Sie helfen Entwicklerinnen und Entwicklern, die Anwendung besser zu verstehen und das gefürchtete „Funktioniert auf meinem Rechner“ zu vermeiden.

Eine DevOps-Kultur des Teilens

Qualität und Security liegen nicht allein in der Verantwortung von Entwicklerinnen und Entwicklern. Erfahrene Operations-Fachleute und Security-Expertinnen und -Experten sind weiterhin entscheidend für den Erfolg. Sie werden gebraucht, um Teams zu begleiten und weiterzubilden, wenn es darum geht, Security nach links zu verlagern und Verantwortlichkeiten zunehmend an Entwicklungsteams zu übertragen. So wie Site-Reliability-Engineering-Teams Entwicklerinnen und Entwickler dabei unterstützen, ihre Anwendungen besser zu betreiben, muss Security dieselbe Haltung einnehmen.

Tools, die den Austausch zwischen verschiedenen Fachbereichen und oft auch über Organisationsgrenzen hinweg erleichtern, sind nicht nur wünschenswert, sondern unverzichtbar. Die Alternativen – getrennte Funktionen mit jeweils konkurrierenden Tools oder eine Gruppe mit einer zweitklassigen Nutzererfahrung – reichen nicht aus. Wenn Operations-Teams mit einem Toolset und Entwicklerinnen und Entwickler mit einem anderen arbeiten, entstehen organisatorische Silos. Das bedeutet selten, dass ein einziges Tool alles beherrschen muss. Modernes Developer-Tooling konzentriert sich auf Anwendungen und darauf, Feedback in den Entwicklungsprozess einfließen zu lassen. Es sollte sich gut in Operations-Tooling integrieren lassen, das detaillierte Untersuchungen und langfristige Berichte ermöglicht, und mit den Abstraktionen der verschiedenen Rollen arbeiten.

Fazit

In Gesprächen über das „Verlagern nach links“ geht es häufig darum, Verantwortlichkeiten von klassischen IT-Funktionen auf Entwicklungsteams zu übertragen, um die Feedback-Schleife zu verkürzen. Doch die Arbeitsweise grundlegend zu verändern, ohne zugleich auch die Tools anzupassen, funktioniert selten. Die Entwicklung komplexer Software ist selbst ein komplexes soziotechnisches System. Wenn Entwicklerinnen und Entwickler stärker in die Verantwortung für Security-Herausforderungen eingebunden werden, müssen wir auch berücksichtigen, dass sie andere Tools benötigen als die bisherige Generation von Tools, die auf Operations-Teams ausgerichtet war.