Jedes Team ist sich einig, dass sichere Entwicklung wichtig ist. Aber wenn es um die Verantwortlichkeit geht? Plötzlich schaut jeder auf jemand anderen. Entwickelnde denken, es sei die Aufgabe der Security. Security-Teams erwarten von Entwickelnden, dass sie sichereren Code schreiben. DevOps will nur die Pipeline am Laufen halten. Und Manager? Sie wollen Sicherheit, ohne die Auslieferung zu verlangsamen.

Die Wahrheit ist, sichere Softwareentwicklung ist nicht die Aufgabe einer einzelnen Person – sie ist die Aufgabe aller. Das bedeutet, Rollen, Verantwortlichkeiten und vor allem Erwartungen klar zu definieren. Wenn dieser Teil nicht richtig gemacht wird, wird die gesamte SSDLC-Anstrengung zu einem langsamen Schuldzuweisungsspiel. Lassen Sie uns aufschlüsseln, wer in der Arena ist, was sie nachts wach hält und wonach sie wirklich um 2 Uhr morgens suchen.

Platzhalterbild: Bildbeschreibung: Diagramm der Rollen eines funktionsübergreifenden Entwicklerteams mit Pfeilen, die Verantwortlichkeiten für sichere Codierung, Tests, Tooling und Bereitstellung abbilden.

Die Aufstellung: Wer ist wer in der Arena der sicheren Entwicklung

Entwickelnde: Im Graben, Code schreibend, CVEs umgehend

Entwickelnde sind dem Code am nächsten und oft die Ersten, die die Schuld bekommen, wenn etwas schiefgeht. Von ihnen wird erwartet, dass sie sicheren Code schreiben, auch wenn ihnen nie beigebracht wurde, wie. Sie leiden unter Alert Fatigue durch überladene Tools und widersprüchliche Ratschläge. Was sie brauchen: Sicherheitsrichtlinien, die in ihren Workflow integriert sind, nicht nachträglich angefügt werden.

DevOps Engineers: Meister der Pipeline, jonglieren mit Tools und Cloud-Konfigurationen

DevOps hält die Pipeline am Laufen und die Deployments fließend. Sie verwalten Secrets, Infrastructure-as-Code, Container-Konfigurationen und CI/CD-Integration. Oft wird von ihnen erwartet, dass sie „einfach Sicherheit zum Laufen bringen“ über den gesamten Stack hinweg – ohne den Build zu unterbrechen. Was sie brauchen: Sicherheit, die in die bestehende Automatisierung passt, nicht mehr manuelle Schritte.

Security Engineers (AppSec/Product Security): Die Wegweiser, Wächter und manchmal Engpässe

Sicherheitsteams erstellen Richtlinien, wählen Tools aus und versuchen, ihren Einfluss auf Dutzende (oder Hunderte) von Entwickelnden auszudehnen. Doch sie sind oft im Verhältnis 100 zu 1 in der Unterzahl. Sie benötigen Tools, die Rauschen reduzieren, hervorheben, was wirklich wichtig ist, und Entwickelnden helfen, Probleme ohne langwieriges Ticket-Pingpong zu beheben.

Technische Manager: Katzen hüten, Funktionen und Vernunft in Einklang bringen

Manager bewegen sich auf dem schmalen Grat zwischen Velocity und Risiko. Sie werden an ausgelieferten Features gemessen – aber auch an Ausfallzeiten, Incidents und Compliance. Sie sind keine Sicherheitsexperten, aber es wird von ihnen erwartet, Entscheidungen zu treffen, die das Unternehmen vor Problemen bewahren. Sie benötigen Transparenz, Metriken und teamübergreifendes Buy-in.

Was ihnen schlaflose Nächte bereitet

Für Entwickelnde: „Sicherheit vs. Geschwindigkeit“, Tool-Hölle (So. Viele. Alerts.), „Das-ist-nicht-mein-Job“-Syndrom

