Softwareentwicklung ist eine Praxis, mit der immer mehr Menschen auf der ganzen Welt beschäftigt sind. Es gibt sowohl Unternehmen als auch Einzelpersonen, die Software entwickeln, einige davon proprietär, andere kostenlos oder Open Source, und einige sind eine Mischung aus beiden. Da Bedrohungen für die Sicherheit von Benutzern oder ihrer Software nicht aus dem Äther kommen, sobald etwas als abgeschlossen erklärt und in die Produktion geht, scheint es der richtige Zeitpunkt zu sein, über Sicherheitspraktiken zu sprechen, die dabei helfen könnten, Sicherheitsrisiken zu bewältigen, die sich möglicherweise einschleichen Ihre Software während des Entwicklungsprozesses. Es gibt mehrere SSDLC-Frameworks (Secure Software Development Life Cycle), darunter auch solche von OWASP, CISA und NIST (SSDF). In diesem Artikel greifen wir einige davon auf, um einige Vorgehensweisen hervorzuheben, die Ihnen dabei helfen sollen, das mit der Softwareentwicklung verbundene Risiko zu bewältigen. Leben Sie nicht mit einem Gefühl falscher Sicherheit und denken Sie, dass Ihnen das nicht passieren kann. Der Halbjahresbericht zur Cybersicherheit von Check Point 2023 zeigt einen Anstieg der weltweiten Cyberangriffe um 8 % im Laufe des Jahres 2022, und der Trend scheint sich nicht umzukehren.
Was ist der Softwareentwicklungslebenszyklus?
Ziel von Softwareentwicklern ist es, Software schnell, genau und sicher zu erstellen. Natürlich kann man nicht immer alle drei bekommen. Im Laufe der Zeit wurde der Entwicklungsprozess in mehrere unterschiedliche Phasen unterteilt, die zu jeder Softwareentwicklung passen. Diese Phasen können wie folgt unterteilt werden:
- Anforderungsanalyse – Was werden wir bauen und warum
- Planung – wie wir es im Allgemeinen aufbauen werden
- Software-Design – wie wir es konkret bauen werden, beispielsweise hinsichtlich des architektonischen Designs
- Software-Entwicklung – Schreiben und Kompilieren der Software
- Testen – Stellen Sie sicher, dass es wie geplant funktioniert
- Einsatz – Versenden oder veröffentlichen Sie es, damit der Endbenutzer es verwenden kann
Es gibt noch einige andere Versionen dieses Zyklus, aber insgesamt sind sie sehr ähnlich. Es ist wichtig, sich daran zu erinnern, dass der Zyklus keine einmalige Sache ist – er endet normalerweise nicht, sobald Sie es an den Kunden versendet oder in der Cloud veröffentlicht haben. Es gibt fast immer Probleme, mit denen Sie sich befassen müssen, die möglicherweise eine Neugestaltung erfordern (zurück zum Anfang), Fehler, die Sie beheben müssen, Funktionen, die Sie hinzufügen möchten, und so weiter. Es kann auch vorkommen, dass Sie an mehreren Schritten parallel arbeiten oder mitten im Schritt anhalten, um sich umzudrehen. Da keiner der Schritte von Natur aus sicherheitszentriert ist, muss die Sicherheit ständig mit dem Entwicklungsprozess Schritt halten, was angesichts der heutigen hektischen Entwicklungsgeschwindigkeiten nicht ausreicht.
Die Bedeutung der Sicherung Ihres SDLC
Bei der sicheren Softwareentwicklung geht es darum, Sicherheitsüberlegungen in alle Phasen des Prozesses einzubeziehen und Sicherheit nicht als Zusatz zum Prozess zu betrachten. Daher sollte Sicherheit immer eine Überlegung sein, egal in welcher Phase des Prozesses Sie sich befinden – Sie denken über die Projektanforderungen nach, planen die Architektur, berücksichtigen die erforderlichen Bausteine und Infrastruktur und setzen sich an die Entwicklung des Codes. Dieser Ansatz wird manchmal als „ Shift-Links-Sicherheit Ansatz.
Hier bezieht sich Shift-Left auf die Verteilung von Sicherheitsbedenken über den gesamten Entwicklungsprozess und die Einbeziehung der Entwickler in das Sicherheitsdesign, die Implementierung und das Testen.
Für Entwickler, die noch nie wirklich über Sicherheitsprobleme nachgedacht haben, kann es einschüchternd sein, sich plötzlich damit auseinandersetzen zu müssen. Deutlich einfacher zu handhaben ist es, wenn die Anforderungen in mehrere klar definierte Best Practices aufgeteilt werden. Man kann es sich so vorstellen, als würde man sich eine neue IDE besorgen.
Je klarer die Anforderungen sind und je mehr Automatisierung und umfassende Tools Sie einsetzen können, desto einfacher werden die Aufgaben.
Best Practices für die SDLC-Sicherheit
Hier sind einige Best Practices, die Ihnen helfen, Ihren Entwicklungsprozess in keiner bestimmten Reihenfolge zu sichern:
Ausbildung – Viele Entwickler fühlen sich der Aufgabe nicht gewachsen, Sicherheitsüberlegungen und Tests auf den von ihnen geschriebenen Code anzuwenden. Die Mehrheit der Entwickler ist sich darüber im Klaren, dass das Einschleusen verfälschter Eingabedaten in Ihr Backend zu einer Codeaktivierung aus der Ferne führen kann, ähnlich wie bei den bekannten „Drop Tables“. Weniger Menschen wären jedoch mit Pufferüberlauftests oder Schwachstellenscans für tertiäre (oder weitere) Abhängigkeiten vertraut. Entwickler können diese Wissenslücken durch den Einsatz von Schulungen schließen. Entwickler sind besser in der Lage, Sicherheitsbedenken in ihre täglichen Codierungen und Tests einzubeziehen, wenn sie ein tieferes Verständnis der Sicherheitsherausforderungen und potenziellen Schwachstellen haben. Außerdem ist es für den Entwickler, der den Code geschrieben hat und mit seiner Funktion bestens vertraut ist, viel sinnvoller, die Sicherheitslücken zu berücksichtigen und die Tests entsprechend zu planen.
Scannen – Sie können viele Arten des Scannens verwenden, um Ihren Code insgesamt sicherer zu machen. Statische, dynamische und interaktive Analysen sind einige davon. Die statische Analyse sucht nach offensichtlichen Codierungsfehlern oder möglichen Sicherheitslücken im Quellcode. Es kann verwendet werden, um nach potenziellen Schwachstellen, unsicheren Codepraktiken und Verstößen gegen Codierungsstandards zu suchen. Laufzeitereignisse werden nicht berücksichtigt, da nur die Codesyntax untersucht wird. Die dynamische Analyse sucht nach Sicherheitslücken, Codierungsfehlern und anderen Problemen in der Anwendung, während diese ausgeführt wird. Es kann verwendet werden, um Speicherlecks, minderwertige Vorgänge und möglicherweise instabile Eingaben oder Prozesse zu identifizieren. Beachten Sie, dass die Qualität der Tests vollständig von den Personen abhängt, die sie entwickelt haben, da diese Art von Tests zu einem bestimmten Zeitpunkt unter Verwendung spezifischer Eingaben durchgeführt wird. Ziel ist es, die Probleme zu finden, bevor es Ihre Benutzer tun. Die interaktive Analyse untersucht die Anwendung, um mögliche Sicherheitslücken und andere problematische Probleme zu finden. Es kann nach möglichen Schwachstellen, Usability-Problemen und Problemen mit der Benutzeroberfläche suchen. Je umfassender die Scan-Tools Sie verwenden, desto besser sind Sie geschützt, aber der Nachteil besteht natürlich in der Entwicklungsgeschwindigkeit. Da jede Anwendung einzigartig ist, liegt es an Ihnen, die Balance zwischen dem richtigen Scanumfang und der gewünschten Entwicklungsgeschwindigkeit zu finden. Darüber hinaus empfehlen wir, eine vollständige SBOM Ihrer Anwendung zu erstellen und verschiedene Scans und Berichte auch auf diese Datenquelle anzuwenden. Ein SBOM-Vermächtnis Ihrer App ist eine gute Möglichkeit, sehr detaillierte Komponenten- und Paketinformationen aufzubewahren, die aus zahlreichen Sicherheitsgründen von unschätzbarem Wert sein können.
Code-Bewertungen – Die Untersuchung des Quellcodes auf Sicherheitslücken, Codierungsfehler und andere Softwaremängel vor der Kombination mit dem aktiven Entwicklungszweig wird als Codeüberprüfung bezeichnet. Typischerweise wird diese Überprüfung von einem Entwickler durchgeführt, der über mehr Fachwissen verfügt als derjenige, der den Code verfasst hat. Solche Überprüfungen können dazu beitragen, sicherzustellen, dass der Code gut geschrieben und die Anwendung sicher ist. Darüber hinaus unterstützen sie die Beibehaltung eines einzigen Standards und von Codierungskonventionen (z. B. Funktions- und Variablennamen) in der gesamten Codebasis.
Es gilt als Best Practice, die Integration von Code in den Hauptzweig zuzulassen, nachdem er von mindestens zwei Augenpaaren überprüft wurde. Der Entwickler, der den Code verfasst hat, ist natürlich das erste Augenpaar. Selbst für hochqualifizierte Ingenieure wie Teamleiter kann es von Vorteil sein, wenn jemand anderes ihren Code bewerten lässt. Dies stellt zumindest sicher, dass mehr als eine Person mit jedem Abschnitt des Codes vertraut ist. Bedenken Sie, dass Menschen in Zeiten großen Stresses oder in Krisenzeiten möglicherweise darüber nachdenken, auf dieses Element zu verzichten. Erwägen Sie nach Möglichkeit, diese Regel als fest codiertes Element Ihrer CI/CD hinzuzufügen, damit sie nicht umgangen werden kann.
Testen – Wir müssen Ihnen nicht sagen, wie wichtig es ist, Ihren Code zu testen, um Sicherheitslücken zu entdecken, bevor sie zu einem Problem werden. Die meisten Codeprojekte sind komplex und miteinander verbunden, daher ist es unmöglich vorherzusagen, wie sich eine einzelne kleine Lücke letztendlich auf die Sicherheit der gesamten Codebasis auswirken kann.
Berücksichtigen Sie beim Schreiben automatisierter Tests die Funktionalität des kürzlich erstellten Codes sowie alle wesentlichen Back-End- und Front-End-Interaktionen mit anderen Teilen der Codebasis.
Sicherheitslücken wie SQL-Injection, Cross-Site-Scripting, unsichere Datenspeicherung und unzureichende Speicherzuweisung (die zu Pufferüberläufen führen können) sind Beispiele für Sicherheitsprobleme, die typischerweise beim Testen angegangen werden. Beim Testen sollten Speicherlecks, träge oder unzuverlässige Leistung und Benutzerfreundlichkeit behoben werden. Die Tests sollten automatisch erfolgen und in die CI/CD-Pipeline integriert sein, sodass keine neue Version oder kein Update veröffentlicht werden kann, ohne sowohl Unit- als auch Integrationstests durchlaufen zu haben.
Unabhängiger Pentest – Niemand kann an alles denken und als Entwickler entwickeln wir manchmal blinde Flecken in Bezug auf den Code, den wir geschrieben haben. Ähnlich wie bei der Codeüberprüfung ermöglichen unabhängige Pentests einen neuen Ansatz und eine andere Sichtweise, um kritisch zu prüfen, was wir getan haben und welche Vorsichtsmaßnahmen wir getroffen haben, um unsere App und unsere Benutzer zu schützen. Solche Tests werden mindestens einmal im Jahr empfohlen und sollten eine Infrastrukturbewertung sowie App-Schwachstellen umfassen.
Verwenden Sie Open Source sicher – Fast jede Software, die sich heute in der Entwicklung befindet, umfasst mehr oder weniger Open-Source-Software. Open-Source-Komponenten gehören zu den Hauptursachen für importierte Schwachstellen in Ihrer Anwendung, entweder direkt oder durch vorübergehende Abhängigkeiten. Darüber hinaus können nicht nur die von Ihnen verwendeten Bibliotheken eine Gefahr für Sie darstellen, sondern auch das Versäumnis, alte Bibliotheken zu aktualisieren oder sich nicht über die neuesten veröffentlichten CVEs auf dem Laufenden zu halten, was Auswirkungen auf Sie haben könnte. Wir empfehlen, eine Liste genehmigter Open-Source-Pakete zur Verwendung durch die Organisation zu erstellen und diese ständig zu überprüfen und zu aktualisieren. Wenn Sie die Entwickler daran hindern, jedes gewünschte Paket hinzuzufügen, auch wenn es nur zu Testzwecken ist, könnte dies dazu beitragen, die Anzahl der Schwachstellen zu verringern, mit denen Sie zu kämpfen haben.
Stellen Sie sicher, dass Schwachstellen nicht zu Exploits werden – Es gibt fast keine Codebasis ohne Schwachstellen. Bei jedem anständigen Scan würden Hunderte bis Tausende davon auftauchen. Es ist unmöglich, sie alle zu beseitigen. Es ist auch wichtig, sich daran zu erinnern, dass Schwachstellen keine Exploits sind. Stellen Sie sicher, dass Sie über einen Filterprozess verfügen, um sicherzustellen, dass jede von Ihnen entdeckte Schwachstelle keine ausnutzbare Bedrohung darstellt, und halten Sie diese Liste ständig auf dem neuesten Stand. Auf diese Weise können Sie allen Dritten oder Benutzern, die über das neueste CVE besorgt sind, mitteilen, dass es absolut keine Auswirkungen auf Ihre Anwendung hat.
Sicherheit beginnt mit Ihrer Denkweise
Es gibt wahrscheinlich so viele verschiedene Möglichkeiten, Software zu entwickeln, wie es Entwickler, Frameworks und Programmiersprachen gibt. Das heißt, es ist nicht einfach, Best Practices zur Sicherung Ihres Entwicklungsprozesses zu finden, die unabhängig von der Sprache, dem Fachgebiet oder der verwendeten IDE relevant sind. Abgesehen von einer Vielzahl von Tools, von denen einige proprietär und andere kostenlos sind und die alle als „das nächste unersetzliche Sicherheitstool“ nach Ihrer Aufmerksamkeit schreien, ist Ihre Denkweise das wichtigste Sicherheitstool, das Sie einsetzen können.
Denken Sie über Ihre Designentscheidungen, Architektur und Speichermöglichkeiten nach. Haben Sie die Möglichkeit eines exponentiellen Wachstums Ihrer Nutzerbasis in Betracht gezogen? Haben Sie die Zugriffsrechte für verschiedene Teile Ihrer Codebasis und Infrastruktur ordnungsgemäß segmentiert? Haben Sie sowohl einen gezielten Angriff auf Ihre Daten oder Geheimnisse als auch einen „indirekten“ Angriff auf die Software-Lieferkette in Betracht gezogen?
All diese und weitere Fragen sollten berücksichtigt werden, bevor Sie sich überhaupt an die Planung Ihrer Anwendung machen, und sie sollten regelmäßig überprüft werden, wenn die Codebasis und die App wachsen und sich weiterentwickeln.
Es gilt als Axiom, dass der anfälligste Teil jeder Software der Mensch ist, der sie ausführt (oder schreibt). Lassen Sie nicht zu, dass Ihre Anwendung, Software oder Codebibliothek Teil der steigenden Statistiken einer neuen Welle von Cyberangriffen wird. Mit der richtigen Planung, Tools und Automatisierung können Sie die richtige Balance zwischen dem Management von Cyberrisiken, der Sicherung Ihres Entwicklungslebenszyklus und der Erstellung von gut dokumentiertem, umfassendem und effizientem Code finden.