DevSecOps  definiert

Die DevSecOps-Prinzipien und -Praktiken entsprechen denen des traditionellen DevOps mit integrierten und multidisziplinären Teams, die zusammenarbeiten, um eine sichere kontinuierliche Softwarebereitstellung zu ermöglichen. Der DevSecOps-Entwicklungszyklus ist ein sich wiederholender Prozess, der damit beginnt, dass ein Entwickler Code schreibt, ein Build in Gang gesetzt wird, das Softwarepaket in einer Produktionsumgebung bereitgestellt und auf Probleme überwacht wird, die in der Laufzeit identifiziert werden, aber die Sicherheit in jeder dieser Phasen einschließt.

DevSecOps-Best-Practices sollen sicherstellen, dass die Sicherheit ein integraler Bestandteil des Software-Entwicklungszyklus ist. Der Prozess wiederholt sich, wenn neue Funktionen entwickelt und Bugs behoben werden. Um schneller entwickeln und veröffentlichen zu können, sind die Entwickler auf Open Source-Software angewiesen, um ihre Projekte abzuschließen. Die typische moderne Anwendung besteht bis zu 90 Prozent aus Open Source-Software. Dies hat das Potenzial, Folgendes in eine Organisation einzuführen:

  • Sicherheitslücken
  • Probleme mit der Einhaltung von Lizenzen

Berichte von Entwicklern und manuelle Prozesse vermitteln nur ein unvollständiges Bild. Daher sind Sicherheit und Compliance ein wesentlicher Bestandteil des DevSecOps-Prozesses.

 

Das Verhältnis von Entwicklern zu Betriebspersonal und Sicherheitspersonal ist 200:5:1. Das bedeutet, dass jedes Sicherheitsproblem, das von einem Tool zum Scannen von Sicherheitslücken identifiziert wird, von einem sehr kleinen Sicherheitsteam überprüft werden muss, dem möglicherweise sogar die technischen Kenntnisse fehlen. Diese Herausforderung lässt sich verringern, indem man die Verantwortung für Sicherheit und Compliance auf die Entwickler- und Betriebsteams überträgt und die Sicherheit früher in den SDLC-Prozess einbezieht.

Entscheidend ist, dass die Identifizierung von Sicherheitsproblemen früher in der CI/CD-Pipeline erfolgt und die Sicherheits- und Compliance-Richtlinien im Softwareentwicklungszyklus (SDLC) automatisiert werden, anstatt manuelle Prozesse zu verwenden. Darüber hinaus können Unternehmen, die die Sicherheit aus DevOps ausklammern, mit Sicherheits- und Compliance-Problemen konfrontiert werden, die näher an der Veröffentlichung liegen, was zu zusätzlichen Kosten für die Behebung solcher Probleme führt.


Starten Sie mit JFrog Xray KOSTENLOS und überprüfen Sie auf Sicherheitslücken

Start For Free


DevSecOps-Kultur

Eine DevSecOps-Kultur ist eine Kultur, in der jeder die Verantwortung und Haftung für die Sicherheit übernimmt. In Verbindung mit den Best Practices von DevOps sollte jedes Entwicklungsteam einen Sicherheitsbeauftragten benennen, der die Sicherheits- und Compliance-Prozesse und -Maßnahmen im Team leitet, um die Sicherheit der bereitgestellten Software zu maximieren.

Das Wesen von DevOps besteht darin, so viel wie möglich zu automatisieren, um menschliche Fehler zu vermeiden und automatisierte Gates zu schaffen, die verhindern, dass instabiler Code in die Produktion gelangt. Im Grunde ist Code, der Sicherheitslücken oder nicht eingehaltene Lizenzen beinhaltet, instabil.

DevSecOps-Grundsätze

