So verwandeln Sie eine DevOps-Pipeline in eine DevSecOps-Pipeline: Eine Übersicht über das Shift-Left-Konzept

Hallo, HackerNoon! Mein Name ist Sofia und ich bin DevOps/Cloud-Ingenieurin. Ich habe mich entschieden, am Wettbewerb von HackerNoon und Aptible teilzunehmen. In diesem Artikel werde ich über die Funktionen der DevSecOps-Pipeline und das Konzept von Shift Left sprechen. Sie erfahren mehr über die Hauptphasen der DevSecOps-Pipeline, automatisierte Sicherheitsprüfungen in der Softwareentwicklung sowie kostenlose und Open-Source-Tools. Außerdem finden Sie Tipps, die Ihnen helfen, Schwachstellen früher zu erkennen und die Anwendungssicherheit zu verbessern. Dieser Artikel hilft Ihnen dabei, den Reifegrad Ihrer DevSecOps-Pipeline einzuschätzen, eine Roadmap für deren Entwicklung zu entwickeln, die richtigen Tools für jede Aufgabe auszuwählen und besser zu verstehen, wie Sie Projekte gemäß der DevSecOps-Philosophie verwalten. Konzept der Verschiebung nach links Das Hauptziel der DevSecOps-Methodik besteht darin, automatisierte Sicherheitsprüfungen in die DevOps-Pipelines, also in den Softwareentwicklungsprozess selbst, einzuführen. Vor nicht allzu langer Zeit führten Informationssicherheitsspezialisten nach Abschluss des Entwicklungsprozesses Tests durch. Dieser Ansatz ist ineffizient – wenn bei Sicherheitstests Fehler entdeckt werden, muss der gesamte Entwicklungszyklus neu gestartet werden. Das ist zeitaufwändig und teuer. Schauen Sie sich das Bild unten an. Sie sehen, dass der Aufwand für die Fehlerkorrektur mit jedem Schritt steigt. Es kostet fast nichts, Sicherheitsprobleme zu beheben, die während der Entwicklung und Funktionstests entdeckt werden. Alle notwendigen Änderungen können sofort am Quellcode vorgenommen und zur erneuten Prüfung gesendet werden. Die Behebung von Problemen in der Artefakterstellungsphase ist mindestens doppelt so teuer. Sie müssen Änderungen am Build-Prozess vornehmen, beispielsweise die Docker-Datei bearbeiten, was bedeutet, dass Sie die Hilfe von DevOps-Ingenieuren benötigen. Wenn beim Integrationstest ein Fehler entdeckt wird, ist die Behebung zehnmal teurer. In diesem Fall müssen Sie den Entwicklungszyklus neu starten und Entwickler, DevOps-Ingenieure und Tester einbeziehen. In der Bereitstellungsphase erkannte Sicherheitsprobleme können zu Benutzerdatenlecks führen. Das Unternehmen kann Bußgelder in Millionenhöhe und einen Rufschaden erleiden, was bedeutet, dass sich die Kosten eines Fehlers um das Hundertfache erhöhen. Die wichtigste Schlussfolgerung ist daher, dass Sicherheitskontrollen so früh wie möglich durchgeführt werden sollten. Wenn Sie es visualisieren, verschieben Sie sie auf die linke Seite der Pipeline. Das ist das Konzept von Shift Left, über das Sicherheitsexperten so gerne sprechen. Struktur der DevSecOps-Pipeline DevSecOps-Pipelines sind eine automatisierte Kette von Prozessen und Tools, die Anwendungen in einer Produktionsumgebung erstellen, testen und bereitstellen und sie in jeder Phase sichern. Das Bild oben zeigt die Struktur der DevSecOps-Pipeline mit allen Hauptphasen der Sicherheitsüberprüfungen. Hier sind ein paar Worte zu jedem von ihnen: Vorab festlegen. Dabei wird die Sicherheit des Quellcodes überprüft, bevor der Entwickler den Code an das Versionskontrollsystem übergibt. Mit dieser Prüfung können Sie unverschlüsselte vertrauliche Informationen wie Passwörter oder API-Schlüssel erkennen. Vorgefertigt. Dabei wird die Sicherheit des Quellcodes überprüft, nachdem dieser in das Versionskontrollsystem gelangt ist. Die Tools führen eine statische Analyse des Quellcodes und seiner Abhängigkeiten durch, um häufige Schwachstellen wie viele der zu erkennen Liste. OWASP Top Ten Nachbau. Dabei handelt es sich um die Sicherheitsüberprüfung eines Artefakts, das aus Quellcode erstellt wurde, beispielsweise einer Docker-Datei, einem RPM-Paket oder einem JAR-Archiv. Die Tools analysieren die Anwendungsumgebung und Abhängigkeiten und finden veraltete Versionen von Paketen und Bibliotheken, die bereits über Patches in neueren Versionen verfügen. Testzeit. Dabei wird die Sicherheit einer Anwendung getestet, die auf einem gesammelten Artefakt ausgeführt wird. Tools in dieser Phase versuchen, die Anwendung zu „kaputtmachen“, indem sie die Aktionen der Angreifer simulieren. Nach der Bereitstellung. Dabei wird die Sicherheit einer Anwendung überprüft, nachdem sie in einer Produktionsumgebung bereitgestellt wurde. Die Tools überwachen offene Register bekannter Schwachstellen in Echtzeit und benachrichtigen, wenn eine Bedrohung für die Anwendung erkannt wird. Schauen wir uns als Nächstes genauer an, was diese Prüfungen sind und mit welchen Tools sie durchgeführt werden. Prüfungen vor dem Commit Mit Pre-Commit-Prüfungen können Sie den Quellcode auf dem Computer des Entwicklers analysieren, bevor Sie Änderungen an der lokalen Kopie des Repositorys festschreiben. Wenn eine der Anweisungen einen Fehler zurückgibt, wird der Commit nicht ausgeführt. In diesem Fall muss der Entwickler den Fehler beheben und erneut festlegen. Diese Prüfung vermeidet die Situation, dass ungeprüfter Code, beispielsweise mit unverschlüsselten Geheimnissen, in das Repository gelangt. Für die Durchführung von Quellcodeprüfungen vor dem Commit ist es notwendig, Tools auf den lokalen Rechnern der Entwickler zu installieren. Dieser Ansatz hat nicht nur Vorteile, sondern auch Nachteile. Zum Beispiel Umgebungsunterschiede: unterschiedliche Versionen der Instrumente, unterschiedliche Betriebssysteme und sogar Prozessorarchitekturen. Wenn Entwickler unterschiedliche Versionen von Pre-Commit-Tools verwenden, unterscheiden sich die Ergebnisse der Überprüfung, was die Zusammenarbeit erschweren kann. Berücksichtigen Sie dies, wenn Sie Pre-Commit-Prüfungen innerhalb eines Teams oder im gesamten Unternehmen durchführen. Tools für Pre-Commit-Prüfungen Viele Open-Source-Tools können zum Einrichten von Pre-Commit-Prüfungen verwendet werden: Gitleaks Git-Geheimnisse Trivy Secret Scanning Flüstern Git-All-Geheimnisse Geheimnisse erkennen Gitty-Lecks Dies sind großartige Tools für Pre-Commit-Prüfungen. Prüfungen vor dem Bau In der Pre-Build-Phase werden White-Box-Tests durchgeführt. Diese Prüfungen werden wie im vorherigen Schritt zur Analyse des Quellcodes verwendet. In diesem Fall handelt es sich bei der Anwendung um eine „White Box“, da wir ihre Architektur und interne Struktur kennen und verstehen. Es gibt verschiedene Arten von Pre-Build-Prüfungen: Geheime Entdeckung Statische Anwendungssicherheitstests (SAST) Software-Kompositionsanalyse (SCA) Lassen Sie uns sie nun im Detail besprechen. Vorgefertigte Geheimerkennungsprüfung Secret Detection ist eine automatisierte Prüfung, die unverschlüsselte vertrauliche Informationen erkennt: unverschlüsselte Geheimnisse im Quellcode, die in ein Versionskontrollsystem gelangt sind. Pre-Build-Prüfungen werden durchgeführt, nachdem der Quellcode in das Repository des Versionskontrollsystems gelangt ist. Daher können Angreifer möglicherweise auf alle unverschlüsselten sensiblen Daten im Speicher zugreifen, beispielsweise wenn der Inhalt des Repositorys durchgesickert ist. Darüber hinaus kann es sein, dass der Prozess der Implementierung von Geheimniserkennungsprüfungen nicht von Grund auf, sondern in einem sich entwickelnden Projekt erfolgt. In diesem Fall können unverschlüsselte Geheimnisse in alten Commits und verschiedenen Repository-Zweigen gefunden werden. Um diese Probleme zu lösen, müssen wir viele verschiedene Dinge tun. Beispielsweise müssen wir Repositories von unverschlüsselten Geheimnissen befreien oder verschiedene Geheimnisseverwaltungstools wie implementieren. Hashicorp Vault Tools zur Geheimerkennung Die Geheimerkennung kann mit konfiguriert werden , , oder . Am besten nutzen Sie jedoch die Dienste bekannter CI/CD-Plattformen, zum Beispiel . Gitleaks Git-Geheimnisse Geheimnisse erkennen GitLab-Geheimniserkennung SAST-Prüfung vor dem Build Static Application Security Testing (SAST) ist ein Test, bei dem Analysatoren nicht nur die syntaktische Korrektheit überprüfen, sondern auch die Codequalität mithilfe einzigartiger Metriken messen. Die Hauptaufgabe von SAST-Scannern ist die Sicherheitsprüfung. Insbesondere enthalten SAST-Analysatoren Quellcode für häufige Schwachstellen, beispielsweise einige der Listen. Es ist wichtig zu sagen, dass SAST-Scanner nicht nur die Schwachstelle selbst finden, sondern auch das Codefragment, das sie verursacht hat. OWASP Top Ten Die SAST-Analyse wird White-Box-Testing genannt, da der Analysator auf die interne Struktur der Anwendung zugreifen kann. Es ist wichtig zu beachten, dass Analysegeräte den Quellcode überprüfen, ohne ihn auszuführen, sodass sie möglicherweise Fehlalarme generieren und einige Schwachstellen nicht erkennen. Aus diesem Grund sollten Sie sich nicht nur auf die SAST-Analyse beschränken. Es ist besser, das Problem umfassend anzugehen und verschiedene Analysetypen zu verwenden: SCA, DAST, IAST und OAST. SAST-Tools Proprietäre Lösungen: e SonarQub Checkmarx SAST Solar-AppScreener Die kostenlose Lösung ist GitLab SAST. SCA-Prüfung vor dem Build-Quellcode Software Composition Analysis (SCA) ist eine Methodik, die Anwendungen durch die Analyse ihrer Open-Source-Komponenten sichert. SCA-Scanner suchen nach veralteten Abhängigkeiten, die bekannte Schwachstellen und Exploits enthalten. Darüber hinaus können einige SCA-Tools die Lizenzkompatibilität von Komponenten und das Risiko einer Lizenzverletzung ermitteln. Source SCA analysiert den Quellcode und insbesondere die im Quellcode definierten Anwendungsabhängigkeiten. Diese Analyse wird oft als Dependency Scanning bezeichnet. Mit SCA können Sie ein Problem erkennen, bei dem eine Schwachstelle in einer Komponente zu Sicherheitsproblemen in allen Anwendungen führen kann. Ein gutes Beispiel ist . Diese Schwachstelle wurde Ende 2021 in Log4j, einem beliebten Java-Logging-Framework, entdeckt. Sie wurde zu einer der am meisten gefürchteten Sicherheitslücken, da sie es Angreifern ermöglichte, beliebigen Java-Code auf Hunderten Millionen Geräten auszuführen. Log4Shell SCA-Tools ist eine Open-Source-Lösung. Trivy Kommerzielle Lösung mit kostenlosen Preisplänen: FOSSA SCA reparieren Als Teil von GitLab (nur in der Ultimate-Version verfügbar) können Sie verwenden . GitLab-Abhängigkeitsscan Post-Build-Prüfungen: Binäre SCA Die Post-Build-Phase erfolgt, nachdem Artefakte aus dem Quellcode in der CI-Pipeline erstellt wurden: ein Docker-Image, ein RPM-Paket oder ein JAR-Archiv. Mit Post-Build-Prüfungen können Sie die Abhängigkeiten in diesen binären Artefakten analysieren. Bei der binären SCA-Analyse werden binäre Artefakte wie Docker-Images, RPM-Pakete und JAR/WAR/EAR-Archive untersucht. Es wird oft auch als Container-Scanning bezeichnet. Es ist sinnvoll, es auszuführen, wenn die binären Artefakte erstellt werden, also nicht vor der Post-Build-Phase. Bei der Arbeit mit Docker-Images gibt es einige spannende Funktionen. Binäre SCA-Analysatoren überprüfen Schichten von Docker-Images und suchen sie als Hash-Summen in öffentlichen Schwachstellendatenbanken wie z oder . Nationale Schwachstellendatenbank (NVD) Snyk Vulnerability DB Einige der Analysatoren können nicht nur anfällige Komponenten finden, sondern auch eine Behebung vorschlagen, indem sie beispielsweise die mindestens erforderliche Version einer Komponente mit einer bereits behobenen Schwachstelle angeben. Beispiele für beliebte binäre SCA-Analysatoren Die kostenlose Lösung ist . GitLab-Container-Scanning Open-Source-Lösungen: Wissenswertes Clair Traube Kai JFrog Röntgen Docker-Hub Docker Registry mit integrierten Analysatoren - . Hafen Testzeitprüfungen: DAST, IAST und OAST In dieser Phase werden dynamische Gray-Box-Tests und Black-Box-Tests durchgeführt. Wenn die interne Struktur der Anwendung teilweise oder vollständig unbekannt ist, werden diese Sicherheitsüberprüfungen durchgeführt, indem die Aktionen eines Angreifers nachgeahmt werden, der Schwachstellen findet und versucht, die Anwendung zu „kaputtmachen“, indem er sie ausnutzt. Lassen Sie uns jeden von ihnen kurz besprechen: DAST, IAST und OAST. Testzeit-DAST-Prüfung DAST-Scanner testen Anwendungen automatisch, indem sie externe Angriffe durch verschiedene Schwachstellen simulieren. Die Anwendung ist eine Blackbox für den Analysator; darüber ist nichts bekannt. Für DAST-Prüfungen ist es erforderlich, dass dem Scanner eine laufende Instanz der Anwendung zur Verfügung steht. Darüber hinaus wird es umso weniger Fehlalarme geben, je näher die Parameter der Testinstanz der Anwendung an der Produktionsinstallation liegen. Angenommen, Sie haben eine Testanwendungsinstanz bereitgestellt, auf die nur über das HTTP-Protokoll zugegriffen werden kann, in der Produktion ist die Anwendung jedoch nur über das HTTP-Protokoll zugänglich. In diesem Fall generiert der DAST-Scanner einige Fehler, die auf die fehlende Verkehrsverschlüsselung zwischen dem Client (Analysator) und dem Server (Anwendungsinstanz) zurückzuführen sind. Beispiele für DAST-Tools Werkzeuge, die Ihre Aufmerksamkeit wert sind: — nur in der Ultimate-Version verfügbar GitLab DAST — eine Open-Source-Lösung, die auch in GitLab DAST verwendet wird OWASP Zed Attack Proxy (ZAP) Acunetix Stärken Sie WebInspect HCL Security AppScan Synopsys verwaltetes DAST (Scannen von Web-Apps) Tenable.io Dynamische Analyse von Veracode Großartig, weitermachen. IAST-Prüfung zum Testzeitpunkt IAST (Interactive Application Security Testing) ist ein Gray-Box-Test, der die Vorteile und Stärken von White-Box-Testing (SAST) und Black-Box-Testing (DAST) vereint. Um alle Vorteile zu vereinen und die Nachteile der SAST- und DAST-Methoden zu beseitigen, haben die Entwickler IAST erfunden – einen Hybridmechanismus, der diese Methoden kombiniert. Es erhöht die Genauigkeit dynamischer Tests, da es durch Codeanalyse mehr Informationen über den Anwendungsbetrieb liefert. Es sei daran erinnert, dass IAST neben seinen Vorteilen auch Einschränkungen aufweist. Der grundlegendste ist die Abhängigkeit von der Sprache, in der die zu testende Anwendung geschrieben ist. IAST-Lösungen arbeiten auf Anwendungsebene und erfordern Zugriff auf den ausführbaren Code, um sein Verhalten zu analysieren. Das bedeutet, dass IAST-Lösungen in der Lage sein müssen, die Programmiersprache zu verstehen, in der die Anwendung geschrieben ist. Es ist zu beachten, dass die Unterstützung einer bestimmten IAST-Lösung für einige Sprachen möglicherweise besser implementiert ist als für andere. Auch die IAST-Analyse dauert lange. Dies hängt von vielen Faktoren ab, beispielsweise der Größe und Komplexität der Anwendung, der Anzahl externer Abhängigkeiten und der Leistung des verwendeten IAST-Tools. Außerdem scannt der Analyseprozess nicht den Code selbst, sondern überprüft nur die Fragmente, die direkt ausgeführt werden. Daher lässt sich die IAST-Analyse am besten mit Funktionstests kombinieren, wenn Sie möglichst viele Anwendungsszenarien testen können. Beispiele für IAST-Tools Hier sind tolle Tools für Sie: Synopsys-Sucher Interaktive Veracode-Analyse Microfocus Fortify WebInspect Checkmarx CxIAST Kontrastbeurteilung Hdiv-Erkennung (IAST) Großartig, weitermachen. Testzeit-OAST-Prüfung OAST (Out-of-Band Application Security Testing) ist eine Technik, die von entwickelt wurde und ist eine Erweiterung von DAST, die Schwachstellen findet, die DAST nicht erkennt, wie z. B. log4shell. PortSwigger Beispiele für OAST-Tools Ich empfehle dir: Rülpsen-Suite OWASP ZAP mit OAST-Plugin OAST-Dienste , , Und PRAHLEREI Tuk Tuk interagieren Weitergehen. Überprüfungen nach der Bereitstellung Dies ist ein wesentlicher Schritt zur Gewährleistung der Anwendungssicherheit und Bedienbarkeit. Im Gegensatz zu Pre-Commit-Prüfungen, die in der Entwicklungsphase durchgeführt werden, können Sie mit Post-Deploy-Prüfungen mögliche Probleme bereits während des Anwendungsbetriebs in der natürlichen Umgebung erkennen. Überwachung der Sicherheit von Artefakten Um neue Schwachstellen rechtzeitig zu erkennen, ist es notwendig, regelmäßige Artefaktprüfungen durchzuführen, auch nach der Bereitstellung einer Anwendung. Dies kann über spezielle Repositories oder Tools erfolgen, wie z , Trivy, GitLab Container Scanning oder die Entwicklung Ihres Integrationsmoduls. Snyk-Container Überwachung der Anwendungssicherheit Eine weitere Möglichkeit, die Sicherheit zu gewährleisten, besteht darin, die Anwendung selbst zu überwachen. Hierfür stehen mehrere Technologien zur Verfügung: Web Application Firewall (WAF) ist ein Tool zur Datenverkehrsfilterung. Es arbeitet auf der Anwendungsebene und schützt Webanwendungen durch die Analyse des HTTP/HTTPS-Verkehrs. RASP (Runtime Application Self-Protection) ist eine Technologie, die Angriffe auf eine Anwendung in Echtzeit erkennt und blockiert. Es fügt der Laufzeitumgebung eine Verteidigungsfunktion hinzu, die es der Anwendung ermöglicht, sich automatisch selbst zu schützen. Der Hauptvorteil von RASP gegenüber WAF besteht darin, dass es versteht, wie die Anwendung funktioniert, und Angriffe sowie unrechtmäßigen Datenverkehr erkennt. Mithilfe des Signaturabgleichs kann RASP nicht nur typische Angriffe erkennen, sondern auch Versuche, Zero-Day-Schwachstellen auszunutzen, indem es auf Anomalien reagiert. Im Gegensatz zu WAF arbeitet RASP innerhalb und mit der Anwendung. WAF kann getäuscht werden. Wenn ein Angreifer den Anwendungscode ändert, kann die WAF dies nicht erkennen, da sie den Ausführungskontext nicht versteht. RASP hat Zugriff auf Diagnoseinformationen über die Anwendung, kann diese analysieren, Anomalien erkennen und Angriffe blockieren. Die Spezialität der RASP-Technologie besteht darin, Angriffe standardmäßig zu verhindern. Das System benötigt keinen Zugriff auf den Quellcode. RASP Narren Ich empfehle dir: Stärken Quadratisch ist eine von Baidu entwickelte Open-Source-Lösung OpenRASP Signalwissenschaften Jscrambler Hdiv Imperva Großartig, weitermachen. Visualisierung der DevSecOps-Pipeline- Ergebnisse und Schwachstellenmanagement In verschiedenen Phasen der Pipeline verwende ich viele Analysegeräte für Anwendungssicherheitstests/DevSecOps. Jeder von ihnen erstellt einen Bericht in seinem eigenen Format, und einige von ihnen generieren sogenannte False Positives. Aus diesem Grund ist es nicht einfach, die Sicherheit einer Anwendung als Ganzes zu analysieren. Um Schwachstellen effektiv zu analysieren und den Behebungsprozess zu verwalten, werden spezielle Vulnerability Management-Tools verwendet, die oft einfach als bezeichnet werden. Security Dashboards Security Dashboards lösen das Problem, indem sie die Ergebnisse von DevSecOps-Analysen in einer einheitlichen und einfach zu analysierenden Form liefern. Auf diese Weise können Sicherheitsingenieure erkennen, welche Probleme vorliegen, welche am kritischsten sind und welche zuerst behoben werden müssen. DevSecOps-Tools Als Security Dashboards kommen in der Regel verschiedenste Tools zum Einsatz: zum Beispiel klassische SOAR/SIEM-Systeme und der spezialisierte DevSecOps-Orchestrator AppSec.Hub von Swordfish Security oder das Open-Source-Schwachstellenmanagement-Toolkit DefectDojo. DefectDojo ist ein weit verbreitetes Tool. Es wird auch in großen Unternehmen häufig eingesetzt. Trotz seiner Beliebtheit und seines soliden Alters weist dieses Tool jedoch gelegentlich einige anfängliche Mängel auf, wenn Mitwirkende die grundlegende Funktionalität im Commit beeinträchtigen. Das Schöne ist jedoch, dass die Entwickler und Betreuer von DefectDojo dabei helfen, die Komplexität zu bewältigen. DefectDojo-Entwickler sind sehr reaktionsschnelle Leute – wir empfehlen, sie direkt über Issues auf GitHub zu kontaktieren. Konzept der Verschiebung nach links: Fassen wir zusammen Hier noch einmal eine kurze Zusammenfassung des Inhalts des Artikels. Ich habe erklärt, was das Shift-Left-Konzept ist und wie es dazu beiträgt, die Kosten für Fehlerbehebungen und die Entwicklungszeit zu reduzieren: Je früher im Entwicklungsprozess Sie mit Sicherheitsüberprüfungen beginnen, desto besser. Dann habe ich die Struktur der DevSecOps-Pipeline dekonstruiert und mir angesehen, welche Sicherheitsüberprüfungen in jeder Phase der Pipeline durchgeführt werden: Vorab festlegen. Dabei wird die Sicherheit des Quellcodes überprüft, bevor dieser in das Versionskontrollsystem gelangt. Vorgefertigt. Es handelt sich um eine Überprüfung der Quellcodesicherheit im Versionskontrollsystem (Secret Detection, SAST, SCA). Nachbau. Es handelt sich um eine Sicherheitsüberprüfung eines aus Quellcode erstellten Artefakts (Source SCA, Binary SCA). Testzeit. Dabei wird die Sicherheit der Anwendung getestet, die mit dem gesammelten Artefakt (DAST, IAST und OAST) ausgeführt wird. Nach der Bereitstellung. Dies beinhaltet die Überprüfung der Anwendungssicherheit nach der Bereitstellung in der Produktionsumgebung (WAF, RASP). Jetzt verstehen Sie, wie die DevSecOps-Pipeline funktioniert. Jetzt können Sie den Reifegrad Ihrer DevSecOps-Pipelines beurteilen, eine Roadmap für deren Entwicklung entwickeln und die richtigen Tools für jede Aufgabe auswählen.