Zu den DevOps-Prinzipien und -Verfahren gehören integrierte und fachübergreifende Teams, deren Zusammenarbeit die Continuous Software Delivery ermöglicht.

Um Software schneller entwickeln und veröffentlichen zu können, fügen Entwickler regelmäßig Open-Source-Komponente in ihre Projekte ein. Geschätzt sind heutzutage 60 bis 90 % eines Codes Open Source. Dies kann für das Unternehmen Folgendes bewirken: Erstens Sicherheitsschwachstellen und auch Probleme mit der Lizenzeinhaltung. Berichte von Entwicklern und manuelle Prozesse vermitteln nur ein unvollständiges Bild. Daher stellen die Sicherheit und die Überprüfung der Lizenzeinhaltung einen unerlässlichen Teil des DevOps-Prozesses dar.

Der Software-Entwicklungszyklus (SDLC) ist ein sich ständig wiederholender Prozess, der mit dem Schreiben eines Codes durch den Entwickler beginnt, gefolgt von einem Build, der in Gang gesetzt wird, der Bereitstellung eines Software-Pakets innerhalb einer Produktionsumgebung, und die anschließende Überwachung, um Probleme während der Laufzeit der Software zu identifizieren. Der Prozess wird fortgesetzt, indem neue Features entwickelt und Bugs behoben werden. Die Sicherheit sollte in jeder Phase der Entwicklung überprüft werden.

Das Verhältnis von Entwicklern zu Betriebspersonal und Sicherheitspersonal ist 200:5:1. Das bedeutet, dass jedes von einem Tool zur Überprüfung auf Sicherheitslücken identifizierte Problem von einem sehr kleinen Sicherheits-Team überprüft werden muss, dem gegebenenfalls sogar das technische Hintergrundwissen dazu fehlt. Diese Herausforderung lässt sich bewältigen, indem man die Verantwortung für Sicherheit und Einhaltung der Lizenzbestimmungen auf die Entwickler- und Operations Teams überträgt und dies 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 das Sec aus DevOps auslassen, mit Sicherheits- und Lizensierungsproblemen konfrontiert werden, die so nah an der Veröffentlichung ihrer Software liegen, dass es zu zusätzlichen Kosten für die Behebung solcher Probleme kommt.


Jetzt KOSTENLOS mit JFrog Xray loslegen und nach Sicherheitslücken suchen

Nehmen Sie die Xray-Herausforderung an


DevSecOps-Kultur

Im Rahmen einer DevSecOps-Kultur übernimmt jeder Einzelne die Verantwortung und das Eigentum an der Sicherheit. In Verbindung mit den Best Practices von DevOps sollte jedes Entwickler-Team einen Sicherheitsbeauftragten benennen, der die Prozesse für die Sicherheit und die Einhaltung von Lizenzbestimmungen und diesbezügliche Aktionen im Team leitet, um die Sicherheit der gelieferten 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-Prinzipien

Die Einführung und Umsetzung von DevSecOps in einer Organisation erfordert ein Umdenken in der Unternehmenskultur und im Betriebsablauf. Dies umfasst Tools, Ressourcen und Training bezüglich der Sicherheit. Im Folgenden finden Sie einige nützliche Konzepte für die Veränderung Ihrer Unternehmenskultur.

  • Sicherheitsbeauftragte

    Diese Teammitglieder sind für die allgemeinen Sicherheitsaspekte verantwortlich und sorgen dafür, dass diese umgesetzt und den anderen Teamkollegen zugänglich gemacht werden. So wird beispielsweise ein Sicherheitsbeauftragter des Entwicklungsteams die Einführung und Verwendung von Sicherheitsmaßnahmen im Team leiten:

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

    Ein Sicherheitsbeauftragter des QA-Teams setzt Folgendes um:

    • Dynamic Application Security Testing (DAST) als Teil eines automatisierten Ablaufs für die Qualitätssicherung.

  • Sicherheit als wesentlicher Bestandteil des Prozesses

    DevSecOps-Praktiken erfordern Sicherheit als Teil des SLDC und nicht erst vor der Freigabe der Software für die Produktion. Dies bedeutet, dass Entwickler die Überprüfung auf Sicherheitslücken sowohl in den Build-Prozess als auch in ihre IDE-Umgebung integrieren, um anfällige Abhängigkeiten ausfindig zu machen.

  • Einfacher Datenzugriff

    Das Verhältnis von Entwicklern zu Sicherheitsexperten liegt bei 200:1. Durch die Verwendung spezieller IDE-Plug-ins können Sicherheitsdaten direkt in die von den Entwicklern bereits verwendeten Tools eingespeist werden, was eine einfache Einführung ermöglicht. Sie sollten den Entwicklern bewährte Verfahren vorstellen, wie sie beim Schreiben ihres Codes Sicherheitsprobleme vermeiden können.