Die Einführung und Umsetzung von DevSecOps in einer Organisation erfordert ein Umdenken in der Unternehmenskultur und im Betriebsablauf. Einschließlich: Sicherheitsschulungen, Tools und Ressourcen. Im Folgenden finden Sie einige nützliche Konzepte für die Veränderung Ihrer Unternehmenskultur.

  • Sicherheits-Champions

    Diese Teammitglieder sind für die allgemeinen Sicherheitsaspekte verantwortlich und stellen sicher, dass diese in der DevOps-Pipeline umgesetzt und anderen Teammitgliedern zugänglich gemacht werden. So leitet beispielsweise ein Sicherheitsbeauftragter des Entwicklungsteams die Einführung und Verwendung von Sicherheitsmaßnahmen im Team:

    • Static Application Security Testing (SAST), um Sicherheitslücken im Quellcode zu entdecken
    • Software Composition Analysis (SCA) für den Einblick in Open Source-Abhängigkeiten.

    Ein Sicherheitsbeauftragter des QA-Teams setzt Folgendes um:

    • Dynamic Application Security Testing (DAST) als Teil von automatisierten QA-Zyklen.

  • Sicherheit als integraler Bestandteil des Prozesses

    DevSecOps-Praktiken erfordern Sicherheit als Teil des SLDC und nicht erst vor der Freigabe der Software für die Produktion. Das bedeutet, dass die Entwickler Sicherheitsscans in den Build-Prozess sowie in ihre IDE-Umgebung integrieren, um anfällige Abhängigkeiten zu erkennen.

  • Leicht zugängliche Daten

    Das Verhältnis von Entwicklern zu Sicherheitsexperten liegt bei 200:1. Durch die Verwendung spezieller IDE-Plugins können Sicherheitsdaten direkt in die von den Entwicklern bereits verwendeten Tools eingespeist werden, was eine einfache Einführung ermöglicht. Führen Sie Best Practices für Entwickler ein, wie beim Schreiben von Codes Sicherheitsprobleme vermieden werden können.

JFrog Xray gibt dem Entwickler Sicherheit an die Hand, indem Informationen über Sicherheitslücken in den im Code verwendeten Abhängigkeiten bereitgestellt werden.

  • Automatisierte Governance

    Zusätzlich zu manuellen Prüfungen, wie z. B. Code-Reviews, können in jeder Phase der DevOps-Pipeline Sicherheitskontrollpunkte verteilt werden, um festzustellen, ob Ihre Software mit der nächsten Phase fortfahren kann. Ein Verwaltungssystem kann die Unternehmensrichtlinien automatisch durchsetzen und ohne Eingreifen entsprechende Maßnahmen ergreifen:

    • Benachrichtigung über Sicherheits- oder Compliance-Verstöße (E-Mail, Slack, Instant Messages, Jira usw.)
    • Blockierung von Downloads
    • Builds fehlschlagen lassen, die abhängig von unsicheren Komponenten sind, oder von solchen, die die Lizenzrichtlinien nicht einhalten
    • Verhinderung des Einsatzes von anfälligen Release-Bundles

JFrog Xray kann in jeden CI-Server integriert werden, um Builds fehlschlagen zu lassen, wenn Sicherheitslücken oder Verletzungen der Open Source-Lizenzkonformität in Build-Artefakten oder Abhängigkeiten gefunden werden.

DevSecOps kann in Ihrer Pipeline automatisiert werden, wodurch eine abstrakte Überlagerung der Sicherheit entsteht.

DevSecOps-Tools

Es gibt mehrere Familien von Sicherheits- und Compliance-Tools, die verschiedene Aspekte des SDLC abdecken. Dazu gehören: Static Code Analysis (SAST), Software Composition Analysis (SCA) und verschiedene Ansätze zur Prüfung des Codes auf Sicherheitslücken (DAST und IAST). Darüber hinaus gibt es Tools, die darauf abzielen, Ihre Binärdateien in Produktionsumgebungen zu überwachen und vor Angriffen zu schützen, die Ihren Code oder Sicherheitslücken in Ihrer Umgebung ausnutzen. Die für die Sicherheit zuständigen Teams sollten es sich idealerweise zum Ziel machen, all diese Methoden einzusetzen, um die Sicherheit des gesamten SDLCs zu gewährleisten.

