Open-Source-Schwachstellen gemeinsam bekämpfen

Originalbeitrag von Trend Micro Research

Sicherheits- und Entwicklungsteams arbeiteten bislang getrennt in „Silos“. Die Teams sind für unterschiedliche Aspekte der Software in ihrem Unternehmen verantwortlich, und konkurrierende Prioritäten, gepaart mit einer riesigen Kommunikationslücke, haben zu einer kulturellen Kluft geführt. DevOps hat die Aufgabe, Produkte in immer kürzerer Zeit auf den Markt zu bringen, während SecOps mit immer komplexeren Bedrohungen und einer Flut von Warnmeldungen konfrontiert ist. Das Ergebnis? Eine überwältigende Arbeitslast für beide Teams. Obwohl DevOps-Teams wissen zwar um die Bedeutung der Absicherung ihrer Arbeit, dennoch wird Sicherheit häufig erst nachträglich eingefügt. Sicherheits-Workflows und Übersicht nehmen ab, je weiter man sich in der Continuous-Integration- und Continuous-Delivery-Pipeline (CI/CD) nach links bewegt, wodurch es schwieriger wird, Probleme zu identifizieren. Dies ist ein großes Hindernis für SecOps-Teams, denn sie sind für das Cyber-Risiko verantwortlich, und die fehlende Kommunikation und Unübersichtlichkeit wird durch nicht aufeinander abgestimmtes Tooling auf beiden Seiten nur noch verschlimmert. Abhilfe für diese Situation schafft nur Sicherheit die bereits ins Design eingebettet ist (Security by Design).

Im modernen Anwendungscode überwiegt Open-Source-Code. Insbesondere entsprechende Komponenten von Drittanbietern können die Markteinführung beschleunigen und die Entwicklungskosten senken, weil der Code nicht von Grund auf neu zu schreiben ist. Aber diese Komponenten sind auch die Quelle wachsender Cyber-Risiken innerhalb des Unternehmens. In dem Maße, in dem Entwickler ihre Nutzung von Open-Source-Bibliotheken ausweiten, hat sich auch die Angriffsfläche vergrößert. Sicherheitsteams bekommen dies häufig nicht mit, da die DevOps-Teams die Anwendungen schnell erstellen und starten.

Unternehmen sind einem erheblichen Sicherheitsrisiko ausgesetzt, denn Schwachstellen im Open-Source-Bereich haben in den letzten drei Jahren um 250 % zugenommen, so eine Studie von Snyk. Hinzu kommt, dass 70 % dieser Schwachstellen durch indirekte Abhängigkeiten entstehen, und das macht es noch schwieriger, sie zu identifizieren und zu schließen. Da bei der Erstellung der meisten Anwendungen mehrere Open-Source-Bibliotheken genutzt werden, erhöht sich das Risiko durch zu wenig Übersicht in den komplexen Komponenteninventaren. Um das potenzielle Risiko zu mindern, benötigen SecOps-Teams einen besseren Einblick in dieses unbekannte und weitläufige Ökosystem.

Etwa 80 % des heutigen Entwicklungscodes ist Open Source, und deshalb ist Transparenz für Sicherheitsteams von entscheidender Bedeutung bei der Absicherung der Applikationen. Sicherheitsteams benötigen eine Lösung, mit der sie nicht nur Schwachstellen identifizieren, sondern diese auch in einer gemeinsamen Sprache kommunizieren können, die es DevOps-Teams einfach macht, Bugs zu beheben, ohne dass es zu Verzögerungen oder Reibungsverlusten kommt.

Lösung

Trend Micro Cloud One – Open Source Security by Snyk geht die Open-Source-Sicherheit von der „rechten“ Seite der CI/CD-Pipeline an und bettet den Schutz so früh wie möglich in den Entwicklungsprozess ein. Durch die Nutzung von Snyks spezieller Forschung und Expertise zu Open-Source-Schwachstellen erhalten SecOps-Teams einen kontinuierlichen Einblick in bekannte Risiken im Entwicklungs-Ökosystem ihrer Organisation und deren Projekte. Durch die automatisierte Priorisierung kritischer Probleme, einschließlich von Schwachstellen und Exploit-„Maturity Scores“, lassen sich Risiken überwachen und verfolgen, ohne die Arbeit der DevOps-Teams zu beeinträchtigen. Dazu gehört auch das Verständnis, wie komplexe Abhängigkeitspfade und Schwachstellen eingeführt wurden, indem die reichhaltigen bereinigten Informationen und spezifische, leicht verständliche Details zu jeder aufgedeckten Schwachstelle untersucht werden. Der gleiche Einblick in versteckte Abhängigkeiten kann Unternehmen auch helfen, Lizenzierungsrisiken projektübergreifend besser zu verwalten.

Letztendlich ermöglicht dies, auch die Kommunikationslücke zwischen DevOps und SecOps zu schließen, weil eine gemeinsame Sprache geschaffen werden kann.

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.