Kontrolle der Sicherheit im Vorfeld mit kontinuierlicher Integration

Die Durchführung von Kontrollen im Vorfeld ist ein Ansatz, der das Testen an einen früheren Zeitpunkt im Softwareentwicklungszyklus verschiebt (deshalb wird dies auch als „Nach links verschieben“ bezeichnet). Wenn Sicherheitstests durchgeführt werden, wenn der Code in Produktion gehen soll, kann es schwierig sein, wieder zurückzugehen und Probleme zu korrigieren. Oft ist es dann für eine schnelle Behebung einfach zu spät. Dies kann zu verzögerten Übergaben, Sicherheitsproblemen und Silos zwischen dem Sicherheitsteam und dem Rest der DevOps-Teams führen.

Da Unternehmen verstärkt versuchen, zu einer DevSecOps-Struktur zu wechseln, wird es entscheidend sein, Sicherheitstests früher in den Entwicklungszyklus einzubinden. Dies geschieht durch die Integration von Sicherheitstests in Bereitstellungspipelines, sodass der Code kontinuierlich getestet wird – nicht nur gegen andere Commits im gemeinsam genutzten Repository, sondern auch im Hinblick auf die Sicherheit.

Kontinuierliche Integration (CI) ist ein Prozess, der die Codequalität durch Bereitstellungspipelines verbessert. Sicherheit kann in einer früheren Projektphase in diese Pipelines integriert werden, was Unternehmen dabei hilft, Kontrollen im Vorfeld vorzunehmen.

Sicherheit in Pipelines für kontinuierliche Integration einbinden

Statische Anwendungssicherheitstests (SAST) sind eine Möglichkeit, die Sicherheit durch kontinuierliche Integration zu automatisieren. SAST analysiert den Quellcode und ermöglicht es Entwickler(inne)n, Probleme zu einem früheren Zeitpunkt im Lebenszyklus der Softwareentwicklung zu beheben.

In GitLab CI/CD überprüft die Bereitstellungspipeline den SAST-Bericht und vergleicht die Sicherheitslücken zwischen den Quell- und Zielbranches. Diese Erkenntnisse erscheinen im Merge Request.

Dynamische Anwendungssicherheitstests (DAST) werden häufig zusammen mit SAST eingesetzt. Während SAST den Quellcode analysiert, analysiert DAST Laufzeitfehler in ausgeführten Anwendungen. Sobald eine Anwendung bereitgestellt wird, ist sie neuen Formen von Sicherheitsrisiken ausgesetzt, wie z. B. Cross-Site-Scripting oder Sicherheitslücken durch fehlerhafte Authentifizierung.

Analog zu SAST überprüft GitLab den DAST-Bericht, vergleicht die Sicherheitslücken zwischen den Quell- und Zielbranches und gibt die Ergebnisse zurück. Der Vergleich verwendet jedoch nur die neueste Pipeline, die für den Basis-Commit des Zielbranches ausgeführt wird.

Andere Arten von Sicherheitstests umfassen Interaktive Anwendungssicherheitstests (IAST) und Anwendungssicherheit zur Laufzeit (RASP). Bei IAST wird ein Agent in einer Anwendung platziert, während RASP vielmehr ein Sicherheitstool ist, das in einer Anwendung platziert wird und auf Live-Angriffe reagieren kann.

Komplexität der Toolchain reduzieren

Neben der zeitaufwändigen Wartung kann eine komplexe Toolchain ein System Sicherheitsrisiken aussetzen. Viele DevSecOps-Teams setzen Plugins, Skripte oder hardcoded benutzerdefinierte Integrationen ein, um ihre Tools zusammenzuführen. Da einige Toolchains manuell durchgeführt werden müssen, sind sie anfällig für menschliche Fehler. Darüber hinaus bedeuten mehr Tools mehr Authentifizierung, mehr Berechtigungen und höhere Sicherheitsanforderungen sowie weniger Sichtbarkeit im Lebenszyklus der Softwareentwicklung. Diese Abstraktionsebenen erschweren es, Probleme nicht nur zu lokalisieren, sondern auch zu beheben.

Ein komplexes System umfasst mehrere Fehlerquellen. Wenn Unternehmen die Sicherheit im Vorfeld behandeln möchten, wird es durch die teilweise Verringerung dieser Komplexität einfacher, Sicherheit und Compliance in den Entwicklungslebenszyklus einzubeziehen. Eine komplexe Toolchain oder eine Plugin-Umgebung kann auch instabile Pipelines verursachen, die besondere Aufmerksamkeit erfordern.

Härte deine Systeme für kontinuierliche Integration

Härten ist ein Prozess zur Sicherung eines Systems durch Verringerung der Anfälligkeit. Ähnlich wie bei der Reduzierung der Komplexität der Toolchain, um die Risikoquellen zu verringern, kann ein Unternehmen mit Härtungschecklisten seine internen Systeme überprüfen und sicherstellen, dass sie bewährte Sicherheitsansätze verfolgen.

Eine Empfehlung besteht darin, die Host-Systeme, die Quell- und Build-Artefakt-Repositories, die CI- und CD-Server sowie die Systeme zu härten, welche die Konfigurationsmanagement-, Build-, Bereitstellungs- und Veröffentlichungstools hosten. Stelle sicher, dass dein Team weiß, was lokal erledigt wird und was sich in der Cloud befindet, und wie sich dies auf die Workflows auswirkt.

Wenn du dein System für kontinuierliche Integration härtest und Sicherheitsscans in deine Bereitstellungs-Pipelines integrierst, können Teams die Sicherheit leichter im Vorfeld kontrollieren. Ausgereifte DevOps-Teams implementieren Sicherheitstests natürlich in ihren kontinuierlichen Integrationsprozess und verfolgen einen Ansatz für die Kontrolle der Sicherheit im Vorfeld. Anstatt die Sicherheit im Nachhinein zu betrachten, behalten diese DevSecOps-Teams die Sicherheit im Blick.