Statische Anwendungstests (Static Application Security Testing, SAST) können Ihnen helfen, Sicherheitslücken in Ihrem selbst entwickelten Code zu identifizieren. Entwickler sollte sich der Existenz dieser SAST-Tools bewusst sein und sie als automatisierten Teil mit in ihren Entwicklungsprozess einbinden. Auf diese Weise lassen sich potenzielle Sicherheitslücken bereits in einem frühen Stadium des DevOps-Zyklus erkennen und beheben.

DieSoftware Composition Analysis (SCA) umfasst die Verwaltung und Überwachung der Lizenzkonformität und der Sicherheitslücken in den Open Source-Komponenten, von denen Ihr Code abhängt. Es ist wichtig zu wissen, welche OSS-Komponenten verwendet werden und welche Abhängigkeiten bestehen. Nach der Identifizierung der Open-Source Komponenten liefern SCA-Werkzeuge wie JFrog Xray Informationen über Lizenzen und darüber, ob es bekannte Sicherheitslücken im Zusammenhang mit diesen Komponenten gibt. Fortschrittliche SCA-Tools beinhalten Funktionen zur Durchsetzung von Richtlinien, die das Herunterladen von Binärdateien sowie die Erstellung fehlerhafter Builds verhindern und andere Systeme benachrichtigen.

Tools fürdie dynamische und interaktive Prüfung der Anwendungssicherheit (DAST und IAST) testen die offenen Schnittstellen der laufenden Anwendung und suchen nach Sicherheitslücken und Fehlern. Während DAST die Anwendung nur in einer Blackbox überprüft, verwendet IAST eine Technik, die die Funktionen von DAST und SAST kombiniert, um die Genauigkeit der Sicherheitstests für Anwendungen zu erhöhen.

Container Runtime Security -Tools überwachen die Container in ihrer Laufzeitumgebung. Solche Tools bieten verschiedene Möglichkeiten, darunter Firewalls auf verschiedenen Ebenen, die Erkennung von Anomalien auf der Grundlage von Verhaltensanalysen und vieles mehr.

Best Practices für DevSecOps

  • Schulen Sie Entwicklungsteams, um sicheren Code zu entwickeln
  • Verfolgen Sie Sicherheitsprobleme genauso wie Softwareprobleme
  • Sicherheit als Code, eingebaute Sicherheit
  • Integrieren Sie Sicherheitskontrollen in die Software-Entwicklungspipeline
  • Automatisieren Sie Sicherheitstests während des Build-Prozesses
  • Erkennen Sie bekannte Sicherheitslücken in der gesamten Pipeline
  • Überwachen Sie die Sicherheit in der Produktion
  • Schleusen Sie Fehler ein, um die Sicherheit zu erhöhen
    Quelle: The Divine and Felonious Nature of Cyber Security – John Willis @botchagalupe

    The DevOps Handbook, Gene Kim, Patrick Debois, John Willis, Jez Humble

Häufig gestellte Fragen

Was ist Software Composition Analysis?

Die Notwendigkeit der Software Composition Analysis (SCA) ergab sich aus der zunehmenden Verwendung von Open Source-Softwarekomponenten, die von Entwicklern eingesetzt werden, um mit dem Innovationstempo Schritt zu halten. Für Unternehmen war es schwierig, die Nutzung von Open Source in verschiedenen Teams und an verschiedenen Standorten zu verwalten und nachzuverfolgen. Daher benötigten sie eine automatisierte Lösung.

Open Source-Software macht in der Regel 90 % des Codes einer Anwendung aus. Es ist von entscheidender Bedeutung, dass dieser Teil des Codes verwaltet wird und sicher ist.

