Entwicklerinnen und Entwickler bringen etwas mit, das in Sicherheitsabteilungen selten ist: Sie können Quelltext lesen, sie kennen die Strecke, auf der Software entsteht, und sie wissen, warum ein Befund im Prüfbericht in der Praxis nicht in zwei Tagen behoben wird. Das ist ein guter Ausgangspunkt – aber der Weg ist ein anderer als bei Administratoren, und die Stellen heißen anders.
Wohin dieser Weg führt
Die naheliegende Richtung ist die Anwendungssicherheit. Sie taucht in Stellentiteln seltener auf als andere Rollen und steckt häufig als Aufgabenteil in Stellen mit anderen Namen: Security Engineer, Product Security, Plattform- oder DevOps-Stellen mit Sicherheitsanteil, gelegentlich Beratung. Die Aufgaben sind in den meisten Häusern ähnlich:
- Prüfwerkzeuge in die Entwicklungsstrecke einbauen: statische Analyse, Abhängigkeitsprüfung, Prüfung laufender Anwendungen, Erkennung von Zugangsdaten im Quelltext – und, wichtiger als der Einbau, die Arbeit an den Befunden, damit die Entwicklungsteams sie nicht abschalten.
- Bedrohungsmodellierung: mit einem Team durchgehen, was schiefgehen kann, bevor es gebaut wird. Das ist die Tätigkeit mit dem größten Wirkungsgrad und die, die am seltensten jemand beherrscht.
- Sicherheit der Lieferkette: Herkunft von Abhängigkeiten, Stücklisten für Software, Signaturen, Umgang mit veralteten Bibliotheken.
- Umgang mit Geheimnissen: Schlüssel, Zugangsdaten, Zertifikate – Ablage, Rotation, Verwendung in der Strecke.
- Vorgaben und Beratung: Anforderungen formulieren, die umsetzbar sind, und Freigaben begleiten.
Daneben gibt es einen zweiten Weg: in die Prüfung von Webanwendungen. Wer Anwendungen gebaut hat, versteht ihre Schwächen schneller als jemand, der nur Werkzeuge bedient. Die Marktlage für Teststellen ist allerdings eng – siehe Ethical Hacker als Suchwort.
Was unmittelbar zählt
In Bewerbungen sollten Sie diese Punkte ausdrücklich benennen, weil sie den Unterschied zu anderen Bewerbern ausmachen:
Sie können einen Befund beurteilen. Ein Prüfbericht enthält Befunde, die im konkreten Zusammenhang harmlos sind, und solche, die schwerer wiegen als ihre Einstufung. Wer den Code kennt, kann das trennen – und genau daran scheitern Sicherheitsabteilungen, die Berichte nur weiterreichen.
Sie kennen die Strecke. Wer weiß, wie Auslieferung, Testumgebungen, Freigaben und Abhängigkeiten zusammenspielen, kann eine Prüfung dort einbauen, wo sie stört und wirkt – statt sie an das Ende zu hängen, wo sie ignoriert wird.
Sie sprechen die Sprache der Entwicklungsteams. Sicherheitsanforderungen scheitern selten an der Technik und häufig an der Art, wie sie vorgetragen werden. Ein Wechsler aus der Entwicklung hat hier einen Startvorteil, den kein Zertifikat ersetzt.
Sie können automatisieren. In Sicherheitsabteilungen wird viel von Hand gemacht, was ein Skript erledigen könnte. Das ist in fast jeder Stelle ein sofort sichtbarer Beitrag.
Die Lücken
Betrieb und Netz. Die größte Lücke. Verzeichnisdienste, Anmeldeverfahren, Segmentierung, Endgeräte – davon weiß ein Entwickler oft wenig, und in Gesprächen wird danach gefragt. Nacharbeiten lässt sich das im Labor; siehe Heimlabor als Nachweis und, als Übersicht der Betriebsthemen, Quereinstieg aus der Administration.
Das Regelwerk. Normen, Nachweise, Audits, Risikobewertung. In Anwendungssicherheit kommt das über Vorgaben, Freigaben und Lieferkettenanforderungen zurück – siehe ISO 27001 und NIS2.
Die Rolle des Prüfers. Sie beurteilen künftig die Arbeit anderer Teams. Das erfordert eine andere Gesprächsführung als die Arbeit im eigenen Team, und es erfordert, eine Feststellung stehenzulassen, auch wenn sie unbequem ist.
Angriffsdenken jenseits der eigenen Anwendung. Entwickler denken in Fehlern des eigenen Codes. Angriffe nutzen die Umgebung: Konfigurationen, Rechte, Nachbarsysteme, Menschen.
Was Sie in zwölf Monaten tun können
Wieder gilt: Der kürzeste Weg führt durch die eigene Stelle. Vier Vorhaben, die sich in fast jedem Entwicklungsteam umsetzen lassen und die in Bewerbungen tragen:
- Eine Prüfstrecke einführen, mit einer ehrlichen Auswertung: Wie viele Befunde, wie viele davon berechtigt, wie viele behoben, wie lange hat es gedauert.
- Eine Bedrohungsmodellierung durchführen – für ein einziges Vorhaben, mit Protokoll und daraus abgeleiteten Anforderungen.
- Die Abhängigkeiten in Ordnung bringen: Bestandsaufnahme, Stückliste, Verfahren für Aktualisierungen, Umgang mit Bibliotheken ohne Pflege.
- Geheimnisse aus dem Quelltext holen und ein Verfahren für ihre Verwaltung einführen.
Jedes dieser Vorhaben ist eine Zeile im Lebenslauf, über die Sie zwanzig Minuten sprechen können, und alle vier stehen in Anzeigen der Anwendungssicherheit. Wie das aufgeschrieben wird, steht unter Lebenslauf.
Nachweise, die in dieser Richtung zählen
Zertifikate spielen hier eine kleinere Rolle als in anderen Richtungen. Was zählt, ist prüfbare Arbeit: ein öffentliches Repository mit Werkzeugen oder Beiträgen, ein anonymisierter Prüfbericht, Wettbewerbsteilnahmen mit Schwerpunkt auf Webanwendungen – siehe CTF und Bug Bounty.
Wenn es ein Zertifikat sein soll: In der offensiven Richtung ist eine praktische Prüfung die einzige mit Aussagekraft, siehe OSCP. Für spätere Stabs- oder Leitungsstellen kommen die breiten Managementzertifikate in Betracht, siehe Zertifikate im Vergleich. Herstellerabschlüsse zu Cloud-Plattformen sind nützlich, wenn Ihre Zielhäuser dort betreiben.
Wie Sie den Wechsel begründen
Ein Punkt, der in Bewerbungen dieser Richtung regelmäßig misslingt: die Begründung. „Ich interessiere mich schon lange für Sicherheit" ist keine, weil sie für jeden Bewerber gilt. Brauchbar sind zwei Formen.
Die erste ist die Fortsetzung: Sie haben in Ihrem Team bereits die Sicherheitsfragen bearbeitet – Prüfwerkzeuge, Abhängigkeiten, Freigaben – und wollen daraus die Hauptaufgabe machen. Das ist die stärkste Begründung, weil sie belegbar ist.
Die zweite ist die Wirkung: Sie haben erlebt, dass Befunde spät kommen und dann teuer werden, und wollen an der Stelle arbeiten, an der das entschieden wird. Auch diese Begründung trägt, wenn Sie ein konkretes Beispiel anschließen können.
Nicht tragfähig ist dagegen die Abkehr: wer erzählt, er habe vom Programmieren genug, bewirbt sich hörbar weg von etwas und nicht hin zu etwas. In der Anwendungssicherheit ist das besonders unpassend, weil die Stelle technische Nähe zur Entwicklung verlangt.
Das Gespräch
Rechnen Sie mit Fragen, die auf Ihr Urteilsvermögen zielen: Wie gehen Sie mit einem Befund um, den das Team für unbegründet hält? Was tun Sie, wenn eine Bibliothek eine kritische Schwachstelle hat, das Aktualisieren aber die Anwendung zerlegt? Wie bekommen Sie ein Team dazu, eine Prüfung nicht zu umgehen? Wie modellieren Sie Bedrohungen für ein Vorhaben, das in zwei Wochen ausgeliefert wird?
Gute Antworten enthalten Verhandlung und Priorisierung, nicht nur Technik. Wer sagt, er würde die Auslieferung stoppen, bis alles behoben ist, beschreibt eine Rolle, die es in keinem Unternehmen gibt. Welche Fragen Sie selbst stellen sollten, steht unter Vorstellungsgespräch.
DevSecOps als Stellentitel
Neben der Anwendungssicherheit gibt es einen Titel, der genau auf diesen Quereinstieg zugeschnitten ist und in Anzeigen zunimmt: die Verbindung von Entwicklung, Betrieb und Sicherheit.
Was dahintersteckt, ist in den meisten Häusern konkret: Sie verantworten die Sicherheit der Auslieferungsstrecke. Also Prüfwerkzeuge in der Strecke, signierte Bauergebnisse, Verwaltung von Geheimnissen, Berechtigungen in der Strecke selbst, Absicherung der Laufzeitumgebung, Prüfung der Infrastrukturbeschreibungen, und die Frage, wer eine Auslieferung freigeben darf.
Zwei Hinweise zur Bewertung solcher Anzeigen. Erstens: Prüfen Sie, ob die Stelle Betriebsverantwortung enthält. „DevSecOps" bezeichnet in einem Haus eine Beratungsrolle mit Werkzeugauswahl und im nächsten eine Betriebsstelle mit Bereitschaft – siehe Stellenanzeige entschlüsseln. Zweitens: Fragen Sie, wer die Befunde abarbeitet. Eine Rolle, die Werkzeuge einführt, ohne dass jemand für die Behebung zuständig ist, erzeugt Berichte und keine Sicherheit.
Für die Bewerbung ist diese Richtung günstig, weil Ihre Herkunft der Einstellungsgrund ist: Sie haben in der Strecke gearbeitet, die Sie künftig absichern. Die Rolle selbst ist unter DevSecOps Engineer beschrieben, das Umfeld unter Entwicklung und Architektur.
Der nüchterne Teil
Zwei Punkte. Erstens: Wer aus der Entwicklung kommt, schreibt in einer Sicherheitsstelle weniger Code. Ein Teil der Arbeit ist Beratung, Abstimmung und Dokumentation. Wer das Programmieren vermisst, sollte eine Stelle suchen, in der Werkzeugbau und Automatisierung ausdrücklich zur Aufgabe gehören.
Zweitens: Die Entgeltfrage ist offen. In manchen Häusern zahlt die Entwicklung besser als die Sicherheit, in anderen umgekehrt. Prüfen Sie das vor dem Wechsel und verhandeln Sie beim Einstieg – siehe Gehalt verhandeln. Wo gerade Stellen frei sind, zeigen die offenen Stellenangebote und gezielt die Stellen im Bereich Application Security.
Wenden Sie das direkt an: Im Stellenmarkt stehen Anzeigen aus ganz Deutschland, und zu jedem Beruf finden Sie die Aufgaben und die üblichen Gehälter daneben.