Stellungnahme zum ESF-Leitfaden für Entwickler

Bei Snyk haben wir Security mit Fokus auf Entwickler erfunden. Wir sind überzeugt, dass die Einbindung von Entwicklern in Sicherheitspraktiken entscheidend ist, um moderne Anwendungen zu entwickeln und zu betreiben. Genau deshalb hat die jüngste Veröffentlichung Recommended Practices Guide for Developers der National Security Agency (NSA), der Cybersecurity and Infrastructure Security Agency (CISA) und des Office of the Director of National Intelligence (ODNI) unser Interesse geweckt. Wir haben uns gefreut, dass die Regierung ein solches Dokument veröffentlicht hat, und fanden die Informationen gut. Als praktischer Leitfaden für Entwickler verfehlte es jedoch unserer Ansicht nach sein Ziel – insbesondere angesichts dieses Zitats aus der Pressemitteilung: „Entwickler tragen eine entscheidende Verantwortung für die Sicherheit unserer Software.“

Der Practice Guide behandelt die richtigen Themen rund um die Software-Supply-Chain-Security. Er ist breit angelegt und deckt die Notwendigkeit eines sicheren Designs, umfassender Sicherheitstests während des gesamten Softwareentwicklungszyklus, neuer Tools zur Erstellung von Software-Stücklisten (SBOMs), neu auftretender Bedrohungen für Build- und Entwicklungsumgebungen und mehr ab. Das Dokument enthält einige gute Ratschläge.

Der Leitfaden weist jedoch einige Schwächen auf, die es zu beachten gilt – insbesondere bei der Präsentation. Weltweit gibt es heute rund 27 Millionen Entwickler. Dabei ist es wichtig, die unterschiedlichen Programmiersprachen, Tool-Präferenzen und Umgebungen zu berücksichtigen, in denen Entwickler Code schreiben. Es gibt nicht nur einen Entwicklertyp, sondern viele. Meiner Erfahrung nach werden die meisten Entwickler kaum einen 64-seitigen PDF-Leitfaden lesen, dessen 24-seitiger Anhang zwei volle Seiten mit Akronymen enthält. Und für viele Entwickler außerhalb der Regierung – und für einige innerhalb – signalisiert der übermäßige Gebrauch des Wortes „Cyber“ oft, dass sich der Inhalt nicht an sie richtet.

Vergleichen Sie das mit Dokumenten, die die Entwickler-Community insgesamt beeinflusst haben: Twelve-Factor App (die moderne Architekturen festgeschrieben und anschließend geprägt hat), die 4 Werte und 12 Prinzipien der agilen Softwareentwicklung sowie die OWASP Top Ten. Vielleicht neuer sind die vier Stufen des SLSA Supply chain Levels for Software Artifacts framework.

Hier sind einige Vorschläge, wie sich künftige Leitfäden dieser Art verbessern lassen, wenn sie sich an Entwickler richten.

1. Holen Sie Entwickler dort ab, wo sie sind. Entwickler sind von Natur aus neugierig, versiert und effizient. Die meisten Entwickler lesen Dokumentation am liebsten in webfreundlichen Formaten, damit sie die Inhalte in ihre bevorzugten Lesetools übernehmen können. PDFs sind praktisch, aber starr und schwieriger zu verwenden.

2. Kommunizieren Sie auf eine entwicklerfreundliche Weise. Für Sicherheitsexperten, die mit Entwicklern zusammenarbeiten, liegt die Herausforderung oft nicht im Wissen, sondern in der Kommunikation. Kommunikationsprobleme – und oft auch nicht abgestimmte Anreize – führen zu einer „Wir gegen sie“-Mentalität, die DevSecOps vermeiden soll. Wie bereits erwähnt, behandeln wir im Practice Guide die richtigen Themen. Werden diese Informationen jedoch so aufbereitet, dass Entwickler ihnen leichter folgen können, etwa in Form dieser Spickzettel, könnte der Leitfaden bei seiner Zielgruppe mehr bewirken.

3. Stellen Sie Beispiele aus der Praxis bereit. Entwickler tüfteln gern und probieren neue Ideen aus. Sie möchten Codebeispiele und neue Tools, die sie selbst testen und ausprobieren können – so wie in unserem jüngsten Blogbeitrag zu schädlichen PyPI-Paketen. Echte Beispiele zum Ausprobieren sind wahrscheinlich der beste Weg, damit Entwickler nicht nur neue Informationen lesen, sondern sie auch in die Praxis umsetzen.

Bei Snyk setzen wir uns dafür ein, Sicherheitsthemen wie diese so zu vermitteln, dass sie für Entwickler leicht zugänglich sind. Hier sind einige Beispiele: eine Lektion von Snyk Learn zum Thema Threat Modeling und ein Spickzettel zu Secure Code Review – beides Themen aus dem Practice Guide. Behalten Sie diesen Blog und Snyk Learn im Blick: Schon bald finden Sie dort weitere Inhalte zu Software-Supply-Chain-Security, die sich an Entwickler richten.