Zu viele Unternehmen übersehen das Risiko von Open Source-Komponenten und konzentrieren sich nur auf den von ihnen geschriebenen Code. Dies kann zu schwerwiegenden Sicherheits- und Lizenzverletzungen führen, die Unternehmen wie Equifax und Capital One Millionen von Dollar kosten. Eine SCA-Lösung kann das beheben!

SCA umfasst die Verwaltung und Überwachung der Lizenzeinhaltung und der Sicherheitslücken in Open Source-Komponenten. Es ist wichtig zu wissen, welche OSS-Komponenten verwendet werden und welche Abhängigkeiten bestehen. Nach der Identifizierung der OSS-Komponenten in einem Unternehmen bieten SCA-Tools einen Einblick in jede Komponente, einschließlich Informationen über die Lizenz, die Versionsnummer und darüber, ob es bekannte Sicherheitslücken gibt.

Welche Risiken bestehen bei der Verwendung von Open Source-Komponenten?

Moderne Anwendungen bestehen heute zu 90 % aus OSS-Komponenten. Das bedeutet, dass der Großteil der Software, die wir täglich erstellen, einsetzen und nutzen, mit größerer Wahrscheinlichkeit Sicherheitslücken enthält als je zuvor. Da diese Komponenten „offen” sind, haben Hacker eine schnelle und einfache Möglichkeit, Einblick in den Code zu erhalten und dort nach Sicherheitslücken zu suchen. Open Source-Software stellt nicht nur ein Risiko aufgrund von Sicherheitslücken dar, sondern kann auch komplexe Probleme bei der Einhaltung von Lizenzbestimmungen für Unternehmen mit sich bringen. Eine mögliche Komplikation könnte darin bestehen, dass eine Lizenz besagt: „Wenn Sie diese Komponente verwenden, müssen Sie Ihren Code als Open Source zur Verfügung stellen“.

Idealerweise sollten alle OSS-Komponenten so früh wie möglich im Entwicklungsprozess auf Lizenzkonformität und Sicherheitslücken überprüft und diese identifiziert werden. Zu wissen, welche Komponenten man über sein gesamtes Portfolio von Anwendungssoftware verteilt hat und diese nachverfolgen zu können, ist ein absolutes Muss, und sollte am besten automatisiert werden. Dies sollte ein integraler Bestandteil der CI/CD-Pipeline sein, um die Entwicklungs- und Release-Geschwindigkeit auf Kurs zu halten.

In der Vergangenheit war es für die Sicherung des SDLC und der Produktion erforderlich, Agenten zum Scannen von Komponenten einzusetzen. Heute gibt es verschiedene Lösungen, die ein höheres Maß an Sicherheit und Compliance-Überwachung bieten, die direkt in Ihre IDE, Ihren Repository-Manager und Ihre CI/CD-Pipeline integriert sind und sogar Ihre Container-Images scannen können. Um die Sicherheit und die Überwachung der Lizenzeinhaltung von Open Source zu gewährleisten, ist es am besten, mit einer nativ integrierten SCA-Lösung zu arbeiten.

Was bieten SCA-Tools?

Fortschrittliche SCA-Tools bieten Funktionen zur Durchsetzung von Richtlinien und ermöglichen die automatische Überwachung von Open Source-Komponenten. Diese können so konfiguriert werden, dass je nach Kontext des zu überprüfenden Vorgangs unterschiedliche Verhaltensweisen bei festgestellten Sicherheits- oder Compliance-Verstößen möglich sind. Ein Beispiel wäre, dass der Build einer hochsensiblen Anwendungssoftware aufgrund einer Sicherheitslücke fehlschlägt, während der Build einer Testanwendungssoftware mit derselben anfälligen Komponente nicht fehlschlägt. SCA-Tools vergleichen jede Open Source-Komponente Ihres Codes mit Ihren Vorschriften und Richtlinien, um entsprechend unterschiedliche automatisierte Prozesse, die auf dem Ergebnis des Abgleichs basieren, in Gang zu bringen.

