Free Known Vulnerability Search - TrustSource Vulnerability Lake bietet vielfältige Unterstützung bei der Suche nach Bekannten Schwachstellen
TrustSource Vulnerability Lake Search
Sowohl Software-Entwickler als auch Security-Researcher kennen die Herausforderung, Bekannte Schwachstelle Open Source Komponenten zuzuordnen. Die CPE (Common Platform Enumeration) codes stellen zwar ein standardisiertes Schema für die Bezeichnung von Schwachstellen zur Verfügung, jedoch wurde die Nomenklatur ursprünglich für Hersteller-Software entwickelt und passt nur leidlich auf den Kontext von Open Source Komponenten, denen oft eine eindeutige „Organisation“ fehlt.
Das führt zu Problemen in der Auffindbarkeit und bei der korrekten Zuordnung. Einmal gewinnt der Projektname, z.Bsp. „kubernetes:kubernetes“ ein anderes Mal ist es die organisierende Foundation, bspw.: „apache:http„. Manchmal gehen die Projekte auch im Laufe der Zeit durch unterschiedliche Organisationen, wie das weitverbreitete Spring-Framework. Dann finden sich Informationen unter „pivotal_software:spring_framework“ und ab 2019 unter „vmware:spring_framework„, was aufgrund der Nebenläufigkeit von Versionen noch auf Jahre viel Irritationen mit sich bringen wird.
Und, um noch eines drauf zu setzen, dann gibt es ja noch die Herausforderungen mit den Projektnamen selbst: „npmjs“ oder lieber „npm_js“ oder doch „npmjs:npm„?
Die TrustSource Vulnerability Lake-Search dreht den Spieß um: Sie stellt Suchoptionen zur Verfügung, um in den vorhandenen CPEs zu suchen und somit die zu beachtenden Keys zu finden.
Mit Hilfe von TrustSource Vulnerability Alert kann ich meine kritischen Komponenten im Schlaf überwachen!!
TrustSource Vulnerability Alert
Mit Hilfe des TrustSource Vulnerability Alerts bleiben Sie stets auf dem Laufenden. Die mit der oben beschriebenen Suche gefundenen Bezeichner lassen sich abonnieren. Registrierte Benutzer – die Registrierung ist kostenfrei und einfach bspw. per GitHub-Account möglich – können die Begriffe auf eine Liste setzen. Diese Listen werden alle paar Stunden mit den Updates aus aktualisierten Quellen, wie der NVD abgeglichen. Finden sich Updates oder neue Einträge erhält der Abonnent eine eMail mit einem Link auf die neuen Informationen.
TrustSource Kunden erhalten diese Funktionalität automatisch auf alle in den Software Bill of Materials (SBOMs) ihrer Lösung(en) angewendet. Die TrustSource-Scanner ermitteln die SBOMs während Ihre Anwendung gebaut wird und kennen daher alle Abhängigkeiten, auch die transitiven. Zudem können Sie in TrustSource selbst auch Infrastrukturkomponenten dem Projekt hinzufügen, und somit die gefährdeten Libraries, die nicht im eigenen Quellcode vorkommen, identifizieren.
Die Kommunikation der Vulnerability Alerts kann entweder per Mail an die entsprechenden Projektteilnehmer oder in die systemeigene Inbox erfolgen. Letzteres ist insbesondere erforderlich, um Fehlschläge aufgrund von Abwesenheiten oder anderen Filtern asynchroner Kommunikation zu entgehen.
Um die einfache Integration in umstehende Systeme zu ermöglichen, stehen alle diese Funktionen auch via API zur Verfügung. Die Nutzung des API ist jedoch kostenpflichtig und nicht Bestandteil der freien Pläne.
Um eine schnelle Einordnung der Kritikalität zu ermöglichen, zeigt TrustSource stets neben der Beschreibung der CVE bzw., deren Zuordnung zu den OS-Komponenten auch die Informationen zu dem Angriffsvektor sowie die Kritikalität in CVSS-Werten (Common Vulnerability Scoring System, Details s. hier ).
TrustSource Life Cycle Alarm
Aus diesen Fähigkeiten ergibt sich noch eine weitere Leistung, die TrustSource seinen Kunden zu Verfügung stellt: Den Life-Cycle-Alarm.
Die Verpflichtung eines Software-Herstellers seine Kunden über Bekannte Schwachstellen zu informieren, endet nicht mit der Auslieferung der Software, sie beginnt zumeist erst dann. Das gilt für Gerätehersteller noch mehr. Je weniger Möglichkeit besteht, den Kunden für zeitnahe Updates zu , motivieren, desto komplexer wird die Situation.
Tauchen im Laufe der Zeit _nach_ der Veröffentlichung der Software, Bekannte Schwachstellen in den verwendeten Komponenten auf, ist es im Sinne ordnungsgemäßer Informationsversorgung an dem Hersteller, seine Kunden zu informieren. Diese Verpflichtung findet bereits im Bereich der Medizinprodukte (MDR) Anwendung und wird sich sicherlich auch auf weitere Bereiche ausdehnen.
TrustSource erlaubt es, SBOMs, die zu einem Release freigegeben wurden, festzuhalten und somit einer fortlaufenden Kontrolle zu unterziehen. JederPatch oder Release-Stand, der auf einem Kundenprodukt erzeugt wurde, lässt sich nachhalten und entsprechend alarmieren.
Es klingt interessant aber Sie sind sich nicht sicher, ob es Ihrem Bedarf entspricht?
Oder wollen Sie sich lieber erst einmal selbst durch einen kostenfreien Test Einblick verschaffen?
Alles neu macht der Mai - TrustSource 2.0 kommt!
TrustSource 2.0 kommt mit neuem Look & Feel
Wir freuen uns, am Freitag, den 7.5.2021 die Version 2.0 in Betrieb zu nehmen. Da es über die letzten Updates etwas voll geworden ist, in der Liste der Features, haben wir den Navigationsbereich in Gruppen zusammengefasst. Diese sind nach den Phasen der Wertschöpfung organisiert, was hilft, sich schneller zu orientieren: Analysen im Bereich Inbound, Schwachstellen-Informationen und Projektmanagement-Aufgaben im Internal-Bereich oder Notice-File-Generierung im Outbound-Bereich.
Mehr Fokus bei der Arbeit
Weiterhin helfen wir unseren Kunden sich zu fokussieren. Gerade in größeren Organisationen mit umfangreichem Projektportfolio wird es wichtig, sich schnell und gezielt zu bewegen. Mit Hilfe der „Pin to Dashboard„-Funktion lassen sich Projekte direkt auf das Dashboard heften, sodass ein direkter Einstieg mit wenigen Klicks möglich wird. Ebenfalls in dieses Segment fällt die Möglichkeit, Projekte und Module mit Tags zu versehen. Tabellenansichten lassen sich mit Hilfe von Tags filtern, was schnell für mehr Sichtbarkeit sorgt. In späteren Ausbaustufen, werden die Tags auch in den Berichten und anderen Übersichten nutzbar sein.
Neues Import-API für CycloneDX SBOMs
Auch haben wir den Entwicklungen am Markt Rechnung getragen und den sich immer schneller etablierenden Standard CycloneDX aufgenommen. Es ist nun möglich, CycloneDX-Dokumente zu importieren. Somit sind auch alle CycloneDX-kompatiblen Scanner für die Arbeit mit TrustSource nutzbar. Die Dokumente müssen nur an das neue API /import/scan/cyclonedx übertragen werden.
Vulnerability Lake
Um unseren Benutzern die tägliche Arbeit zu vereinfachen, haben wir eine vollständige Replik der NVD-Daten aufgenommen. Alle zwei Stunden aktualisiert, können Sie nun die CVEs durchsuchen, nach Organisation, Produkt und Versionen (CPEs) recherchieren – aus TrustSource heraus oder über unsere API. Es ist unser Ziel, den Datenpool sukzessive zu vergrößern und dieses wertvolle Wissen auf Knopfdruck verfügbar zu machen. Derzeit arbeiten wir an einem Matching der CPEs auf pURLs, um die Identifikation von CVEs zu betroffenen Komponenten zu optimieren.
Verbesserungen
Darüber hinaus werden wir auch eine Reihe von Verbesserungen einführen
- Es wird nun möglich sein, zwischen dem Scan – den Rohdaten, die von einem beliebigen Scanner oder dem CycloneDX SBOM-Upload in TrustSource eingebracht werden – und der analysierten Abhängigkeitsansicht hin und her zu springen. Dies wird helfen, die Abhängigkeitshierarchie besser zu verstehen.
- Wir haben die Geschwindigkeit beim Laden des Analyse-Auswahlelementes verbessert. Täglich gescannte, aber lange Zeit geänderte Projekte neigten dazu, eine erhebliche starke Latenz zu erzeugen.
- DeepLinks aus der DeepScan-Ergebnisansicht in das Repository werden nun auch für spezifische branches unterstützt
- Die Light-Integration via eMail zu on-premises Jira-Systemen wird nun unterstützt. Die Option lässt sich projektspezifisch konfigurieren.
Fehlerbehebungen
Die folgenden Fixes werden zur Verfügung gestellt:
- Das Löschen von Lizenz-Alias in einer nicht sequentiellen Reihenfolge erzeugt keine leeren Aliase mehr
- Verhinderung eines internen Fehlers, wenn Modul- oder Komponentennamen bei Scans ungewöhnlich lang waren
- Die Datumsdarstellung in Safari funktionierte manchmal nicht korrekt
- Einige Anpassungen an den Komponenten-Crawlern und der Speicherung der Ergebnisse reduzieren die Menge der fehlerhaften Daten
Sie wollen mehr über SBOMs oder OpenSSF Coding Best Practises erfahren? Kontaktieren Sie uns!
TrustSource mit Vulnerability Lake (beta)
Vulnerability Lake ergänzt das TrustSource Angebot
Aufgrund vieler Anfragen haben wir uns entschlossen, unsere interne Schwachstellen-DB für unsere Kunden zu öffnen. Ab der Version 2.0 wird TrustSource seine interne „Known Vulnerability“-Datenbank für die Suche zur Verfügung stellen. Es werden mehrere Suchmöglichkeiten zur Verfügung stehen:
- TrustSource Vulnerability-Lake öffentliches Web-UI
eine öffentliche, kostenlose Suche über unsere Schwachstellendaten für die manuelle Nutzung. Zudem wird es möglich sein, sich für bis zu fünf Produkte zu registrieren, um Updates direkt in den eigenen Posteingang zu erhalten. - TrustSource Vulnerability-Lake Web-UI
eine in die TrustSource-Lösung integrierte Such-UI für unsere registrierten Benutzer - TrustSource Vulnerability-Lake API
eine API, die die Such- und Abgleichsfunktionen auch für die programmatische Nutzung bereitstellt. Eine bestimmte Anzahl von Transaktionen pro Monat wird kostenlos sein. Die API wird auch einige statistische Informationen zur besseren Interpretation der Schwachstellendaten bereitstellen.
Die öffentliche Web-Benutzeroberfläche sowie die in TrustSource integrierte Web-Benutzeroberfläche werden einen einfachen und einen Experten-Suchmodus bieten. Im einfachen Modus können Sie eine Produktinformation angeben und die Suche nach Organisation oder Version erweitern. In der professionellen Version kann dies in einem einzigen String kodiert werden, z.B. ’some-org:my-product:3.2.1′ Die Ergebnisse enthalten die typischen Informationen wie CVSS Base Score, CVE-ID, Beschreibung und weiterführende Links.
Die Daten werden alle zwei Stunden aktualisiert. Im ersten Anlauf wird die Lösung nur NVD-Daten enthalten. Später werden wir den Umfang dort erweitern, wo es sinnvoll ist. In den letzten Jahren haben wir eine steigende Verbreitung von CNAs – den Stellen, die CVEs vergeben – beobachtet. Das reduziert die Dringlichkeit, viele verschiedene Quellen zu verarbeiten. Abhängig von Ihrem Anwendungsfall kann es aber dennoch sinnvoll sein, weitere Quellen einzubeziehen. Zögern Sie daher nicht, uns zu kontaktieren, wenn Sie eine wichtige Quelle hingefügt haben möchten.
Wie TrustSource vor Dependency Konfusion schützen kann
Was ist passiert?
Sicherheitsforscher haben es mit Hilfe eines Dependency-Konfusion Angriffes geschafft, sich Zugang zu diversen Hochsicherheits-Netzwerken zu verschaffen. Mit Hilfe dieses Angriffes ist es Ihnen gelungen, Informationen und Daten aus den betroffenen Netzwerken nach draußen zu schicken. Je nach Ausgestaltung des Angriffsszenarios wären jedoch auch andere Aktivitäten denkbar. Erst einmal hinter den Verteidigungslinien angekommen, lässt sich das Schadensszenario frei wählen.
Wie ist der Angriff erfolgt?
Die Sicherheitsforscher sind auf die Idee gekommen, als Sie in den veröffentlichten Open Source Werkzeugen der Firmen (Apple, Adobe, etc.) Namen privater Pakete gefunden haben.
Oft nutzen Unternehmen Open source und ergänzen gewisse Funktionalitäten oder grafische Steuerelemente mit eigenen Bibliotheken. Diese wiederum werden nur von einem Team entwickelt und als eigene Pakete bzw. Bibliotheken für andere Entwicklungsteams bereitgestellt. Das ist effizient und komfortabel, da die breite Menge der Entwicklungs-Teams sich nicht kümmern muss, das Look-and-Feel dennoch konsistent über unterschiedliche Anwendungen bzw. Services bleibt.
Spielen die Unternehmen nun Software zurück an die Community und werden die Referenzen auf solche „privaten“ Pakete nicht aus dem Quellcode entfernt, trägt die Veröffentlichung dien Namen dieser Pakete nach draußen. Das an sich ist noch nicht so gefährlich. Interessant wird dies erst, wenn die Information für eine Dependency-Attack (s. nebenan) ausgenutzt wird.
Wie können Sie sich schützen?
- Komponenten-Namen:
Folgen die internen Komponentennamen einem Namens-Schema, wie bspw.ORG.COPMANY.UNIT.UITOOLSwird es für Dritte erheblich schwieriger entsprechende Namen in den Paketmanagern anzulegen, ohne dass es Aufsehen erregt.ORG.COPMANY.UNIT.UITOOLSfällt mehr auf, als die 100ste Version vonUITOOLS. - Nutzung von Paketmanager-Proxies:
Um in dem Angriff erfolgreich zu sein, sind die lokalen Verteilmechanismen zu überlisten. Es sollte sichergestellt sein, dass für gewisse Paket-Typen, u.a. bspw. mit Hilfe der Namenskennung ode reiner einfachen Blacklist, keine Updates von außen gezogen werden. - Versionsüberwachung:
Mit Hilfe einer Versionshistorie wird es schnell möglich, festzustellen, welche Versionen im Einsatz sind. Ein Sprung von 1.2.3 zu 69.1.0 lässt sich schnell entdecken, bzw. fällt auf.
Was ist eine Dependency-Konfusion?
Moderne Package-Systeme nutzen Paketmanager, insbesondere um die stetig wachsende Zahl von Open Source Komponenten zu verwalten. Jede Build-Vorschrift enthält daher eine Liste der einzubindenden Komponenten. Unter Java ist das die POM.XML-Datei, bei Node.JS (JavaScript) ist das die PACKAGES.JSON.
In dieser Datei sind die Komponenten und die Mindestanforderungen and die Komponenten, die Versionsnummern angegeben. Da sich viele Komponenten öfter ändern, steht in den Vorschriften oft nicht nur die exakte Versionsangabe, bspw. 1.2.3 sondern ein Vermerk wie ^1.2.3, was so viel bedeutet wie: „Gib mir mindestens die 1.2.3 oder neuer.“ . Erfolgt seitens der Maintainer der Komponente eine Update auf bspw. 1.2.4 (neuer Patch) oder 1.3.0 (neues Feature) würde die eigene Lösung mit Hilfe der Formulierung beim nächsten Bauen von den Neuerungen profitieren können.
Wird nun in einem Package Manager von einem bösartigen Akteur eine neuere Version eingestellt, bspw. eine 2.1.0, so kann er relativ sicher sein, dass diese Version vom Package Management für den oben beschriebenen Kontext bereitgestellt würde. Baut das Projekt nun anständig, würde dieser schadhafte Code in ein QS-System ausgebracht und dort ausgeführt. Je nach
Sie wollen Schwachstellen entlang des gesamten Produkt-Lebenszyklus Ihres Produkt verlässlich überwachen?
TrustSource kann gegen solche Angriffe schützen!
TrustSource kennt die aktuellen Versionen Ihrer Module und Lösungen sowie der öffentlich verfügbaren. plötzliche Versionssprünge öffentlich verfügbarer Komponenten werden von unseren Systemen erkannt und an unser Support-Team zur Prüfung gemeldet. Kritisch einzustufende Entwicklungen werden an die Projekte zurückgemeldet.
Nutzen Sie bereits TrustSource ist Ihnen vermutlich das Konzept des „linked Modules“, des Einbindens von Releases eigener Software bekannt. Tauchen hier Versionen auf, die bisher unbekannt sind, führt auch dies zu einer Meldung an den jeweiligen Projektleiter. Somit können Sie sicher sein, entsprechende Entwicklungen schnell zu bemerken.