Security vs. Entwicklung: ein Spiel der Prioritäten

Im dynamischen Tech-Ökosystem von heute ist es entscheidend, AppSec-Programme in großem Maßstab zu verwalten. Mit wachsenden Codebasen und immer ausgefeilteren Bedrohungen verlagert sich der Fokus: Statt einzelne Schwachstellen zu beheben, geht es zunehmend darum, in allen Entwicklungsteams eine einheitliche Sicherheitsstrategie zu etablieren. Neue Ansätze wie Application Security Posture Management (ASPM) ermöglichen Unternehmen, über einzelne Schwachstellen hinauszugehen und umfassende Programme zu koordinieren, die stattdessen das Management kritischer Geschäftsrisiken in den Mittelpunkt stellen. Diese Tools vereinfachen den Prozess durch die Automatisierung von Security-Kontrollen, eine verbesserte Risikoanalyse und die Priorisierung von Schwachstellen.

ASPM mag für manche wie ein neuer Ansatz wirken. Bei Snyk bewegen wir uns jedoch schon seit acht Jahren in diese Richtung. Von Anfang an war Snyk ein Vorreiter bei AppSec-Tools mit Developer-first-Ansatz. Unser Ziel war es stets, AppSec-Programme über das bloße „Shift Left“ mit herkömmlichen AppSec-Tools hinauszuführen und Teams zu vermitteln, dass Unternehmen Entwicklern mehr Verantwortung für Security übertragen müssen, damit AppSec wirklich wirksam ist. Dafür brauchte es eine völlig neue Kategorie von Security-Tools, die speziell für Entwickler entwickelt wurden.

Auch wenn Entwickler mehr Verantwortung für Security übernehmen, bleibt das Security-Team für die Sicherheitslage der Anwendungen im Unternehmen verantwortlich. Die Tools in die Entwicklungsumgebung zu integrieren, ist nur ein Teil unserer Arbeit bei Snyk. Noch wichtiger ist es, Security- und Entwicklungsteams dabei zu unterstützen, gemeinsam einen stärker präventionsorientierten Ansatz für Security zu verfolgen. Dazu gehören natürlich der Einsatz der Snyk-Tools, aber auch Schulungen und Security-Champion-Programme, die Definition und Messung von AppSec-Erfolgskennzahlen sowie die Übertragung von Erfolgen vom ersten Anwendungsteam auf alle Anwendungen und Teams. ASPM ist ein Beleg für unser Engagement und dafür, wie wir unsere über viele Jahre gesammelte Expertise in ein Produkt überführen – und setzt damit Maßstäbe in der Anwendungssicherheit.

Um das volle Potenzial dieser Tools auszuschöpfen, müssen die Entwicklungs- und Security-Teams strategisch aufeinander abgestimmt sein. Das ist oft eine Herausforderung, da es so wirken kann, als bewegten sich Security und Entwicklung in getrennten Welten. Angesichts der Vorteile von ASPM ist es umso wichtiger, die individuellen Beweggründe der einzelnen Teams zu verstehen.

Die individuellen Beweggründe der einzelnen Teams zu verstehen, ist entscheidend, um Entwickler umfassend für Security-Tools wie Snyk zu gewinnen.

Anforderungen der Teams

Wo Anforderungen aufeinanderprallen

• Fokus: Kritische Security-Patches vs. wichtige neue Funktionen.

• Tempo: Die Vorsicht des Security-Teams vs. der Sprint der Entwicklung.

• Einführung von Tools: Entwickler sind möglicherweise so begeistert von neuen Tools, dass sie die Security-Prüfung überspringen.

• Kommunikation: Die Teams sprechen manchmal unterschiedliche „Sprachen“ – was für die einen Dokumentation ist, kann für die anderen unverständlich sein.

• Schulungen: Für Entwickler können Security-Schulungen wie ein Umweg wirken.

Bestandsaufnahme: Unstimmigkeiten erkennen

Um mögliche Probleme bei der Einführung von Security-Tools durch Entwickler zu lösen, sollten Sie zunächst bestehende Unstimmigkeiten erkennen:

Fragen für Führungskräfte im Security-Bereich

• Strategie: Wie beziehen wir Entwickler in unsere Security-Vision ein?

• Tools: Wie unterstützen wir Entwickler dabei, Security zu integrieren?

• Lernen: Wie sieht unser Security-Schulungsplan für Entwickler aus?

• Feedback-Schleife: Wie funktioniert die Kommunikation zwischen Entwicklung und Security?

