vpierre/ndaal_public_sbom_auditorऑफ़लाइन सिंगल-बाइनरी वेब ऐप जो CycloneDX, SPDX और syft SBOMs को इनजेस्ट करता है, CVE स्कैनरों का एक एन्सेम्बल चलाता है, निष्कर्षों को EPSS, CISA-KEV और nuclei के साथ समृद्ध करता है, और SARIF, CSAF और PDF निर्यात करता है।
एक सिंगल-बाइनरी, ऑफ़लाइन वेब एप्लिकेशन जो SBOM (Software Bill of Materials) फ़ाइलों की जाँच करता है। एक SBOM अपलोड करें या उनका एक फ़ोल्डर आयात करें, प्रत्येक का विश्लेषण स्वतंत्र टूल्स के एक समूह (ensemble) से करें, सामान्यीकृत निष्कर्षों की समीक्षा एक स्थानीय UI में करें, और परिणाम को आठ प्रारूपों में निर्यात करें। कोई इंस्टॉलेशन नहीं, कोई नेटवर्क एक्सेस नहीं, कोई टेलीमेट्री नहीं।
NOASSERTION को उस फ़ील्ड से अलग करते हुए जो बस अनुपस्थित है।होम पेज (/) प्रत्येक संग्रहीत SBOM को सूचीबद्ध करता है और संग्रह बढ़ने पर भी उपयोगी बना रहता है:
log4j या openssl जैसी क्वेरी हर उस SBOM को ढूँढ लेती है जो वह कंपोनेंट शिप करता है। क्वेरी की लंबाई सीमित है और इसे उदारता से पार्स किया जाता है।/components उल्टे प्रश्न का उत्तर देता है — मेरे कौन-से SBOM इस
कंपोनेंट को घोषित करते हैं — पूरे संग्रह में एक साथ, कंपोनेंट नाम या सटीक
पैकेज URL द्वारा। यह ingest के समय बनाए गए एक समर्पित कंपोनेंट इंडेक्स को पढ़ता है, जो डैशबोर्ड के फ़ुल-टेक्स्ट इंडेक्स से अलग है।
चूँकि एक पुराना इंडेक्स वास्तव में प्रभावित SBOM को "प्रभावित नहीं" के रूप में पढ़ा जा सकता है, पेज बताता है कि कितने SBOM अभी तक इंडेक्स नहीं हुए हैं और Rebuild index प्रदान करता है, जो ठीक उन्हीं के लिए रखे गए बाइट्स को फिर से पार्स करता है। खोज तभी पूर्ण होती है जब वह चेतावनी चली जाए।
"Indexed" का अर्थ है कि इंडेक्स बनाया गया था, जो "पंक्तियाँ उत्पन्न करने" के समान नहीं है: एक केवल-मेटाडेटा SBOM कोई कंपोनेंट घोषित नहीं करता, इसलिए वह कोई योगदान नहीं देता और फिर भी पूरी तरह से इंडेक्स होता है। स्टोर प्रति SBOM इंडेक्सिंग के तथ्य को रिकॉर्ड करता है (schema v8, components_indexed_at) बजाय इसे पंक्ति के अस्तित्व से अनुमान लगाने के — अनुमान लगाने का अर्थ था कि कंपोनेंट-रहित SBOM कभी "अभी तक इंडेक्स नहीं" सेट से बाहर नहीं निकल सकता था, इसलिए चेतावनी हर rebuild के बाद भी बनी रहती थी और बटन उन्हीं SBOM को हमेशा के लिए नए इंडेक्स किए गए के रूप में रिपोर्ट करता था। अपग्रेड स्वचालित रूप से माइग्रेट करता है और उन सबको बैकफ़िल करता है जिनमें पहले से पंक्तियाँ थीं; एक rebuild शेष को सुलझा देता है।
प्रत्येक टूल रनटाइम पर वैकल्पिक है और PATH पर पहचाना जाता है (बाइनरी को
SBA_TOOL_<NAME>_BIN से ओवरराइड करें)। निष्कर्ष कभी किसी एकल टूल पर निर्भर नहीं होते। प्रत्येक स्कैन से पहले टूल को उसके version आर्ग्युमेंट के साथ एक बार शुरू किया जाता है: कोई बाइनरी न होने का अर्थ है
skip (not found on PATH), जबकि एक बाइनरी जो शुरू नहीं हो सकती, या जो 15 सेकंड के भीतर कोई उत्तर नहीं देती, उसका अर्थ है उस कारण के साथ fail।
| Tool | Role | Verified against |
|---|---|---|
| syft | SBOM normaliser / CycloneDX 1.6 converter | 1.52.0 |
| grype | CVE matcher | 0.119.0 |
| trivy | Vulnerability scanner | 0.74.0 |
| osv-scanner | OSV database lookups | 2.4.0, 2.6.0 |
| bomber | Independent ensemble matcher | 0.5.1 |
| bomdrift | Supply-chain drift / typosquat (SARIF) | 0.9.9 |
| inspektr | SBOM vulnerability scanner (JSON) | 0.1.9 |
| shieldbom | Offline embedded/IoT CVE scanner (SARIF) | 0.3.0 |
| provenant | Licence / copyright / provenance (ScanCode) | 1.0.10 |
"Verified against" वह संस्करण है जिसके साथ प्रत्येक invocation वास्तव में चलाया गया था, न कोई न्यूनतम सीमा और न कोई पिन: टूल्स रनटाइम पर PATH पर हल किए जाते हैं और कोई भी संगत संस्करण काम करता है। osv-scanner दो सूचीबद्ध करता है क्योंकि 2.x लाइन के अपनी लॉगिंग बदलने के बाद 2.6.0 को फिर से सत्यापित किया गया — प्रलेखित
scan --lockfile <input> --format json रूप अपरिवर्तित है और निष्कर्षों पर अभी भी गैर-शून्य के साथ बाहर निकलता है, इसलिए कोई कोड परिवर्तन आवश्यक नहीं था।
पहले आठ टूल्स CVE-आकार के vulnerability findings में योगदान करते हैं;
provenant भिन्न है — यह licence, copyright, holder और author
provenance रिपोर्ट करता है, जिसे auditor अपने स्वयं के निष्कर्ष आकार के रूप में संग्रहीत और प्रदर्शित करता है (प्रति रन एक "Licence & provenance" अनुभाग, जो Markdown निर्यात में शामिल है) बजाय इसे त्यागने के।