Ein SCA-Tool benutzt eine Referenzdatenbank für bereits bekannte Sicherheitslücken und existierende Lizenzen und gleicht diese dann mit den Open Source-Abhängigkeiten Ihrer Anwendungssoftware ab. Je umfassender diese Datenbanken sind, desto geringer ist das Risiko, dass bekannte Sicherheitslücken oder Lizenzierungsprobleme im Produktionscode auftreten.

Was sollte man bei der Entscheidung für ein SCA-Tool in Erwägung ziehen?

Bei der Betrachtung von Tools für die Software Composition Analysis ist es wichtig, Folgendes zu beachten:
1. Technologische Unterstützung: Wie universell ist es und unterstützt es alle in Ihrem Unternehmen verwendeten Programmiersprachen und Pakettypen?
2. Ökosystem-Integration: Das SCA-Tool muss mit Repositories, IDEs, Paketmanagern, CI-Servern usw. integriert werden, und zwar über sofort einsatzbereite Integrationen und über umfangreiche offene APIs.
3. Datenbank: Eine umfassende Datenbank für Sicherheitslücken und Lizenzbestimmungen ist ein Muss, um Sie bestmöglich abzusichern.

Wie unterscheiden sich SCA-Tools von den übrigen Tools für die Sicherheit von Anwendungen?

Ein komplettes Sicherheitspaket sollte aus den folgenden Tools bestehen:
- Dynamic Application Security Testing (DAST)
- Interactive Application Security Testing (IAST)
- Software Composition Analysis (SCA)
- Static Application Security Testing (SAST)

JFrog Xray ist ein SCA-Tool, das sich auf die Erkennung und Beseitigung von Open Source-Sicherheitslücken und Lizenzkonformitätsproblemen in den OSS-Komponenten und Abhängigkeiten konzentriert, auf die Sie sich beim Schreiben Ihres Anwendungscodes stützen. Da die Basis eines Codes bis zu 90 % aus OSS besteht, kann Xray einen großen Einfluss auf die Stabilität und Sicherheit Ihrer Produktionsversionen haben.

Unternehmen, die sich einer solchen Herangehensweise bedienen, erhalten durchweg Verbesserungen ihres SDLCs, wie z. B.: verbesserte Qualität durch frühzeitige Erkennung von Problemen, Transparenz von eigenentwickeltem und Open Source-Code, geringere Kosten für die Behebung von Sicherheitslücken durch frühzeitige Erkennung und Behebung im Entwicklungsprozess, Minimierung des Risikos von Sicherheitsverstößen und optimierte Sicherheitstests.

Welche Risiken bestehen, wenn man sich auf freie CVE/NVD-Datenbanken stützt?

Sie können die beste Integration von SCA-Tools aller Zeiten haben, aber eine Lösung zur Sicherheitsüberprüfung ist nur so gut wie die Datenbank der Sicherheitslücken. Die Verwendung einer Datenbank, die nicht auf dem neuesten Stand der Sicherheitslücken ist, gleicht einem Versuch, jemanden in einer Menschenmenge zu finden, ohne zu wissen, wie er aussieht. Einige Unternehmen betrachten die Verwendung der Common Vulnerability Enumeration (CVE) von MITRE in der National Vulnerability Database (NVD) als den Goldstandard für die Absicherung. Viele Sicherheitsexperten sind der Meinung, dass es nicht mehr ausreicht, sich auf CVE und NVD zu stützen, um Daten über Sicherheitslücken zu erhalten.

