Es ist leider eine allzu verlockende Vorstellung, dass Software-Security-Aktivitäten etwas sind, was man nur einmal erledigen muss und worum man sich, wenn es einmal erledigt wurde, keine Gedanken mehr machen muss. Dass dem nicht so ist dürfte allerdings unschwer zu erkennen sein: unsere Software entwickelt sich kontinuierlich weiter und bietet daher jederzeit die Gefahr, neue Schwachstellen zu entwickeln. Aber auch die Möglichkeiten potenziellen Angreifenden entwickeln sich stetig. So kann beispielsweise ein Verschlüsselungsalgorithmus, der zum Zeitpunkt der Implementierung noch als ausreichend sicher galt, inzwischen veraltet sein und ein Sicherheitsrisiko darstellen. Sicherheitsmaßnahmen sind also genau wie ein Hausputz beständig wiederkehrende Aufgaben und teilweise werden sie auch ähnlich lästig empfunden. So besteht schnell die Gefahr, dass sie irgendwann nicht mehr durchgeführt werden, weil einfach die Motivation fehlt und andere Aktivitäten höher priorisiert werden.
Glücklicherweise gibt es in der Software eine Lösung für langweilige, repetitive Aufgaben: die Automatisierung. Und das Mittel der Wahl für Automatisierungen innerhalb eines agilen Entwicklungszyklus ist in der Regel die DevOps Pipeline. Diese wird benötigt um Continuous Integration (CI) umzusetzen, also die fortlaufende und kleinschrittige Einbindung neuer Features auf einen für die Kund*innen verfügbaren Server. Es sollte hierbei bereits selbstverständlich sein, dass in den Pipelines sämtliche Unit Tests des Projektes durchgeführt werden, um zu gewährleisten, dass nur Code veröffentlicht wird, der alle vorhandenen Tests besteht. Darüber hinaus kann die Pipeline aber auch weitere hilfreiche Aufgaben übernehmen, die dazu beitragen können, dass der Code in unseren Projekten sicher ist und auch bleibt. Ich werde im Folgenden drei Security-Aktivitäten beschreiben, die sich in eine DevOps Pipeline integrieren lassen. Da es sich hierbei meist um vergleichsweise langlaufende Prozesse handelt (was im Umfeld von Pipelines etwa 5-10 Minuten bedeutet), sollten sie nicht für jeden Commit durchgeführt werden, sondern unabhängig von der CI-Pipeline nach einem festgelegten Zeitplan starten. Idealerweise liegt dieser außerhalb der regulären Geschäftszeiten, um die Entwicklungsteams nicht unnötig auszubremsen.
Static Application Security Testing
Beim Static Application Security Testing (SAST) handelt es sich um eine reine Codeanalyse, das Programm wird also nicht zur Laufzeit getestet. Hierdurch lassen sich bekannte Muster im Code wiederfinden, welche auf Schwachstellen in der Anwendung hinweisen können. Oft werden so auch nicht direkt Sicherheitslücken gefunden, sondern sogenannte „Bad Pracitces“ also zu vermeidende Praktiken bei der Entwicklung. Auch wenn diese nicht unmittelbar zu einer Schwachstelle führen müssen, ist es doch lohnenswert, sie zu beheben, da so der Code im Ganzen lesbarer und wartbarer wird. Je einfacher ein Stück Software zu verstehen ist, um so geringer ist die Gefahr, dass sich ein Fehler einschleicht und um so weniger Zeit kostet es im Ernstfall eine Änderung vorzunehmen. Natürlich wird ein SAST genau wie alle anderen automatisierten Tools eine gewisse Menge an false positives produzieren, da es auch nur eine Mustererkennung bieten kann und kein echtes Verständnis des Codes. Letzten Endes muss ein erfahrene*r Entwickler*in die jeweiligen Ergebnisse auswerten.
Secret Scanning
Zur Laufzeit benötigen die allermeisten Programme Zugriff auf externe Systeme wie zum Beispiel Datenbanken oder Storage Accounts. Um sich gegen diese Systeme zu autorisieren werden Passwörter benötigt. Die Speicherung dieser Passwörter sollte dabei immer den höchstmöglichen Sicherheitsstandards unterliegen, da beispielsweise ein unbefugter Zugriff auf eine Produktivdatenbank verheerende Folgen für jedes Unternehmen haben kann. Eine Git-Repository oder andere Quellcodeverwaltungssysteme sind nicht dafür ausgelegt, die notwendigen Sicherheitsstandards zu gewährleisten, daher sollten vertrauliche Daten niemals direkt im Quellcode stehen, sondern über spezialisierte Tools wie beispielsweise den Azure Key Vault gemanagt werden. Ein Secret Scanning Task in der Pipeline kann selbstständig prüfen, ob Passwörter oder ähnliche Schlüssel in die Quellcodeverwaltung eingecheckt wurden. Sollte hierbei tatsächlich etwas gefunden werden, so muss dieses Passwort als korrumpiert angesehen werden. In diesem Fall ist es notwendig, das alte Passwort sofort zu deaktivieren und durch ein neues Passwort zu ersetzen, welches nicht mehr in der Quellcodeverwaltung landet. Um diesen Aufwand zu vermeiden ist es empfehlenswert, diese Prüfung bereits vor dem Check-In des Codes durchzuführen, beispielsweise durch einen Pre-Commit Hook. Da solche Checks jedoch vom lokalen Nutzenden übersprungen werden können, ist eine zusätzliche Prüfung in der Pipeline notwendig.
Software Composition Analysis
Beinahe jede Software ist auf Drittanbieterpakete angewiesen, da es weder wirtschaftlich noch ratsam ist, sämtliche Funktionalität selbst zu implementieren. Dies hat jedoch den Nachteil, dass man nicht nur die gewünschte Funktionalität, sondern auch potenzielle Angriffsvektoren importiert. Eine Möglichkeit dieses Risiko zu verringern ist die Software Composition Analysis (SCA). Diese gleicht die Liste der in unserem Projekt verwendeten Pakete mit offiziellen Listen bekannter Schwachstellen ab. Besitzt eines der von uns verwendeten Pakete eine bekannte Schwachstelle, so wird ein entsprechender Report erstellt und der Pipelinelauf schlägt fehl. In vielen Fällen werden von den jeweiligen Plugin-Entwickelnden zeitnahe Fixes bereitgestellt, sodass man lediglich ein Versions-Update durchführen muss. Ist dies unglücklicherweise nicht der Fall, muss man als Entwickelnder abwägen: Kann ich das Paket ersetzen, kann ich das Risiko in Kauf nehmen oder muss ich auf die Funktionalität dieses Pakets verzichten?
Natürlich lassen sich innerhalb der Pipeline-Tasks noch mehr Features umsetzen, die auf die Sicherheit unserer Projekte einzahlen. Diese drei Aufgaben stellen lediglich eine Basis dar, welche mit relativ geringem Aufwand den Schutz des Projekts deutlich steigern kann.
Ähnliche Artikel
