Sie löst üblicherweise direkte und transitive Abhängigkeiten, Komponentennamen und -versionen, Lizenzen, Herkunft sowie Übereinstimmungen mit veröffentlichten Schwachstellenaufzeichnungen oder organisationsdefinierten Richtlinien auf. Die Analyse kann Manifeste, Lockfiles, Quellbäume, Paket-Metadaten, Build-Ausgaben, Container-Images oder Binärsignaturen verwenden.
Der zentrale Nachweis ist die Komponentenidentität, nicht eine Analyse des Originalcodes der Anwendung oder eines Live-Angriffs. Genaue Identifikation hilft Teams, neu offengelegte Schwachstellen zu untersuchen, nicht unterstützte Abhängigkeiten zu verwalten, Lizenzpflichten zu prüfen sowie Software Bills of Materials zu erzeugen oder zu verifizieren. Ergebnisse benötigen fortlaufende Pflege, da sich Abhängigkeiten und externe Intelligenz nach dem Release ändern.
Wichtigste Punkte
Untersuchte NachweisePaketmanifeste und -locks, Abhängigkeitsgraphen, Artefaktinhalte, Paketkennungen, Prüfsummen, Build-Metadaten und Komponentendatenbanken.
Typische ErgebnisseKomponenteninventar, Abhängigkeitsbeziehungen, Versions- und Lizenzinformationen, Richtlinienbefunde, Schwachstellen-Abgleiche sowie Upgrade- oder Behebungskandidaten.
Solider BetriebDie tatsächlich gebauten und bereitgestellten Artefakte scannen, transitive und eingebettete Komponenten einbeziehen, Versionsnachweise bewahren, Intelligenz aktualisieren und Eigentümer für Behebungsentscheidungen zuweisen.
Wichtige EinschränkungEine Komponenten-zu-Advisory-Übereinstimmung belegt nicht, dass verwundbarer Code in einem bestimmten Produkt vorhanden, erreichbar oder ausnutzbar ist. Fehlende Metadaten und falsche Versionsauflösung können ebenfalls False Negatives oder Positives erzeugen.