모든 컴포넌트.SBOM모든 암호.CBOM모든 양자 리스크.PQC

SBOMLens는 ㈜체인랩스가 만든 SCA(소프트웨어 구성 분석) 및 SBOM·CBOM 관리 플랫폼입니다. 10개 패키지 생태계의 매니페스트와 lockfile에서 오픈소스 구성요소를 식별해 NVD·OSV·GHSA와 대조하고, 라이선스를 점검해 SBOM으로 내보냅니다. CI 게이트는 확인하지 못하면 실패합니다. 같은 스캔으로 7개 언어군 소스코드·설정 파일·인증서에서 CBOM(암호 자재명세서)을 만들고, 모든 알고리즘의 양자내성 준비도를 NIST FIPS 203/204/205 기준으로 평가합니다. 개발자 수가 아닌 조직 단위로 과금합니다.

네. SBOMLens는 SCA(소프트웨어 구성 분석) 제품입니다. 10개 패키지 생태계의 매니페스트와 lockfile을 읽어 정확한 버전이 확인된 구성요소를 NVD·OSV·GHSA와 대조하고(버전 범위로만 선언된 구성요소는 '미확인'으로 표시), 라이선스를 정책과 비교한 뒤 결과를 CycloneDX 또는 SPDX SBOM으로 내보냅니다. 구성요소는 매니페스트·lockfile에 적힌 내용으로 식별하며, 코드 조각(snippet) 비교는 하지 않고 바이너리 분석은 Preview입니다. 여기에 더해 같은 스캔에서 양자내성 등급이 붙은 CycloneDX CBOM을 만들고, 근거가 남는 Auto-VEX 판정을 작성합니다.

SBOM은 애플리케이션이 어떤 소프트웨어 컴포넌트로 만들어졌는지 — 라이브러리, 버전, 라이선스 — 를 나열합니다. CBOM은 그 애플리케이션이 의존하는 암호 자산 — 알고리즘, 키 길이, 프로토콜 버전, 인증서 — 을 나열합니다. “이 CVE에 노출되어 있는가”는 SBOM으로, “RSA가 깨지면 무엇이 무너지는가”는 CBOM으로 답합니다. SBOMLens는 둘 다 생성합니다.

SBOMLens는 CLI 스캔 한 번으로 SBOM(CycloneDX 1.6·1.5 또는 SPDX 2.3)과 CBOM(CycloneDX 1.6)을 함께 만들고, sbomctl scan --with-cbom을 쓰면 둘을 CycloneDX 1.6 파일 하나에 담습니다. 2026년 9월 기준, 다른 주요 SCA 벤더의 공개 제품 페이지에서는 양자내성 등급이 붙은 암호 알고리즘 인벤토리를 확인할 수 없습니다. JFrog Xray는 CycloneDX SBOM 내보내기에 CBOM 데이터를 넣을 수 있지만, 인증서와 비밀값만 다루고 알고리즘과 키 길이는 다루지 않습니다. SBOMLens의 CBOM은 Go·Java/Kotlin·JavaScript/TypeScript·Python·Rust·C/C++/Objective-C·C#, nginx·Apache httpd·HAProxy·openssl.cnf·Spring 설정의 TLS 항목, PEM 인증서와 키를 다룹니다.

네. sbomctl scan --with-cbom을 실행하면 소프트웨어 컴포넌트와 암호 자산이 CycloneDX 1.6 JSON 문서 하나에 함께 담기며, SBOMLens는 CycloneDX 출력을 공식 1.6 스키마로 테스트합니다. 두 목록이 같은 스캔에서 나와 같은 파일에 들어가므로 서로 다른 빌드를 가리킬 일이 없습니다. 이 옵션은 소스 스캔용이며 --upload·--binary와 함께 쓸 수 없습니다.

npm, PyPI, Maven, NuGet, Go modules, Cargo, Composer, RubyGems, CocoaPods, SwiftPM 등 10개 패키지 생태계를 지원합니다. Gradle 빌드 파일은 파싱하지 않으며, Java 의존성은 Maven pom.xml에서 읽습니다. Gradle 빌드 파일이 있으면 sbomctl ci는 파일 이름을 알리고 종료 코드 6으로 실패합니다(--allow-unsupported를 주면 경고로 바뀝니다). 바이너리 분석은 Preview로 제공하며, 파일 하나 또는 폴더 전체를 받아 Go 바이너리, JAR·WAR·EAR, Python wheel·egg를 읽습니다.