So hat beispielsweise Risk Based Security, das für einen der aktuellsten und umfassendsten Sicherheitslücken-Informationsdienste – VulnDB – bekannt ist, jedes Jahr die Gesamtzahl der von CVE und NVD identifizierten und katalogisierten Sicherheitslücken übertroffen. Über 249.155 Sicherheitslücken, die Produkte von 27.676 Anbietern abdecken, einschließlich zehntausender Sicherheitslücken, die nicht in CVE/NVD enthalten sind, was VulnDB zur umfassendsten Lösung auf dem Markt macht. Über 2.000 Bibliotheken von Drittanbietern wurden identifiziert und auf Sicherheitslücken überwacht.

JFrog Xray profitiert von einer engen Integration mit VulnDB, der primären Quelle für Sicherheitslücken- und Lizenzkonformitätsinformationen.

Welche Vorteile hat die Nutzung einer externen Sicherheitsdatenbank wie beispielsweise VulnDB?

Zunächst einmal sind viele Sicherheitsexperten in der Branche der Meinung, dass es nicht mehr ausreicht, sich auf CVE- und NVD-Datenbanken für Sicherheitslückendaten zu verlassen. Es kann lange dauern, bis eine Sicherheitslücke in den CVE/NVD-Datenbanken veröffentlicht wird, und in der Zwischenzeit können hinterlistige Akteure diese Sicherheitslücken analysieren und herausfinden, wie sie sie für bösartige Aktivitäten nutzen können.

Je eher Ihre SCA-Lösung eine Sicherheitslücke in der Datenbank aufweist, desto eher können Sie Ihren Produktionscode gegen diese Sicherheitslücke absichern. Dasselbe gilt für die Überprüfung von Lizenztypen und -versionen. Ihre Compliance- oder Rechtsabteilungen werden über eine Reihe von Richtlinien in Hinblick auf die Verwendung von OSS-Lizenzen verfügen. Mit einer aktuellen Lizenzdatenbank, die Sie überprüfen können, minimieren Sie das Risiko, dass unbeabsichtigte Lizenztypen in Ihrem Produktionscode vorkommen, was teuer und kompliziert sein kann.

Warum ist es nötig, Lizenzen und deren Einhaltung zu überprüfen?

Die Sicherstellung der Lizenzkonformität bei OSS-Abhängigkeiten ist ein wachsendes Anliegen für Compliance-Manager, Rechtsteams und CEOs gleichermaßen. Niemand möchte dafür verantwortlich sein, dass eine Überprüfung fehlgeschlagen ist oder es sogar zu kostspieligen Verfahren aufgrund einer Verletzung des Urheberrechts oder eines Gesetzesverstoßes bezüglich der Lizenzen kommt. Es ist von enormer Bedeutung zu wissen, welche OSS von welchen Entwicklern und in welchen Builds und Releases verwendet wird.

Die Kosten von Sicherheitsverletzungen sind uns allen schmerzlich bewusst. Denken Sie nur an die jüngste Sicherheitslücke bei SolarWinds oder an das berühmt-berüchtigte Equifax-Fiasko, das das Unternehmen Milliarden kostete. Es besteht ein großes Risiko, dass Softwarelizenzen nicht eingehalten werden, was zu einem komplexen und teuren Streit um geistiges Eigentum führen kann. Es ist möglich, dass die Bedingungen bestimmter Lizenzen bedeuten, dass Sie Ihren gesamten Anwendungscode quelloffen machen müssen, wenn Sie deren Code verwenden! Und es gibt gewiss nicht viele CEOs, die darauf erpicht sind, ihre Kronjuwelen zu verschenken. Bei einigen Unternehmen ist dies aufgrund der Art der Software, die mit höherer Wahrscheinlichkeit geprüft wird, mehr der Fall als bei anderen, und je nach Branche kann eine fehlgeschlagene Überprüfung mit einer hohen Geldstrafen geahndet werden.

Überprüfen Sie Ihre Images

Probieren Sie JFrog DevSecOps Tools jetzt aus!
Führen Sie einen KOSTENLOSEN Sicherheitsscan für Ihrer Images durch!

JETZT SCANNEN!