BomLens가 하지 않는 일¶

이 문서는 우리가 아는 한계의 목록입니다. 결과를 믿고 쓰기 전에 읽어 주세요.

실행¶

Docker 엔진(20.10 이상)이 필요합니다. 데스크톱 앱과 웹 UI는 이미지를 대신 관리하고, CLI는 이미지를 직접 받게 합니다. 호스팅 서비스는 없습니다.
Windows 설치 파일은 아직 코드 서명이 없어서 처음 실행할 때 SmartScreen 경고가 나옵니다. 릴리스 서명으로 파일을 확인하세요.
웹 UI는 내 컴퓨터에서 혼자 쓰는 도구입니다. 계정과 접근 제어가 없으니 포트를 네트워크에 열지 마세요.
스캐너 이미지는 Trivy, syft, grype, cosign 같은 외부 도구를 함께 담고 있습니다. 이 도구들에 대한 취약점 알림 약 200건이 저장소의 코드 스캐닝 화면에 열려 있습니다. 각 도구의 원 저장소가 고친 의존성을 넣은 버전을 아직 내지 않았기 때문입니다. 고친 릴리스가 나오면 도구를 올리고, 알림은 이유를 적은 경우에만 닫습니다.

소스 스캔은 두 가지 방식으로 의존성을 찾습니다. 완전한 lock 파일이 트리 전체를 덮으면(package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, bun.lock, gradle.lockfile 중 하나이고 루트 아래 다른 매니페스트가 없을 때) lock 파일을 읽습니다. 그렇지 않으면 컨테이너 안에서 패키지 관리자를 실행해 프로젝트를 해석하는데, 이때 프로젝트 자체의 빌드 단계(pip install, go mod tidy, gradle)가 실행되고 레지스트리에 접근할 네트워크가 필요합니다. 고르는 옵션은 --detection이며 CLI 레퍼런스에 있습니다.
lock 파일이 없고 의존성을 해석할 방법도 없는 프로젝트는 결과가 모자랍니다. 스캔은 깨끗한 결과처럼 보고하지 않고 배너와 SBOM 기록으로 그 사실을 알립니다.
lock 파일을 정적으로 읽으면 빌드가 내려받은 패키지에서 읽는 저작권 표기는 채워지지 않습니다. 그래서 Rust 프로젝트는 항상 빌드합니다.
정적으로 읽는 방식은 lock 파일이 말하는 대로 의존성을 받아들입니다. lock 파일이 코드와 맞는지는 알려 주지 않습니다.

바이너리에 정적으로 링크된 구성요소는 도구가 심볼을 아는 몇 개의 라이브러리(ncurses, readline, quagga)만 찾습니다. 나머지는 식별하지 못하고 결과에도 나오지 않습니다. "정적 링크 구성요소가 있을 수 있음"이라는 표시는 아직 하지 않습니다.
펌웨어 분석은 이미지를 풀어 패키지 관리자 데이터와 심볼, 버전 문자열을 읽습니다. 암호화된 영역이나 지원하지 않는 형식은 읽지 않고 결과의 범위 안내에 적습니다.
바이너리 구성요소의 버전은 파일이 스스로 밝힌 내용과 대조해 정하므로 틀리거나 비어 있을 수 있습니다. 쓸 만한 버전이 없는 구성요소는 버전 없이 나열합니다.

취약점 대조는 Trivy의 데이터베이스를 쓰고, 선택하면 NVD CPE 대조(--deep-cve)를 더합니다. 패키지 URL이나 CPE가 없는 구성요소는 대조할 수 없습니다. "취약점 없음"은 식별된 것 안에서 찾지 못했다는 뜻이며, 그래서 보고서는 확인하지 못한 구성요소가 몇 개인지도 함께 적습니다.
악용 신호(EPSS, CISA KEV)와 라이선스 레지스트리 조회는 네트워크가 필요합니다. 오프라인 실행은 이를 건너뛰고 그 사실을 적습니다.
라이선스 정보는 패키지가 선언한 내용이며, 선택하면 ScanCode로 파일에서 읽습니다(--deep-license). 라이선스 분류와 충돌 검사는 안내일 뿐 법률 자문이 아닙니다.
도달성 분석(취약한 코드가 호출되는지)은 Go에만 있습니다.

출력은 CycloneDX 1.6(요청하면 1.7)이며, SPDX 내보내기와 AI 모델용 SPDX 3.0.1 문서를 함께 제공합니다. 다른 형식은 쓰지 않습니다.
적합성 검사는 SBOM을 2026년 최소 요소와 그 밖의 프로파일에 견주어 잽니다. SBOM이 적은 내용을 검사할 뿐, 그 내용이 사실인지는 검사하지 않습니다.

여기에 낡은 내용이 있거나 빠진 한계가 있으면 이슈로 알려 주세요.