JFrog Xray gibt dem Entwickler durch die Bereitstellung von Informationen über Sicherheitslücken in den im Code verwendeten Abhängigkeiten Sicherheit an die Hand.

  • Automatisierte Steuerung

    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, 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 Verstöße gegen Open-Source-Lizenzen in irgendeinem der Artefakte oder der Abhängigkeiten dieses Builds gefunden werden.

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

DevSecOps Tools

Es gibt diverse Arten von Tools zur Überprüfung der Sicherheit und Lizenzeinhaltung, die verschiedene Aspekte des SDLCs abdecken. Diese umfassen Folgende: Static Code Analysis (SAST), Software Composition Analysis (SCA) sowie verschiedene Ansätze für das Testen des Codes auf Sicherheitslücken (DAST und IAST). Darüber hinaus gibt es Tools, mit denen Sie Ihre Binärdateien in Produktionsumgebungen überwachen und vor Angriffen schützen können, die Ihren Code oder Schwachstellen 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.

Static Application Security Testing (SAST) Tools können dabei behilflich sein, Sicherheitslücken in Ihrem selbstentwickelten Quellcode zu identifizieren. Entwickler sollte sich der Existenz dieser SAST-Tools bewusst sein und sie als automatisierten Teil mit in ihren Entwicklungsprozess einbinden. Dies hilft schon früh im DevOps-Arbeitsablauf beim Erfassen und Beheben potentieller Sicherheitslücken. Es gibt viele Static Analysis Tools, wie zum Beispiel SonarQube und Veracode.

Die Software Composition Analysis (SCA) umfasst die Verwaltung und Überwachung der Lizenzkonformität und der Sicherheitsschwachstellen 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 bieten Funktionen zur Durchsetzung von Richtlinien, die das Herunterladen von Binärdateien, fehlerhafte Builds und die Benachrichtigung anderer Systeme verhindern.

Dynamic and Interactive Application Security Testing (DAST und IAST) Tools 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. Einige IAST-Tools sind zum Beispiel Synopsys, Checkmarx und Contrast Security.

Container Runtime Security Tools überwachen die Container in deren Laufzeitumgebung. Solche Tools verfügen über verschiedene Funktionen, einschließlich des Firewallings auf verschiedenen Ebenen, der Identifizierung von Anomalien basierend auf Verhaltensanalysen und mehr. Beispiele für Tools zum Schutz während der Laufzeit sind Twistlock (Prisma Cloud Native Security), AquaSec, NeuVector und Rezilion.

Best Practices für DevSecOps

  • Die Schulung von Entwicklerteams zur Entwicklung eines sicheren Codes
  • Sicherheits- und Softwareprobleme gleichermaßen nachverfolgen
  • Sicherheit in Form eines Codes (Integrierte Sicherheit)
  • Die Integration von Sicherheitskontrollen in die Software-Pipelines
  • Automatisierung der Sicherheitstests im Build-Prozess
  • Das Aufspüren bekannter Sicherheitslücken während der Pipeline
  • Die Sicherheitsüberwachung in der Produktion bekannter Phasen
  • Das Einfügen von Fehlern, um die Sicherheit zu erhöhen
    Quelle: The Divine and Felonious Nature of Cyber Security – John Willis @botchagalupe

    Das DevOps-Handbuch (The DevOps Handbook), Gene Kim, Patrick Debois, John Willis, Jez Humble

FAQ

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-Code macht schätzungsweise 60-90 % des Codes einer Anwendung aus. Es ist daher wichtig, dass dieser Teil des Codes verwaltet und gesichert wird.

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 solche Probleme verhindern!

SCA umfasst die Verwaltung und Überwachung der Einhaltung von Lizenzen 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 Schwachstellen 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 durch Schwachstellen 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 Schwachstellen ü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 Ihrer CI/CD-Pipeline sein, um Ihre Entwicklungs- und Veröffentlichungsgeschwindigkeit 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?

Auf der Suche nach einem geeigneten Software Composition Analysis Tool, ist es wichtig Folgendes zu beachten:
1. Technologische Unterstützung: Wie universell einsetzbar ist das Tool und unterstützt es alle Programmiersprachen und Pakettypen, die in Ihrem Unternehmen eingesetzt werden?
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?

Ihr Sicherheitspaket sollte aus folgenden Tools bestehen:
- Dynamic Application Security Testing (DAST)
- Interactive Application Security Testing (IAST)
- Software Composition Analysis (SCA)
- Static Application Security Testing (SAST)
Dynamic Application Security Testing (DAST) Tools stellen eine Sicherheitstechnologie für Webanwendungen bereit, die Sicherheitslücken identifiziert, indem sie beobachtet, wie Anwendungssoftware auf speziell gefertigte Anfragen reagiert, die Sicherheitsangriffe imitieren. DAST Tools sind auch als „web scanner“ bekannt. Die OWASP-Organisation bezeichnet sie als „web application vulnerability scanner“ (Scanner für Sicherheitslücken in Webanwendungen).

