Open-Source-Management
Open-Source-Management für die Software, die Sie tatsächlich ausliefern.
SBOMs aus CI und von Lieferanten laufen zu einem einzigen, gesteuerten Inventar zusammen – Lizenzen, Schwachstellen und Wartungsstatus für jede Komponente.
Open Source trägt die Anwendung. Das Risiko, das damit einhergeht, liegt selten dort, wo Sie es im entscheidenden Moment abfragen können.
Inventar
Die Liste ist unvollständig.
Transitive Abhängigkeiten und mitgelieferter (vendored) Code landen nie in einer Tabelle – wenn also eine CVE auftaucht, können Sie die Frage „Nutzen wir das, und wo?“ nicht beantworten.
Lizenzen
Pflichten bleiben ungeprüft.
Copyleft- und unbekannte Lizenzen gelangen in die Produktion, weil niemand die Pflichten den Komponenten zugeordnet hat, die sie tragen.
Wartung
Abhängigkeiten verrotten still und leise.
ine vor zwei Jahren gewählte Bibliothek wird upstream archiviert, und nichts weist Sie darauf hin, dass sie nun nicht mehr gepflegt wird.
Sie können nicht steuern, was Sie nicht inventarisiert haben.
Jedes SBOM – aus der CI oder aus einem Lieferanten-Upload – läuft in einem einzigen Inventar zusammen, das Sie nach Paket, Lizenz, Schwachstelle oder Wartungsstatus abfragen können.
01
Ein Inventar für jede Komponente, die Sie ausliefern.
Jedes SBOM speist eine organisationsweite Paketliste. Sehen Sie jede genutzte Version einer Komponente, die Produkte, die sie ausliefern, sowie ihre PURL und ihr Ökosystem an einem Ort.
Produktübergreifende Paketsicht, nicht ein SBOM nach dem anderen
Versionsverfolgung über das gesamte Portfolio
Transitive und mitgelieferte Komponenten inbegriffen
02
Kennen Sie jede Lizenzpflicht, bevor Sie ausliefern.
Lizenzausdrücke werden nach dem SPDX-Standard geparst und durchlaufen einen Freigabe-Workflow. Pflichten wie Namensnennung, Offenlegung des Quellcodes und Copyleft werden je Lizenz verfolgt – benutzerdefinierte Lizenzen inklusive, neben dem Standardkatalog.
Freigabestatus „Freigegeben“, „Abgelehnt“ und „Ungeprüft“
Pflichtenverfolgung für jede Lizenz
Benutzerdefinierte, nicht-SPDX-Lizenzen im selben Inventar
03
Neue CVEs werden auf bereits ausgelieferte Versionen zurückgeführt.
Neue CVEs werden auf bereits ausgelieferte Versionen zurückgeführt. Komponenten werden mit NVD, GitHub Security Advisories und OSV abgeglichen und anschließend mit EPSS, CISA KEV und CWE angereichert. VEX-Einstufungen halten die Reaktion Ihres Teams fest, sodass derselbe Fund nicht zweimal bewertet wird.
Korrelation mit NVD, GitHub Security Advisories und OSV
EPSS und KEV zur Priorisierung, nicht nur CVSS
VEX-Einstufungsverfolgung für jeden Fund
04
Erkennen Sie Abhängigkeiten, die das Internet nicht mehr pflegt.
Die Support Analysis wertet Signale aus Paket-Registries und Repositorys aus, um den Wartungsstatus jeder Komponente einzustufen, und zeigt OpenSSF-Scorecard- und Health-Scores an – sodass Sie riskante Abhängigkeiten nach Ihrem Zeitplan ersetzen und nicht erst nach einem Sicherheitsvorfall.
Eingestuft von „aktiv gepflegt“ bis „aufgegeben“
Registry-Deprecation plus Signale zur Repository-Aktivität
OpenSSF Scorecard und Health-Scores je Paket
Die Pflichten sind jeder Lizenz im Inventar zugeordnet, sodass die Anforderungen einer Komponente sie über jedes Produkt hinweg begleiten, das sie verwendet.
Namensnennung
MIT
BSD
Apache-2.0
Fügen Sie den Copyright-Hinweis und den Lizenztext Ihrer Distribution bei.
Offenlegung des Quellcodes
GPL-3.0
LGPL
Stellen Sie den entsprechenden Quellcode den Empfängern zur Verfügung.
Copyleft
GPL-.20
GPL-3.0
Abgeleitete Werke müssen unter derselben Lizenz veröffentlicht werden.
Patentgewährung
Apache-2.0
Die Lizenz enthält eine ausdrückliche Gewährung von Patentrechten.
Netzwerk-Copyleft
AGPL-3.0
Der Quellcode muss Nutzern angeboten werden, die über ein Netzwerk mit der Software interagieren.
Vom Upload zum gesteuerten Inventar in vier Schritten.
1. Einlesen
SBOMs kommen bei Push und Pull Request von GitHub, GitLab und Bitbucket, aus pylynk oder der GraphQL API in der CI oder über einen Lieferanten-Upload-Link.
2. Auflösen
Komponenten werden in das organisationsweite Paketinventar eingelesen und ihre Lizenzausdrücke dem SPDX-Katalog zugeordnet.
3. Anreichern
Jede Komponente erhält Schwachstellentreffer, EPSS- und KEV-Status, Wartungsgrad und OpenSSF-Scorecard-Ergebnisse.
4. Steuern
Richtlinien greifen je Umgebung bei Lizenz, Schwachstelle und Support-Grad. Verstöße erscheinen als Tickets in Jira oder Linear und als Warnungen in Slack.
Ersetzen Sie die Tabelle und den isolierten Scanner.
Manuell + nur Scanner:
✕ Das Inventar liegt in einer Tabelle, die vom Build abdriftet
✕ Lizenzen werden einmal geprüft, wenn überhaupt, ohne Freigabenachweis
✕ Scans laufen beim Release und vergessen die Version danach
✕ Kein Signal, wenn eine Abhängigkeit upstream aufgegeben wird
✕ Befunde liegen in einem Bericht, den niemand einem Verantwortlichen zuweist
Mit Interlynk:
✓ Ein Inventar, das bei jedem Build aktualisiert wird – produktübergreifend
✓ Lizenz-Freigabe-Workflow mit verfolgten Pflichten
✓ Kontinuierliche Überwachung ordnet neue CVEs ausgelieferten Versionen zu
✓ Wartungsstatus für jede Komponente eingestuft
✓ Richtlinienverstöße werden an Jira, Linear und Slack weitergeleitet
Open-Source-Management, beantwortet.
Was ist Open-Source-Management?
Es bedeutet, ein präzises, aktuelles Inventar der Open-Source-Komponenten in Ihrer Software zu führen und die damit verbundenen Risiken zu steuern: Lizenzpflichten, bekannte Schwachstellen und den Wartungsstatus. Interlynk inventarisiert Komponenten automatisch, prüft Lizenzen anhand eines Freigabe-Workflows, überwacht neue CVEs und kennzeichnet Komponenten, die nicht mehr gepflegt werden.