Is your security team drowning in "critical" alerts that aren't actually exploitable?

🌊🧘‍♂️ Most teams treat dependency risk as a periodic task, but our webinar on April 8 shows you how to make it continuous.

We'll explore how #DependencyTrack uses #EPSS and #VEX to filter out the noise and prioritize the 10% of vulnerabilities that actually pose a threat to your production environment.

🔗 https://www.amazee.io/blog/post/live-uncover-hidden-vulnerabilities-with-dependency-track

I've got a questions about working with the tools provided by #OWASP.

When working within the #Java and #Maven build environments to use both the dependency-check plugin as well as the DependencyTrack application? I do know that the #DependencyTrack uses the #CycloneDX plugin to generate the BOM. What I'm trying to prevent is extra build time used up to perform similar operations.

CVEs reported without version, and/or never updated to limit their CPEs to exclude versions where the vulnerability is fixed;

and now I get false positives every single time I update that dependency 😭

(in this case, specifically, Keycloak's CVE-2020-1717, CVE-2022-1438 and CVE-2023-0105, both still reported on version 22.0.4 by Dependency Track; the GitHub Advisories have the accurate information, but not the NVD 😡)

#DependencyTrack #cve #keycloak #security #vulnerability

Google Publishes a Tutorial on How To Deploy #OWASP #DependencyTrack Platform to Google Cloud:

#SupplyChainSecurity
#OpenSource
#SBOM

https://cloud.google.com/community/tutorials/deploy-dependency-track

Christmas time reminds me of last years Log4j-incident. If you were one of the people involved in either finding, fixing or mitigating the vulnerability during the hectic weekend a year ago, the linked blog post is especially for you.

In this blog, I'll outline you how we at SOK are dealing with our supply chain security and third party software components. I'll give an overview of our reasons for collecting SBOMs beyond the preparation for a log4j-level incident. I'll also touch on subjects as strategies, CI/CD integration, SBOM formats and reporting.

https://www.linkedin.com/pulse/why-how-sboms-sok-miso-lith

#DependencyTrack #Appsec #SBOM #cybersecurity #infosec #security #devops #supplychain #supplychainsecurity

Umso größer Entwicklungsprojekte sind, umso mehr Abhängigkeiten bestehen. Alle Abhängigkeiten im Überblick zu behalten ist teilweise schon eine Herausforderung, ganz zu schweigen, von der allzu oft durchgeführten wahllosen Einbindung ohne Check der Lizenzen, Vulnerabilities etc. im Vorfeld. Aber wie bekommt man diese Themen alle in den Griff?

Die meisten Paketmanager etc. bieten mittlerweile entsprechende Features an. Mit dotnet list package --vulnerable erfolgt beispielsweise im .NET-Umfeld eine Auflistung aller vulnerablen Pakete. Mit npm audit kann eine derartige Liste mit NPM herausgefahren werden.

Diesen Varianten ist aber gemein, dass sie den Status zum Aufrufzeitpunkt abbilden. Nicht mehr und nicht weniger. Und möglicherweise möchte man etwas mehr:

• Tracking der Abhängigkeiten über Versionen der eigenen Software hinweg
• Übersicht aller Lizenzen der Abhängigkeiten
• Auflistung und Risikobewertung aller Schwachstellen pro Version der eigenen Software
• Möglichkeit, Schwachstellen zu auditieren und Entscheidungen zu dokumentieren
• Automatische Aktualisierung/Auswertung durch Integration ins Build-System

Das Open Web Application Security Project (kurz OWASP) ist vielen vielleicht ein Begriff, bringt die Foundation doch regelmäßig die Top 10 Web Application Security Risks heraus. Diese sollten in der Webentwicklung auf jeden Fall neben den Secure Coding Practices [PDF] und dem Web Security Testing Guide im Auge behalten werden.

Mit Dependency-Track stellt OWASP ein Tool zur Verfügung, in welches mittels einer CycloneDX-BOM (Bill of Material) Listen von Abhängigkeiten importiert und gegen Vulnerability Datenbanken geprüft werden. Hierfür stehen VulnDB, GitHub Advisories und zahlreiche weitere Quellen zur Verfügung.

Für die Generierung der notwendigen BOM stehen zahlreiche Tools für unterschiedliche Entwicklungsplattformen zur Verfügung. Somit ist eine einfache Einbindung in die Buildumgebung problemlos zu machen.

Die Installation von Dependency-Track gestaltet sich denkbar einfach, da die Auslieferung unter anderem als Docker-Container erfolgt.

Nachfolgend einige Screenshots des Herstellers.

Zudem steht ein übersichtliches Dashboard für einen Überblick über die gesamte Softwareinfrastruktur und einer Bewertung des aktuellen Risikos bereit.

Dependency-Track steht auf GitHub zur Verfügung und bereichert die Entwicklungsumgebung kostenlos.

Der bloße Einsatz dieses Tools bringt keine Verbesserung der Situation. Vielmehr muss es einen klaren Verantwortlichen geben, der zum Einen ein Abhängigkeitsmanagement betreibt (Wildwuchs eingrenzen, Überblick, Lizenzen) und zum anderen ein Audit über gefundene Risiken durchführt und deren Behebung (Aktualisierung der Abhängigkeit, Austausch etc.) einleitet.

Umso zentraler dieses Thema im Entwicklungsprozess behandelt wird, umso besser und schneller kann auf Schwachstellen reagiert werden.

#dependencytrack #security #vulnerability

https://norberteder.com/abhaengigkeiten-und-vulnerabilities-im-griff/