Aus methodischer Sicht versucht DAST, die Arbeit eines menschlichen Pentesters (Penetrationstester), der die Anwendungen eingehend untersucht, nachzuahmen. Dies kann manchmal hilfreich sein, aber wenn Sicherheit und Geschwindigkeit für das System wichtig sind, stößt die DAST-Technologie an ihre Grenzen.

Static Code Analysis oder Static Application Security Testing (SAST) Tools (z. B. SonarQube) helfen dabei, Sicherheitslücken in Ihrem eigenen, selbst entwickelten Quellcode zu identifizieren. Sie sind jedoch nicht dazu in der Lage, Sicherheitslücken oder Probleme bezüglich der Lizenzen in den zusätzlich verwendeten Open-Source-Komponenten ausfindig zu machen. Static Code Analysis hilft Ihnen jedoch dabei, komplizierte Bugs innerhalb des eigenen Quellcodes zu finden, und verhindert so, dass diese Probleme in der Anwendung beim Endbenutzer bereiten. SonarQube verfügt auch über Funktionen, die erklären, warum der Code anfällig ist, und Empfehlungen für die nächsten Schritte geben.

IAST-Tools (Interactive Application Security Testing) verwenden Software-Instrumente, um die Leistung einer Anwendung zu bewerten und Schwachstellen zu erkennen. IAST verfolgt einen „agentenähnlichen“ Ansatz, d. h. Agenten und Sensoren werden eingesetzt, um die Funktionsweise der Anwendung während automatisierter Tests, manueller Tests oder einer Mischung aus beidem kontinuierlich zu analysieren.

Der Hauptunterschied von IAST zu sowohl SAST als auch DAST ist, dass es die gesamte Anwendung überprüft. Durch den Zugriff auf ein so breites Spektrum an Daten wird die IAST-Abdeckung im Vergleich zu Quellcode- oder HTTP-Scans vergrößert, und es werden genauere Ergebnisse ermöglicht.

JFrog Xray ist ein SCA-Tool, das sich auf die Erkennung und Beseitigung von Sicherheitslücken und Problemen bezüglich der Lizenzeinhaltung innerhalb der Open-Source-Softwarekomponenten und -Abhängigkeiten konzentriert, auf die Sie sich während des Schreibens Ihres Anwendungscodes verlassen. 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 Schwachstellen durch frühzeitige Erkennung und Behebung im Entwicklungsprozess, Minimierung des Risikos von Sicherheitsverstößen und optimierte Sicherheitstests.

Welche Risiken birgt es, sich auf kostenlose Datenbanken wie beispielsweise CVE/NVD zu verlassen?

Sie können die besten SCA-Tools aller Zeiten integriert haben, aber selbst die beste Sicherheitslösung ist nur so gut wie die Datenbank, auf die sie zugreifen kann. Die Verwendung einer Datenbank, die nicht auf dem neuesten Stand der Sicherheitslücken ist, ist wie der 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, nur über CVE und NVD Daten über Sicherheitslücken zu erhalten.

So hat beispielsweise Risk Based Security, das für einen der aktuellsten und umfassendsten Schwachstellen-Informationsdienste – VulnDB – bekannt ist, jedes Jahr die Gesamtzahl der von CVE und NVD identifizierten und katalogisierten Schwachstellen übertroffen. Über 249.155 Schwachstellen, die Produkte von 27.676 Anbietern abdecken, einschließlich zehntausender Schwachstellen, 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, welches die primäre Quelle für Informationen zu Sicherheitslücken und Lizenzen darstellt.

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 Schwachstellendaten zu verlassen. Es kann lange dauern, bis eine Sicherheitslücke in den CVE/NVD-Datenbanken veröffentlicht wird. In der Zwischenzeit können bösartige Akteure diese Sicherheitslücken jedoch analysieren und herausfinden, wie sie diese in schädlicher Weise ausnutzen können.

Je früher die von Ihnen eingesetzte SCA-Lösung Informationen zu einer Sicherheitslücke in der Datenbank hat, desto früher können sie ihren Produktionscode davor bewahren, diese Sicherheitslücke in sich zu tragen. Das gleiche 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. Eine aktuelle Lizenzdatenbank für einen Abgleich verfügbar zu haben, minimiert das Risiko, ungewollte Lizenztypen im Produktionscode zu haben, die sehr kostspielig und kompliziert zu handhaben sein könnten.

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

Die Einhaltung von Lizenzen für OSS-Abhängigkeiten sicherzustellen, ist gleichermaßen sowohl für die Compliance-Manager als auch für die Rechtsabteilungen und CEOs ein zunehmendes Problem. 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.

Loslegen

Jetzt JFrog DevSecOps Tools ausprobieren!
Installieren Sie eine kostenlose Testversion – lokal oder in der Cloud.

Kostenlos starten