암호 자재 명세서(CBOM, Cryptographic Bill of Materials)
1. 개요
정의: 암호 자재 명세서(CBOM, Cryptographic Bill of Materials)는 시스템을 구성하는 암호 알고리즘·키·인증서·프로토콜·암호 라이브러리와 이들 사이의 의존관계를 버전·파라미터·보안강도·사용위치와 함께 기계판독형으로 기록한 암호 자산 인벤토리이다.
기존의 소프트웨어 자재 명세서(SBOM)는 애플리케이션을 이루는 패키지·라이브러리·컨테이너를 식별하여 공급망의 가시성을 높이는 데 집중한다. 그러나 SBOM은 "어떤 라이브러리를 쓰는가"는 알려 주지만 "그 라이브러리가 실제로 어떤 암호 알고리즘을, 어떤 키 길이로, 어디에서 쓰는가"까지는 설명하지 못한다. 예를 들어 동일한 OpenSSL 버전을 쓰더라도 어떤 서비스는 RSA-2048로 TLS 핸드셰이크를 하고, 다른 서비스는 하드코딩된 MD5로 무결성을 검증하고 있을 수 있는데, SBOM만으로는 이 차이를 구분할 수 없다.
CBOM이 등장한 배경에는 양자컴퓨터의 발전과 그에 따른 전환 압박이 있다. 충분히 큰 결함허용 양자컴퓨터가 등장하면 Shor 알고리즘에 의해 RSA·ECC 같은 공개키 암호가 무력화될 수 있고, 지금 탈취해 저장해 둔 암호문을 미래에 복호화하는 "지금 수확하고 나중에 복호화한다(Harvest Now, Decrypt Later)" 위협이 현실화된다. 이에 NIST는 2024년 FIPS 203(ML-KEM)·FIPS 204(ML-DSA)·FIPS 205(SLH-DSA)로 양자내성암호(PQC) 표준을 확정했고, 전환 로드맵(NIST IR 8547 등)에서는 양자취약 알고리즘을 2030년경 권고폐기(deprecated), 2035년경 사용불가(disallowed)로 단계적으로 밀어내는 방향을 제시하고 있다(세부 일정·초안/최종 여부는 원문 확인 필요).
문제는 대부분의 조직이 "자신이 어떤 암호를, 어디서, 어떤 파라미터로 쓰는지"조차 정확히 모른다는 점이다. 인벤토리가 없으면 전환 대상 범위를 산정할 수 없고, 전환 우선순위를 정할 수 없으며, 전환 완료 여부도 증명할 수 없다. CBOM은 바로 이 "암호 가시성" 공백을 메우는 표준화된 인벤토리로, 암호 민첩성(Crypto-Agility)과 PQC 전환의 전제 조건이자 출발점이다.
이 답안에서는 CBOM의 구성 원리와 데이터 모델, 생성·운영 생명주기, SBOM과의 관계와 차이, 암호 민첩성 및 PQC 전환과의 연계, 그리고 기술사 관점의 도입 전략과 고려사항을 논술한다.
2. CBOM의 구성 원리와 데이터 모델
2.1 왜 "구성요소 목록"이 아니라 "관계와 맥락"인가
암호 자산은 단순 나열만으로는 위험을 평가할 수 없다는 점에서 일반 소프트웨어 패키지와 다르다. 같은 AES라도 128비트 CBC 모드와 256비트 GCM 모드는 보안 속성이 크게 다르고, 같은 RSA라도 서명용 2048비트와 키 교환용 1024비트는 양자·고전 위협에 대한 노출도가 전혀 다르다. 따라서 CBOM의 식별 단위는 "알고리즘 이름"이 아니라 알고리즘·모드·키 길이·보안강도·용도·구현 위치를 묶은 하나의 암호 자산이어야 한다.
또한 암호 위험은 개별 자산이 아니라 자산 사이의 의존관계에서 증폭된다. 예컨대 서버 개인키(관련 암호 자재)는 그것을 담은 X.509 인증서(certificate)와 연결되고, 그 인증서는 TLS 1.2 프로토콜(protocol)에서 쓰이며, 그 프로토콜은 RSA 키 교환과 SHA-256 서명(algorithm)에 의존한다. 한 노드가 양자취약으로 판정되면 그것에 의존하는 상위 자산·서비스를 역으로 추적해 영향 범위를 산정해야 하는데, CBOM은 이러한 의존 그래프를 표현함으로써 "무엇이 있는가"에서 "무엇이 무엇에 의존하며 어디까지 영향이 번지는가"로 분석 범위를 확장한다.
2.2 CBOM 전체 구성 개념도
flowchart LR
subgraph SRC["수집 원천"]
CODE["소스코드(정적분석)"]
BIN["바이너리·라이브러리"]
CFG["설정·인증서 저장소"]
NET["네트워크·TLS 스캔"]
end
subgraph CBOM["CBOM(CycloneDX 1.6)"]
ALG["algorithm(알고리즘·모드·강도)"]
CERT["certificate(X.509 등)"]
PROT["protocol(TLS·SSH·IPsec)"]
MAT["related-crypto-material(키·토큰)"]
end
subgraph USE["활용"]
RISK["양자위험·규정 분석"]
PLAN["PQC 전환 우선순위"]
PROOF["전환 완료 증빙·감사"]
end
CODE --> ALG
BIN --> ALG
CFG --> CERT
CFG --> MAT
NET --> PROT
ALG --> RISK
CERT --> RISK
PROT --> RISK
MAT --> RISK
RISK --> PLAN --> PROOF
위 그림처럼 CBOM은 여러 수집 원천에서 암호 자산을 추출하여 표준 스키마로 정규화하고, 이를 위험 분석·전환 계획·감사 증빙으로 흘려보내는 파이프라인의 중심에 위치한다. 수집 원천이 하나가 아니라는 점이 중요하다. 소스코드 정적분석만으로는 운영 환경에서 실제로 협상되는 TLS 스위트를 알 수 없고, 네트워크 스캔만으로는 코드에 잠재된 사용되지 않는 암호 경로를 찾을 수 없기 때문에, 신뢰할 수 있는 CBOM은 복수 원천을 병합·중복제거하여 만든다.
2.3 CycloneDX 1.6와 CBOM 데이터 모델
CBOM은 독자 포맷이 아니라 OWASP CycloneDX 1.6에서 추가된 암호 자산 표현 기능을 기반으로 한다. IBM Research가 주도해 설계했으며, 2024년 CycloneDX 1.6 릴리스에서 Attestations(증빙)와 함께 도입되었고, CycloneDX 명세는 ECMA-424로 표준화되어 국제 표준의 지위를 갖게 되었다. 핵심은 기존 SBOM과 "같은 포맷·같은 도구 체계"를 재사용한다는 점으로, 조직은 이미 운용 중인 SBOM 생성·검증·배포 파이프라인에 암호 자산을 얹을 수 있다.
CycloneDX는 암호 자산을 component의 cryptoProperties.assetType으로 분류하며, 대표 유형은 다음과 같다.
| assetType | 의미 | 기록 예시 | 위험 분석 포인트 |
|---|---|---|---|
algorithm |
암호 알고리즘·프리미티브 | RSA-2048, AES-256-GCM, SHA-1 | 양자취약 여부, 보안강도(112/128bit), 폐기 대상 여부 |
certificate |
공개키 인증서 | X.509 서버 인증서 | 서명 알고리즘, 유효기간, 체인 신뢰성 |
protocol |
보안 프로토콜 | TLS 1.2/1.3, SSH, IPsec | 취약 버전·취약 스위트 협상 가능성 |
related-crypto-material |
키·토큰 등 부가 자재 | 개인키, 비밀키, 토큰 | 보관 위치, 수명, 접근통제 |
각 자산에는 알고리즘 변형(primitive), 파라미터 세트, NIST 수준, 인증 상태, 구현 라이브러리와 함께 "코드의 어느 파일·어느 라인에서 쓰이는지"를 가리키는 증빙(evidence)이 결합된다. 이 증빙 연결 덕분에 CBOM은 단순 선언이 아니라 실제 코드·설정을 근거로 하는 검증 가능한 인벤토리가 되며, 전환 작업 시 수정 지점을 바로 특정할 수 있다.
3. CBOM 생성·운영 생명주기
3.1 발견(Discovery)·정규화·병합
CBOM 생성의 첫 단계는 암호 사용을 자동 발견하는 것이다. 소스코드 수준에서는 정적분석기가 암호 API 호출·알고리즘 상수·키 길이를 추출하고(IBM의 Sonar/CBOMkit 류 도구가 대표적), 바이너리 수준에서는 링크된 암호 라이브러리와 심볼을 식별하며, 운영 수준에서는 TLS/SSH 스캐너가 실제 협상되는 프로토콜·스위트·인증서를 수집한다. 서로 다른 원천이 같은 자산을 중복 보고하므로, 알고리즘·파라미터·위치를 키로 정규화·중복제거하여 하나의 일관된 그래프로 병합한다.
여기서 실무적 난점은 "정적으로 보이지만 실행되지 않는 경로"와 "동적으로만 드러나는 경로"를 어떻게 다룰지다. 코드에 MD5 호출이 있어도 데드코드일 수 있고, 반대로 외부 설정으로 런타임에 선택되는 알고리즘은 정적분석에 잡히지 않는다. 따라서 성숙한 조직은 정적 결과에 "사용 증거(호출 빈도, 트래픽 샘플)"를 결합해 자산의 실효성을 가중한다.
3.2 분석·우선순위·전환·증빙
수집된 CBOM은 위험 규칙과 결합되어 자산별 위험도로 환산된다. 대표 규칙은 (1) 양자취약 공개키(RSA·ECC·DH)인가, (2) 고전적으로도 취약한 레거시(MD5·SHA-1·DES·RC4·TLS 1.0)인가, (3) 보안강도가 112비트 수준이라 폐기 일정이 이른가 등이다. 이 위험도에 데이터 민감도·노출면·수명(장기 보호가 필요한 데이터인가)을 곱해 전환 우선순위를 산출한다. 장기 기밀성이 요구되는 자산일수록 "지금 수확하고 나중에 복호화" 위협이 크므로 PQC 전환을 앞당긴다.
sequenceDiagram
participant Dev as 개발·운영
participant Scan as 발견 도구
participant CB as CBOM 저장소
participant Risk as 위험·정책 엔진
participant PM as 전환 관리
Dev->>Scan: 코드·바이너리·TLS 스캔 요청
Scan->>CB: 암호 자산·증빙 제출(CycloneDX)
CB->>CB: 정규화·중복제거·의존 그래프 구성
CB->>Risk: 자산·의존관계 전달
Risk->>Risk: 양자위험·레거시·강도 평가
Risk->>PM: 우선순위·영향범위 산출
PM->>Dev: 전환 백로그·수정 지점 지시
Dev->>CB: 전환 후 재스캔(ML-KEM·ML-DSA 반영)
CB->>Risk: 전환 완료 여부 재검증
전환이 끝나면 동일 파이프라인으로 재스캔하여 양자취약 자산이 제거되고 PQC 알고리즘으로 대체되었음을 CBOM으로 증명한다. CycloneDX Attestations와 결합하면 "누가·언제·어떤 근거로 특정 통제를 충족했는가"를 서명된 형태로 남길 수 있어, 규제기관·고객에게 전환 진척을 기계판독형으로 보고할 수 있다.
4. SBOM·QBOM과의 비교, 그리고 암호 민첩성과의 관계
CBOM은 SBOM의 경쟁 개념이 아니라 보완·특화 관계다. SBOM이 "무엇으로 만들어졌는가(구성요소)"를 다룬다면, CBOM은 그 구성요소가 "어떤 암호를 어떻게 쓰는가(암호 행위와 자산)"를 다룬다. 둘은 같은 CycloneDX 포맷을 공유하므로 하나의 BOM 문서에 함께 담길 수 있다.
| 구분 | SBOM | CBOM | 비고(QBOM 관점) |
|---|---|---|---|
| 1차 관심 | 패키지·라이브러리·의존성 | 암호 알고리즘·키·인증서·프로토콜 | QBOM은 양자위험 관점에서 CBOM을 해석·확장 |
| 핵심 질문 | 무엇이 들어갔는가 | 어떤 암호를 어디서 쓰는가 | 무엇이 양자취약이며 언제까지 바꿔야 하는가 |
| 주 용도 | 취약 라이브러리·라이선스 추적 | 암호 가시성·PQC 전환·컴플라이언스 | 전환 일정·우선순위 수립 |
| 표준 | CycloneDX, SPDX | CycloneDX 1.6(ECMA-424) | 아직 수렴 중, 용어 혼용 유의 |
이 비교에서 차이가 생기는 근본 이유는 "동일성 판정 기준"이 다르기 때문이다. 패키지는 버전·해시로 동일성을 비교적 명확히 판정할 수 있지만, 암호 자산은 같은 이름이라도 모드·강도·용도·구현이 다르면 위험이 달라지므로, CBOM은 더 풍부한 속성과 증빙을 필수로 요구한다. 실무적으로 QBOM(Quantum-safe/Cryptography BOM)이라는 용어도 쓰이는데, 이는 대체로 양자안전 전환 관점에서 CBOM을 특화해 부르는 표현으로 이해하면 된다(표준·용어가 수렴 중이므로 단정은 지양).
암호 민첩성과의 관계도 중요하다. 암호 민첩성은 "특정 알고리즘을 코드 곳곳에 하드코딩하지 않고, 정책·설정으로 알고리즘을 교체할 수 있게 설계하는 능력"이다. CBOM이 없으면 어디를 바꿔야 할지 모르므로 민첩성의 전제가 무너지고, 민첩성이 없으면 CBOM으로 식별한 자산을 실제로 교체하기 어렵다. 즉 CBOM은 "가시성", 암호 민첩성은 "교체 능력"으로, 둘이 결합될 때만 PQC 전환이 반복 가능하고 측정 가능한 프로세스가 된다.
5. (심화) 규제·정책 동향과 실무 적용 전략
CBOM의 부상은 기술 트렌드만이 아니라 정책 압박과 맞물려 있다. 미국에서는 연방기관·계약자에 대해 양자내성 전환 시한(예: 2030년경 고가치·고영향 시스템)을 요구하는 흐름이 형성되고 있으며, FAR 개정 논의 등으로 공급망 전반에 NIST PQC 준수가 확산될 전망이다(구체 일정·적용 범위는 원문 확인 필요). NIST IR 8547은 RSA·ECC 등 양자취약 알고리즘을 2030년 권고폐기, 2035년 사용불가로 미는 전환 로드맵을 제시하며, 이때 112비트와 128비트 강도의 적용 시점이 달라질 수 있으므로 CBOM에 보안강도를 반드시 태깅해야 한다.
실무 적용의 핵심은 단계적 접근이다. 1단계는 발견으로, 전사 암호 사용을 CBOM으로 인벤토리화하여 "모른다"를 "안다"로 바꾸는 것이다. 한 금융기관이 수천 개 서비스의 TLS 설정을 스캔해 수백 건의 TLS 1.0/1.1과 다수의 RSA-1024를 발견한 사례처럼, 발견만으로도 즉시 조치 가능한 레거시가 드러난다. 2단계는 우선순위화로, 장기 기밀 데이터·외부 노출면·규제 대상 시스템을 상위에 둔다. 3단계는 하이브리드 전환으로, 당장 PQC 단독 전환이 어려운 영역은 전통 알고리즘과 PQC를 함께 쓰는 하이브리드 키 교환을 적용해 호환성과 안전성을 동시에 확보한다. 4단계는 지속 검증으로, CI/CD에 CBOM 생성을 내재화해 새 코드가 금지 알고리즘을 들여오면 빌드를 실패시키는 "정책 게이트"를 만든다.
이 과정에서 CBOM은 개발·보안·규제·감사 조직을 잇는 공통 언어로 작동한다. 개발자는 수정 지점을, 보안팀은 위험 우선순위를, 규제 대응팀은 준수 증빙을, 감사팀은 특정 시점의 암호 구성을 각자의 관점에서 같은 CBOM으로 소통할 수 있다는 점이 가장 큰 실무적 가치다.
6. 고려사항 및 시사점(기술사 관점)
- 전환 전략: CBOM 도입은 "PQC로 다 바꾸기"가 아니라 "먼저 보고, 우선순위를 정하고, 반복 가능하게 바꾸는" 거버넌스 체계 구축으로 접근해야 한다. 발견→분석→전환→증빙의 생명주기를 CI/CD에 내재화해야 일회성 조사가 아닌 지속 관리로 정착한다.
- 트레이드오프: 정적분석은 포괄적이지만 거짓양성(데드코드)과 동적 경로 누락이 있고, 네트워크 스캔은 실효적이지만 내부 호출·오프라인 자산을 놓친다. 단일 원천에 의존하지 말고 복수 원천을 병합하되, 증거 기반으로 자산의 실효성을 가중해 노이즈를 줄여야 한다.
- 암호 민첩성과의 연계: CBOM이 식별한 자산을 실제로 교체하려면 암호를 추상화 계층·설정으로 분리하는 민첩성 설계가 선행·병행되어야 한다. 가시성(CBOM)과 교체능력(agility)은 분리될 수 없는 한 쌍이다.
- 표준·용어의 미성숙: CBOM·QBOM·cryptoProperties 등 용어와 스키마가 수렴 중이므로, 특정 벤더 포맷에 고착(lock-in)되지 않도록 ECMA-424(CycloneDX) 같은 개방 표준을 기준으로 삼고, SPDX 등과의 상호운용성도 확보해야 한다.
- 보안 자체의 리스크: CBOM은 "어디에 어떤 약한 암호와 키가 있는가"를 담은 공격 지도이기도 하다. CBOM 산출물 자체에 대한 접근통제·서명·무결성 보호를 적용하지 않으면 공격자에게 최적의 표적 목록을 제공하게 된다.
- 전망과 연계 기술: 향후 CBOM은 SBOM·AI SBOM·VEX와 함께 통합 공급망 투명성 체계로 수렴할 가능성이 크며, 양자내성암호(PQC)·암호 민첩성·제로트러스트의 키/인증서 관리와 결합되어 조직의 암호 거버넌스 중추로 발전할 것이다.
참고자료
- OWASP CycloneDX v1.6 Released (CBOM·Attestations): https://cyclonedx.org/news/cyclonedx-v1.6-released/
- CycloneDX Specification Overview: https://cyclonedx.org/specification/overview/
- Wikipedia, Cryptographic bill of materials: https://en.wikipedia.org/wiki/Cryptographic_bill_of_materials
- IBM Research, CBOMkit (Zurich): https://www.zurich.ibm.com/cbom/
- NIST IR 8547, Transition to Post-Quantum Cryptography Standards: https://csrc.nist.gov/pubs/ir/8547/ipd
- NIST FIPS 203 (ML-KEM): https://csrc.nist.gov/pubs/fips/203/final
- NIST FIPS 204 (ML-DSA): https://csrc.nist.gov/pubs/fips/204/final
한 줄 요약: CBOM은 알고리즘·키·인증서·프로토콜 등 암호 자산과 그 의존관계를 CycloneDX(ECMA-424) 포맷으로 가시화하여, 암호 민첩성과 양자내성암호 전환을 반복 가능·측정 가능·증빙 가능하게 만드는 암호 거버넌스의 출발점이다.