Entwickelnde fürchten Tools, die Deployments blockieren und sie mit Problemen niedriger Priorität überfluten. Sie wünschen sich schnelles, umsetzbares Feedback – vorzugsweise in ihrer IDE oder in PRs. Sie hassen alles, was sich wie Schuldzuweisung ohne Unterstützung anfühlt.

Für DevOps: Pipeline-Engpässe, Konfigurationsalpträume, Secrets geheim halten

DevOps wünscht sich weniger manuelle Schritte und weniger Überraschungen. Sie machen sich Sorgen, versehentlich sensible Daten zu veröffentlichen oder einen S3-Bucket für die Welt zu öffnen. Sie benötigen klare Richtlinien und Tools, die die Automatisierung nicht behindern.

Für Sicherheitsexperten: Zu viel Rauschen, zu wenige Ressourcen, immer im Rückstand

Sicherheitsteams werden von Alerts, False Positives und Tool-Sprawl überwältigt. Sie sind es leid, reaktiv zu sein. Was sie sich wünschen, ist Kontext, Priorisierung und Wege, Risiken proaktiv anzugehen – ohne jedes Deployment zu überwachen.

Für Manager: Kosten rechtfertigen, Risiken managen, Menschen finden, die das verstehen

Manager machen sich Sorgen um den ROI. Ist dieses Sicherheitstool sein Geld wert? Nutzt das Team es überhaupt? Sie stecken auch fest bei dem Versuch, „Unicorn“-Ingenieure einzustellen, die sowohl Code als auch Sicherheit verstehen. Sie wollen praktische Erfolge, nicht ein weiteres Dashboard, das sie verwalten müssen.

Was sie tatsächlich googeln (und was dieser Hub beantworten wird)

Anfragen von Entwickelnden

• „Sicheres Codieren [meine Sprache]“
• „Wie man SQL-Injection schnell stoppt“
• "OWASP Top 10 für Menschen erklärt"

Entwickelnde wünschen sich klare, praktische Antworten. Sie suchen keine 80-seitigen PDFs – sie wollen kopierbare Lösungen und sprachspezifische Ratschläge für sicheres Codieren.

DevOps-Anfragen

• "Sicherheit in CI/CD automatisieren, ohne alles zu beeinträchtigen" 
• „Tools für Terraform-Sicherheits-Scans“ 
• "Docker-Sicherheits-Best Practices, die nicht von 2015 stammen"

DevOps sucht nach Wegen, Sicherheit in die bereits verwendeten Tools zu integrieren – ohne Deployments zu unterbrechen oder Builds zu verlangsamen.

Sicherheitsabfragen:

• „SSDLC-Implementierungsleitfaden für agile Entwicklung“
• „Threat Modeling, das Entwickelnde nicht hassen werden“
• "SAST Tool-Vergleich"

Security Engineers wollen skalieren. Sie suchen nach Tools und Playbooks, die sich in agile Prozesse integrieren lassen und tatsächlich dabei helfen, Shift Left umzusetzen – ohne ständiges „Babysitting“.

Manager-Anfragen: 

• "Kosten eines Data Breach vs. Sicherheitsinvestition"
• "ROI der Sicherheitsschulung für Entwickelnde"
• „Wie man eine Sicherheitskultur aufbaut, die keine Vertrauensübungen erfordert“

Manager suchen nach konkreten Zahlen, begründbaren Investitionen und einfachen Wegen, um eine sichere Entwicklung voranzutreiben – ohne die Team-Velocity oder die Moral zu beeinträchtigen.

Jeder möchte sichere Software. Niemand möchte mehr Arbeit. Der Schlüssel liegt darin, die Schwachstellen jeder Rolle zu verstehen und ihnen Tools und Prozesse zur Verfügung zu stellen, die mit ihrem Workflow arbeiten – nicht dagegen. 

Es ist an der Zeit zu ergründen, was Teams tatsächlich motiviert, sichere Praktiken einzuführen – und was dabei meist im Wege steht.