네, Preview로 제공합니다. 바이너리 분석은 파일 하나 또는 폴더 전체를 받습니다. Go 바이너리는 ELF·PE·Mach-O 파일의 빌드 정보로, JAR·WAR·EAR는 pom.properties의 Maven 좌표로(중첩 JAR 포함), Python 패키지는 wheel·egg·dist-info 메타데이터로 식별합니다. 그 밖의 ELF·PE·Mach-O 파일은 시그니처로 대조하고 낮은 신뢰도로 표시합니다. 결과는 SBOM이며, 바이너리에서 CBOM은 만들지 않습니다.

가능합니다. Enterprise 요금제의 온프레미스 빌드는 완전 폐쇄망에서 동작하며, 미리 넣어 둔 취약점 DB 스냅샷을 직접 갱신해 외부 연결 없이 매칭합니다. 국내 데이터 주권이 필요하면 같은 서버를 Microsoft Azure·AWS·KT ucloud에서 운영할 수 있습니다.

빌드가 실패합니다. NVD·OSV·GHSA 중 응답한 곳이 하나도 없으면 sbomctl ci가 종료 코드 4를 반환하므로, 전혀 확인하지 못한 스캔이 깨끗한 결과로 통과하는 일은 없습니다. 일부만 응답했다면 응답한 DB의 결과로 판정합니다. 서버에서는 어느 DB로도 확인하지 못한 SBOM을 '확인 안 됨'으로 표시합니다. 다른 실패도 코드가 따로 있습니다. 2는 취약점 정책, 3은 라이선스 정책, 5는 업로드 실패, 6은 파싱하지 못한 매니페스트가 탐지됐거나 구성요소가 하나도 없을 때입니다.

Auto-VEX가 의존성 그래프를 읽어, 취약 컴포넌트가 개발 의존성으로만 쓰이거나 이미 수정 버전 이상이면 not_affected로 판정합니다. 신뢰도 0.7 이상은 근거와 판단 사유를 붙여 자동 생성하고, 나머지는 담당자 검토로 넘깁니다. 담당자가 직접 배제한 결과는 사유와 만료일을 남겨 억제(suppression)할 수 있습니다.

VEX(Vulnerability Exploitability eXchange)는 특정 취약점이 자사 제품에 영향을 주지 않음을 표준 형식으로 밝히는 방법입니다. 이 문서를 손으로 쓰는 일이 취약점 관리에서 가장 느린 구간입니다. Auto-VEX는 의존성 그래프 근거로 판정을 내리고 각 판정의 근거·신뢰도 점수·판단 사유를 기록하며, 사람이 쓴 판정은 언제나 자동 판정보다 우선합니다. sbomctl vex auto --vex-format cyclonedx는 CycloneDX 1.6 VEX를 로컬에서 만들고, 어떤 소스 파일도 import하지 않는 npm 직접 의존성은 not_affected로 제안만 하고 자동 적용하지 않습니다. 직접 작성한 판정은 sbomctl vex add --project로 SBOMLens 서버에 저장합니다.

네. sbomctl cbom policy가 CBOM을 내장 NIST 정책이나 직접 작성한 YAML 규칙과 대조해 위반 시 빌드를 실패시킵니다. 새로 들어온 취약한 알고리즘을 감사 때가 아니라 CI에서 막습니다. 내장 정책은 약한 알고리즘과 짧은 키를 거부하고 RSA-2048에 경고합니다. 양자 취약 알고리즘까지 막으려면 YAML의 deny.algorithms에 RSA·ECDSA·ECDH·DH·DSA를 넣으십시오.

보안 의무를 지고 소프트웨어를 만들거나 도입하는 모든 조직입니다. 산업마다 요구가 다릅니다. 의료기기(美 FDA 524B조)와 디지털 요소 제품(EU 사이버복원력법)은 SBOM을, 美 연방 시스템(행정명령 14412)은 암호 인벤토리를, 금융(DORA ICT 제3자 리스크)과 자동차(UN R155, ISO/SAE 21434)는 공급망 증적을, NIS2는 공급자 리스크 관리를 요구하고, 국내는 공공분야 SBOM 제출 제도화를 추진하고 있습니다. SBOMLens는 그 모두의 출발점인 인벤토리를 만듭니다.

