vpierre/ndaal_public_sbom_auditorCycloneDX, SPDX 및 syft SBOM을 수집하고, CVE 스캐너 앙상블을 실행하며, EPSS, CISA-KEV 및 nuclei로 결과를 보강하고, SARIF, CSAF 및 PDF로 내보내는 오프라인 단일 바이너리 웹 앱입니다.
SBOM(Software Bill of Materials) 파일을 조사하기 위한 단일 바이너리 오프라인 웹 애플리케이션입니다. SBOM을 업로드하거나 SBOM 폴더를 가져와서, 독립적인 도구들의 앙상블로 각각을 분석하고, 정규화된 결과를 하나의 로컬 UI에서 검토한 뒤, 결과를 여덟 가지 형식으로 내보냅니다. 설치도, 네트워크 접근도, 텔레메트리도 없습니다.
NOASSERTION과 단순히 누락된 필드를 구분합니다.홈 페이지(/)는 저장된 모든 SBOM을 나열하며, 코퍼스가 커져도 계속 사용할 수 있습니다:
log4j나 openssl 같은 질의는 해당 컴포넌트를 포함하는 모든 SBOM을 찾아냅니다. 질의는 길이가 제한되며 관대하게 파싱됩니다./components는 반대 질문 — 내 SBOM 중 어느 것이 이 컴포넌트를 선언하는가 — 에 전체 코퍼스를 한 번에 대상으로, 컴포넌트 이름이나 정확한 패키지 URL로 답합니다. 이는 수집 시 구축된 전용 컴포넌트 인덱스를 읽으며, 대시보드의 전문 인덱스와는 별개입니다.
오래된 인덱스는 실제로 영향을 받는 SBOM을 "영향 없음"으로 읽히게 만들 수 있으므로, 이 페이지는 아직 인덱싱되지 않은 SBOM이 몇 개인지 명시하고, 바로 그것들에 대해 보관된 바이트를 다시 파싱하는 Rebuild index를 제공합니다. 검색은 그 경고가 사라져야만 완전해집니다.
"인덱싱됨"은 인덱스가 구축되었음을 의미하며, "행을 생성함"과는 다릅니다: 메타데이터만 있는 SBOM은 컴포넌트를 선언하지 않으므로 아무것도 기여하지 않지만 여전히 완전히 인덱싱된 것입니다. 저장소는 행 존재 여부로 추론하는 대신 SBOM별로 인덱싱 사실을 기록합니다(schema v8, components_indexed_at) — 추론 방식은 컴포넌트가 없는 SBOM이 "아직 인덱싱되지 않음" 집합에서 결코 벗어날 수 없게 만들어, 경고가 모든 재구축에도 살아남고 버튼이 같은 SBOM을 영원히 새로 인덱싱된 것으로 보고했습니다. 업그레이드는 자동으로 마이그레이션하고 이미 행이 있던 것은 백필하며, 한 번의 재구축으로 나머지가 정리됩니다.
각 도구는 런타임에 선택 사항이며 PATH에서 감지됩니다(SBA_TOOL_<NAME>_BIN으로 바이너리를 재정의). 발견 사항은 결코 단일 도구에 의존하지 않습니다. 각 스캔 전에 도구는 버전 인수와 함께 한 번 시작됩니다: 바이너리가 없으면 skip(not found on PATH)이고, 시작할 수 없거나 15초 이내에 응답하지 않는 바이너리는 그 이유와 함께 fail입니다.
| 도구 | 역할 | 검증 버전 |
|---|---|---|
| syft | SBOM 정규화기 / CycloneDX 1.6 변환기 | 1.52.0 |
| grype | CVE 매처 | 0.119.0 |
| trivy | 취약점 스캐너 | 0.74.0 |
| osv-scanner | OSV 데이터베이스 조회 | 2.4.0, 2.6.0 |
| bomber | 독립 앙상블 매처 | 0.5.1 |
| bomdrift | 공급망 드리프트 / 타이포스쿼팅(SARIF) | 0.9.9 |
| inspektr | SBOM 취약점 스캐너(JSON) | 0.1.9 |
| shieldbom | 오프라인 임베디드/IoT CVE 스캐너(SARIF) | 0.3.0 |
| provenant | 라이선스 / 저작권 / 출처(ScanCode) | 1.0.10 |
"검증 버전"은 각 호출이 실제로 실행된 버전이며, 최소 요구 버전도 고정 버전도 아닙니다: 도구는 런타임에 PATH에서 확인되며 호환되는 버전이면 무엇이든 작동합니다. osv-scanner가 두 개를 나열하는 이유는 2.x 계열이 로깅을 변경한 후 2.6.0을 재검증했기 때문입니다 — 문서화된 scan --lockfile <input> --format json 형식은 변경되지 않았고 여전히 발견 사항이 있으면 비영(非零) 종료하므로 코드 변경이 필요하지 않았습니다.
처음 여덟 개 도구는 CVE 형태의 취약점 발견 사항을 제공합니다; provenant는 다릅니다 — 라이선스, 저작권, 보유자 및 저자 출처를 보고하며, 감사기는 이를 버리지 않고 자체 발견 사항 형태로 저장하고 표시합니다(실행별 "Licence & provenance" 섹션, Markdown 내보내기에 포함).
스캐너들은 모든 형식을 직접 읽을 수 없습니다: bomber는 CycloneDX ≤ 1.6만 소비하고, 어떤 스캐너도 SPDX 3.0 JSON-LD를 읽지 않습니다. 두 경우 모두 감사기는 먼저 syft convert를 통해 입력을 CycloneDX로 정규화하며, syft를 사용할 수 없을 때는 도구가 패키지 0개를 보고하도록 두는 대신 문서화된 이유와 함께 건너뜁니다. grype의 취약점 데이터베이스는 실행당 한 번(대역 외로) 갱신되므로 일상적인 데이터 노후화는 실패한 스캔이 아니라 새로운 스캔이 됩니다.
분석 후, 각 CVE 형태 발견 사항은 vulnlookup 서비스(기본값 https://vulnlookup.ndaal.eu)에서 가져온 세 가지 실제 신호로 보강됩니다:
각 발견 사항은 KEV, Nuclei, EPSS 및 Source 값을 표시하며, Source는 vulnlookup 레코드로 다시 연결됩니다. 발견 사항은 가장 긴급한 것부터 정렬됩니다: 알려진 악용(KEV) 항목이 앞서고, 그다음 EPSS 백분위수가 높은 것이 옵니다; 보강이 없는 발견 사항은 분석기가 생성한 순서를 유지합니다. 보강 정보는 모든 내보내기 형식으로 전달됩니다 — SARIF 2.1 / 2.2, Markdown, ODT, DOCX, PDF 및 CSAF 2.1 / 2.2, 여기서 CSAF는 EPSS를 네이티브 지표로 담고 CISA-KEV와 nuclei를 노트로 기록합니다 — 그리고 내보내기 양식은 이제 기본적으로 모든 형식을 선택합니다.
Settings → Vulnerability enrichment에서 구성합니다: 켜기/끄기 토글(기본 활성화)과 최대 세 개의 vulnlookup 소스, 각각 기본 URL, TCP 포트 및 QUIC 포트를 가집니다(빈 포트는 443으로 처리됨). 소스 1과 2는 기본적으로 포트 443의 공개 https://vulnlookup.ndaal.eu를 사용하고, 소스 3은 기본적으로 이 호스트 자체의 8680(TCP) / 8681(QUIC) 포트에서 루프백 https://127.0.0.1을 사용하므로, 같은 위치에 있는 vulnlookup이 즉시 작동하는 폴백이 됩니다. 소스는 순서대로 시도됩니다 — 첫 번째가 주 소스이고 나머지는 폴백입니다.
조회는 브라우저가 아니라 감사기의 서버 프로세스가 수행하므로, 실행되는 호스트 자체가 HTTPS로 소스에 도달할 수 있어야 합니다: 클라이언트는 TLS 1.3만 사용하고 운영체제의 CA 번들을 신뢰합니다. 도달할 수 없으면 모든 발견 사항은 Not enriched로 남고 분석은 여전히 완료되며, 서버 로그는 0이 아닌 failed= 카운트와 함께 post-analysis enrichment finished를 표시합니다(클라이언트가 아예 시작할 수 없었을 때는 post-analysis enrichment failed). 보강은 모든 분석기가 완료된 후 한 번 실행되므로, 열은 실행이 완료된 직후 채워집니다.
결과를 읽을 때는 각 발견 사항이 어떤 패키지에 매칭되었는지 확인하십시오. 패키지가 없는 발견 사항 — 예를 들어 affects fedora @ 40 — 의 KEV 배지는 설치된 패키지가 아니라 운영체제 릴리스에 대한 매칭에서 나온 것이며, 대개 적용되지 않습니다. Go 표준 라이브러리에 대해 보고된 CVE-2020-0601도 같은 종류의 불일치입니다: 이는 Go가 1.13.6에서 수정한 Windows CryptoAPI 결함입니다.
하나의 발견 사항에서 세 신호를 모두 보려면 ndaal_public_sbom_examples 저장소의 jenkins:2.60.3 이미지 SBOM(example/anchore-sbom-examples/results/docker.io_library_jenkins:2.60.3/sbom/)을 분석하십시오: Spring4Shell(CVE-2022-22965)과 Jenkins Stapler RCE(CVE-2018-1000861)는 각각 KEV 배지, critical nuclei 템플릿, 그리고 0.98을 넘는 EPSS를 가집니다.
GitLab 작업 항목 #2는 Create CSAF document 액션을 추가합니다: 하나의 SBOM에 대한 감사 발견 사항이 초안 CSAF 2.1 권고문(상태 draft, 버전 0.1.0, 추적 id ndaal-sba-draft-에 SBOM의 SHA-256 앞 16자리 16진수를 붙인 것)이 되어 csaf.ndaal.eu 같은 csaf-crud 서비스에 제출됩니다. 이 빌드에는 초안 생성기와 Settings → CSAF upload 카드가 포함됩니다: 세 개의 엔드포인트를 순서대로 시도하며(csaf.ndaal.eu 두 번, 그다음 이 호스트의 https://localhost:8180에 있는 csaf-crud), 루프백 엔드포인트에서만 자체 서명 인증서를 신뢰하는 옵트인이 있습니다. SBOM 페이지의 버튼, 초안 다운로드 및 --export-csaf 명령줄 옵션은 다음 단계에서 이어집니다.