Fragen für Führungskräfte im Engineering-Bereich

• Perspektive der Entwickler: Wie sehen Entwickler ihre Rolle im Bereich Security?

• Herausforderungen: Welche Hürden begegnen ihnen bei Security-Tools für Entwickler?

• Zusammenspiel von Security und Entwicklung: Wie würden Sie die aktuelle Beziehung zwischen Security und Entwicklung beschreiben?

• Aus Fehlern lernen: Wie fließen die Erkenntnisse aus Security-Vorfällen in die Arbeit ein?

• Sprint-Planung: Welchen Anteil unserer Sprints widmen wir Security?

Synergien schaffen: Mehr Entwickler für Security-Tools gewinnen

Wenn Sie die Ursachen für die fehlende Abstimmung gefunden haben, geht es darum, eine Brücke zu bauen:

Dialog

• Security-Leitung: Informieren Sie Entwickler regelmäßig über Security-Neuigkeiten und nehmen Sie ihr Feedback offen auf.  

  • Wichtige Updates priorisieren: Regelmäßiger Austausch ist entscheidend. Unterscheiden Sie aber auch zwischen kritischen Security-Benachrichtigungen und weniger wichtigen Hinweisen, damit Entwickler nicht überfordert werden.

  • Regelmäßige Treffen: Organisieren Sie monatliche oder vierteljährliche Treffen mit Entwicklern, um Erkenntnisse zur Security zu besprechen und Trends statt Einzelfälle in den Mittelpunkt zu stellen.

• Engineering-Leitung: Fördern Sie die aktive Teilnahme der Entwickler an diesen Gesprächen. Benennen Sie eine Ansprechperson, die direkt mit dem Anbieter der Security-Tools zusammenarbeiten kann.

Nahtlose Integration

• Security-Leitung: Security-Prüfungen im SCM und/oder CI/CD sind ein guter Anfang. Stellen Sie sicher, dass die Security-Daten sichtbar und umsetzbar sind. Lassen Sie PR-Security-Prüfungen oder Builds zunächst nicht fehlschlagen. So schaffen Sie durch Schulungen statt Kontrolle Vertrauen bei den Entwicklern.

• Engineering-Leitung: Vermitteln Sie Entwicklern das nötige Wissen über Security-Tools. Stimmen Sie sich zu Schwachstellenmeldungen, Triage und Richtlinien ab.

Kontinuierliches Lernen

• Security-Leitung: Nutzen Sie Security-Tools für Entwickler, um gezielte Security-Workshops anzubieten.

• Engineering-Leitung: Ermutigen Sie Entwickler zur Teilnahme, wenn die Workshop-Themen direkt für ihre Arbeit relevant sind.  Geben Sie dem Security-Team regelmäßig Feedback zu den Sessions, damit sie für Entwickler interessant und relevant bleiben.

Einheitliche Kennzahlen

• Security-Leitung:  Führen Sie KPIs für Schwachstellen ein. Teilen Sie die Ergebnisse, würdigen Sie Erfolge und bleiben Sie offen für Feedback von Entwicklern.

• Engineering-Leitung: Investieren Sie einen Teil des Budgets für technische Schulden in Security, indem Sie einen bestimmten Anteil der Sprints für die Behebung bestehender Probleme einplanen. Nehmen Sie Security-Ziele in die Sprint-Planung auf, insbesondere bei der Einführung neuer Funktionen.  Ermutigen Sie Entwickler, kontinuierlich Feedback zu Security-Hinweisen zu geben – und kritische Probleme von bloßem Hintergrundrauschen zu unterscheiden.

Prioritäten setzen und sicher bleiben

Zusammenfassend lässt sich sagen: Um AppSec-Programme in großem Maßstab zu optimieren, müssen wir den Fokus von der Behebung einzelner Schwachstellen auf integrierte Security-Strategien für alle Entwicklungsinitiativen verlagern. Dabei ist es entscheidend, die unterschiedlichen Beweggründe von Entwicklern und Security-Teams zu verstehen.

Plattformen wie Snyk können die Zusammenarbeit zwischen Security- und Entwicklungsteams fördern – durch mehr Transparenz, Security-Kontrollen, detaillierte Risikoanalysen und eine strategische Priorisierung. Dieser gemeinsame Ansatz ist die Zukunft: Security erkennt nicht nur Bedrohungen, sondern entwickelt gemeinsam mit Entwicklern proaktive Schutzmaßnahmen. So entsteht ein einheitliches, agiles und sicheres Tech-Ökosystem.