그 규제들이 출발점으로 삼는 산출물을 만듭니다. SBOMLens는 SBOM을 CycloneDX 1.6·1.5(JSON·XML) 또는 SPDX 2.3(JSON·Tag-Value)으로, CBOM을 CycloneDX 1.6으로(단독 또는 SBOM과 한 파일로), VEX를 근거와 함께 CycloneDX 1.6 VEX로, CI 결과를 SARIF 2.1로 내보냅니다. 2027년 12월부터 EU 사이버복원력법이 기술문서에 요구하는 기계 판독 가능 SBOM, FDA가 524B조 사이버 기기에 요구하는 SBOM, 행정명령 14412가 CISA·NIST에 CBOM으로 표준화하도록 지시한 암호 인벤토리가 여기에 해당합니다. SBOMLens는 인벤토리를 만들 뿐, 규제 준수를 인증하지는 않습니다.

날짜가 이미 정해졌기 때문입니다. 2024년 8월 FIPS 203·204·205로 대체 알고리즘이 확정됐습니다. NIST IR 8547 초안은 RSA-2048 같은 112비트 양자 취약 알고리즘을 2030년 이후 deprecated, 모든 양자 취약 공개키 알고리즘을 2035년 이후 disallowed로 제시합니다. 행정명령 14412는 美 연방 고가치·고영향 시스템에 2030년 12월 31일까지 양자내성 키 교환을, 2031년 12월 31일까지 양자내성 전자서명을 요구합니다. 전환에는 수년이 걸리고 오늘 수집된 데이터는 나중에 복호화될 수 있으므로, 계획보다 인벤토리가 먼저 있어야 합니다. SBOMLens는 각 암호 자산을 safe·vulnerable·ready로 분류하고 취약한 자산마다 대체 알고리즘을 지목합니다.

개발자 수가 아니라 조직 단위 월 고정가입니다. Free는 $0이며 프로젝트 1개, 프로젝트당 SBOM 5개, 하루 API 키 호출 100회까지이며, SBOM 비교·의존성 그래프·Auto-VEX·알림을 포함합니다. Standard는 조직당 월 $199로 프로젝트 10개와 하루 API 키 호출 10,000회를 제공하고, 서버의 CBOM·양자내성 등급·인증서 만료 추적·CBOM 비교를 더합니다. Premium은 조직당 월 $1,999로 프로젝트 50개, API 호출 무제한, 전담 지원을 제공하며, SLA는 계약으로 협의합니다. 대시보드 사용은 API 한도에 포함되지 않습니다. 애플리케이션 50개를 넘거나 온프레미스·폐쇄망이 필요하면 Enterprise로 견적하며, 51~150번째 애플리케이션은 앱당 월 $40부터입니다.

Preview로 가능합니다. AKS용 SBOMLens admission 웹훅은 sbomctl upload --image-ref로 SBOM을 올리지 않은 이미지, 해결되지 않은 critical 취약점이 있는 이미지, 검사가 아직 pending·incomplete인 이미지의 Pod를 거부합니다. partial 검사는 경고와 함께 허용합니다. 클러스터마다 조직 전용 admission 키를 따로 씁니다. 기본값은 fail-open(failurePolicy: Ignore)이므로 SBOMLens에 닿지 못하면 배포가 허용됩니다. 운영자가 SBOMLens 서버에서 기능을 켜야 동작합니다.

네. Azure에서는 Container Apps와 관리 ID, Entra 인증 전용 PostgreSQL, 액세스 키 없는 Redis·Blob Storage로 동작하고, 남은 몇 개의 비밀값은 Key Vault 참조로만 읽으므로 설정에 비밀값이 없습니다. Bicep 템플릿은 저장소에 있습니다. 같은 제품이 AWS·KT ucloud·폐쇄망 온프레미스에서도 동작합니다. 모든 요금제는 지금 직접 계약으로 구매할 수 있고, Azure Marketplace 리스팅은 2027년 1분기 게시 예정이며, Azure DevOps 태스크는 프리뷰입니다.

2주입니다. 체인랩스가 귀사 환경에서 SBOMLens를 직접 실행해 SBOM, CBOM, PQC 평가, 취약점 현황의 첫 결과를 그 기간 안에 제공하며, 귀사 스택에 맞춘 데모를 함께 구성합니다.