Cryptographic Bill of Materials (CBOM) Deep-Dive

 

오늘 다룰 주제는 보안 업계에서 가장 뜨겁게 떠오르고 있는 암호 자재명세서(CBOM, Cryptographic Bill of Materials)입니다.

이번 강의는 마린 이베지치(Marin Ivezic, 2024)의 전문 분석 자료인 “Cryptographic Bill of Materials (CBOM) Deep-Dive”를 바탕으로 진행됩니다.

원문에서는 CBOM을 이렇게 한 줄로 정의합니다:

“A CBOM is to cryptography what an SBOM is to software components.” (CBOM은 암호화에 있어 SBOM이 소프트웨어 구성 요소에 갖는 의미와 같습니다.)

원문의 이 말이 무엇을 뜻하는지, 제가 아주 쉽게 풀어드리겠습니다. 준비되셨나요?

---

STAGE 1 — Why It Matters: 왜 CBOM이 지금 당장 필요할까요?

여러분, 혹시 양자 컴퓨터(Quantum Computing) 소식 들어보셨나요?

양자 컴퓨터가 상용화되면, 지금 우리가 인터넷 은행, 쇼핑몰, 보안 로그인에 사용하는 대부분의 암호화 방식(RSA, ECC 등)이 단 몇 분 만에 뚫리게 됩니다. 시한폭탄의 바늘이 돌아가고 있는 셈이죠.

문제는 수많은 기업과 기관들이 “우리 시스템 내부 어디에, 어떤 암호가 쓰이고 있는지”조차 제대로 모른다는 점입니다.

소프트웨어가 점점 복잡해지면서 개발자조차 자신이 가져다 쓴 라이브러리 깊숙한 곳에 10년 된 위험한 암호 알고리즘(SHA-1, MD5 등)이 들어있는지 알지 못합니다. 어딘가에 숨어있는 위험한 암호를 찾지 못하면, 양자 컴퓨터 시대가 왔을 때 대응 자체가 불가능해집니다.

이 문제를 해결하기 위해 등장한 지도가 바로 CBOM입니다.

---

STAGE 2 — Unpacking the Core Concept: 핵심 개념 쉽게 파헤치기

개념이 조금 어렵게 느껴지시나요? 비유를 하나 들어볼게요.

어떤 대형 빌딩을 관리한다고 생각해 봅시다.

• SBOM(소프트웨어 자재명세서)은 “건물 자재 목록”입니다. 콘크리트는 어디 제품인지, 창문과 문은 몇 개가 들어갔는지 적어둔 설계도죠.
• CBOM(암호 자재명세서)은 “도어락 및 열쇠 관리 장부”입니다. 101호 문에는 어떤 비밀번호 도어락이 달려있는지, 열쇠 길이는 몇 cm인지, 열쇠 건전지 만료일(인증서 유효기간)은 언제인지 정밀하게 기록한 장부입니다.

건물 자재(소프트웨어 부품)를 아는 것도 중요하지만, 도둑을 막기 위해서는 ‘열쇠와 도어락(암호)’이 제대로 관리되고 있는지 아는 것이 핵심입니다.

📌 CBOM의 공식 정의

CBOM(Cryptographic Bill of Materials)이란, 소프트웨어 시스템에 적용된 모든 암호 알고리즘, 암호 키, 디지털 인증서, 보안 프로토콜 및 그들 간의 연결 관계를 컴퓨터가 읽을 수 있는(Machine-readable) 표준 형식으로 기록한 목록입니다.

---

STAGE 3 — Evidence and Application: 증거와 실무 적용

실제 산업계와 정부는 CBOM을 어떻게 활용하고 있을까요?

미국 백악관(OMB M-23-02)과 국가안보국(NSA)은 연방 기관에 차세대 양자내성암호(PQC)로 전환하기 위한 첫 단계로 암호 자산 전수조사(CBOM 구축)를 의무화했습니다. 또한 OWASP의 CycloneDX 1.6 표준은 CBOM을 공식 규격으로 포함시켰습니다.

SBOM과 CBOM의 구체적인 차이를 아래 표로 정리해 보았습니다.

구분	소프트웨어 자재명세서 (SBOM)	암호 자재명세서 (CBOM)
주요 대상	오픈소스 라이브러리, 패키지, 모듈	암호 알고리즘, 키, X.509 인증서, TLS 프로토콜
핵심 목적	소프트웨어 공급망 취약점 추적	암호 체계의 강도 점검 및 양자 위협(PQC) 대비
특성	코드에 정적으로 고정된 부품 위주	설정 및 통신 조건에 따라 달라지는 동적 가변성

🛠️ 실무 적용: CI/CD 파이프라인 자동화

개발자가 일일이 손으로 CBOM을 작성할 필요는 없습니다. 최근에는 개발자가 코드를 빌드할 때 자동으로 CBOM을 생성하도록 파이프라인(CI/CD)에 추가합니다.

예를 들어, GitHub Actions 환경에서는 다음과 같은 단계로 CBOM을 자동 추출합니다:

 

이렇게 매 빌드마다 생성된 CBOM 파일(JSON/XML)을 보안 모니터링 시스템에 전달하면, “유효기간이 30일 남은 인증서”나 “양자 컴퓨터에 취약한 RSA-2048 암호”가 사용될 때 보안팀에 즉시 알림이 가게 됩니다.

---

STAGE 4 — Summary and Extension: 요약 및 자가 점검

오늘 배운 내용을 3가지로 요약해 드립니다.

1. CBOM은 시스템 내 암호 알고리즘, 키, 인증서의 현황을 기록한 ‘암호 전용 자재명세서’입니다.
2. 양자 컴퓨터 시대를 대비해 양자내성암호(PQC)로 전환하기 위한 필수 지도 역할을 합니다.
3. CI/CD 파이프라인에서 자동 생성하여 암호의 취약점과 만료일을 지속적으로 모니터링할 수 있습니다.

---

 

SBOM이 걸어간 길 CBOM도 걷는가—“새로운 공급망 언어가 탄생하는 과정” < 보안·양자 < 기사본문 – 하이테크정보

1. 핵심 메시지 (Core Message)

미국 정부가 SBOM(소프트웨어 자재명세서)을 통해 소프트웨어 공급망 보안의 최소 요소와 기계 처리(자동화) 표준 문법을 정립했던 방식을, 최근 양자컴퓨터 시대에 대응하기 위한 CBOM(암호 자재명세서) 구축에 그대로 재적용하고 있습니다. 이는 단순한 행정 규제가 아니라, 글로벌 IT/보안 공급망 전반에서 사용될 ‘새로운 보안 통용 언어’를 만드는 과정입니다.

---

2. 전체 요약 (Full Summary)

1. SBOM 규제의 진화 (제도화 및 정교화):
   • 2021년 미 행정명령(EO 14028) 이후 NTIA가 최소요소와 ‘기계 읽기 가능성(Machine-readable)’ 원칙을 제시하며 시작되었습니다.
   • 2026년 초 연방정부 차원의 일률적인 서한(각서) 제출 방식은 완화되었으나, 오히려 FDA(의료기기) 인허가 및 유럽 EU 사이버복원력법 등 실질적 법적 강제력 영역으로 규제가 이동했습니다.
   • CISA 등의 개정 가이드라인(2026.07)을 통해 해시값, 사용 조건, 생성 도구 및 작성 시점(단계)까지 명시하도록 기준이 훨씬 촘촘해졌습니다.
2. CBOM의 등장과 배경 (행정명령 14412호):
   • 2026년 6월 미 행정명령 14412호는 CBOM 최소요소 가이드라인 수립(270일 내)과 조달 규정 개정을 명시했습니다.
   • 양자내성암호(PQC, Post-Quantum Cryptography: 양자컴퓨터의 해독에 견디는 차세대 암호)로 전환하려면, 현재 시스템 어디에 어떤 암호가 존재하는지 지도(Map)를 그리는 CBOM 구축이 필수 전제조건입니다.
3. SBOM과 CBOM의 기술적 본질 차이:
   • SBOM: 소스코드나 빌드 결과물 내에 부품(라이브러리)이 정적으로 존재하는지 여부를 추적합니다.
   • CBOM: 모듈이 제공하는 암호, 설정된 암호, 실제 통신/실행 시 최종적으로 협상되어 쓰이는 암호가 서로 다를 수 있는 가변성(Dynamic Nature)을 가집니다. 따라서 ‘있는 암호’와 ‘쓰는 암호’를 구분하여 실시간·자동화된 방식으로 평가하는 문법이 요구됩니다.

---

3. 3가지 핵심 개념 (Key Concepts)

1. 기계 읽기 가능성 (machine-readability)
   • 정의: 사람이 눈으로 확인하는 서류(PDF, Word)가 아닌, 컴퓨터 프로그램이 규칙에 따라 자동으로 수집·분석·위험 평가를 수행할 수 있는 데이터 구조(예: JSON, XML, CycloneDX 형식 등).
2. 암호 자재명세서 (cryptographic-bill-of-materials, CBOM)
   • 정의: 시스템 내부 및 통신 구간에 적용된 암호 알고리즘, 키(Key) 길이, 디지털 인증서, 암호화 모듈의 위치와 관계를 명시한 목록.
3. 동적 가변성 (static-vs-dynamic-inventory)
   • 정의: 정적으로 고정된 부품 목록과 달리, 암호 체계는 접속 상대나 설정 조건에 따라 실제로 사용되는 암호 알고리즘이 실시간으로 변하는 특성.

---

 

“CBOM의 목적은 서류 자체가 아니라 무엇을 바꿔야 하는지 확인하는 것이 핵심” < 보안·양자 < 기사본문 – 하이테크정보

오늘 강의는 제이슨 박(2026) 교수의 하이테크정보 기고문, “CBOM의 목적은 서류 자체가 아니라 무엇을 바꿔야 하는지 확인하는 것이 핵심”이라는 칼럼을 바탕으로 진행합니다.

원문에서 필자는 가장 중요한 한 문장을 이렇게 던집니다:

“목록의 목적은 서류 한 장을 더 만드는 데 있지 않다.”

보안 현장에서 왜 이 문장이 그토록 중요한지, 저스틴과 함께 하나씩 풀어보겠습니다. 준비되셨죠?

---

STAGE 1 — Why It Matters: 서류 도장 찍기 보안이 위험한 이유

많은 기업들이 정부 규제나 가이드라인이 나오면 “제출할 서류 한 장 더 늘었네”라고 생각하곤 합니다. 2024년 국내 「소프트웨어 공급망 보안 가이드라인 1.0」이 나오고 SBOM이 도입되었을 때도 비슷했죠.

하지만 서류를 만들어 제출했다고 해서 우리 시스템이 저절로 안전해질까요? 당연히 아닙니다.

원문 칼럼의 핵심 지적처럼, CBOM(암호 자재명세서)은 정부나 고객사 제출용 ‘성적표’가 아닙니다. 양자 컴퓨터가 등장하거나 새로운 암호 취약점이 터졌을 때, “그래서 우리 시스템에서 당장 무엇부터 갈아 끼워야 하지?”를 알려주는 ‘실시간 수리 지도’여야 합니다.

서류 작성을 위한 목록과, 실제 시스템을 바꾸기 위한 목록은 접근법부터 완전히 다릅니다.

---

STAGE 2 — Unpacking the Core Concept: ‘갖고 있는 것’과 ‘쓰는 것’의 차이

암호 목록을 만드는 일이 왜 소프트웨어 부품(SBOM)을 세는 것보다 훨씬 까다로울까요?

원문에서는 아주 명쾌한 비유를 듭니다. 바로 공구함의 망치 비유입니다.

집 공구함에 망치가 들어있다고 해서, 우리가 매일 망치질을 하는 것은 아니죠? 반대로 내 공구함에 망치가 없다고 해서, 집안 공사 현장 전체에서 망치가 안 쓰이는 것도 아닙니다.

소프트웨어와 암호의 관계도 똑같습니다.

구분	존재하는 암호 (Installed)	실제 쓰이는 암호 (In-Use)
의미	프로그램 라이브러리 내에 설치되어 있는 암호 기능	실제 사용자와 통신하거나 데이터를 저장할 때 실행되는 암호
비유	공구함에 들어있는 망치	지금 벽에 못을 박고 있는 망치
위험성	존재만 하고 쓰이지 않는 암호까지 다 세면 위험이 과장됨	눈에 띄지 않게 조용히 작동하는 암호를 놓치면 보안 맹점 발생

따라서 제대로 된 CBOM 장부라면, 단지 “RSA 암호 알고리즘 2만 건 발견”처럼 수치만 나열해서는 안 됩니다. 소용이 없거든요.

원문 저자의 설명에 따르면, 살아있는 CBOM에는 반드시 다음 4가지가 함께 적혀야 합니다:

1. 어디에 들어 있는가? (설치 위치)
2. 실제로 어디에서 쓰이는가? (실행 맥락)
3. 무엇을 보호하는가? (보호 대상의 중요도)
4. 바꾸면 무엇이 함께 흔들리는가? (연쇄 영향도)

이 4가지가 적혀 있어야만 “아, 3번 서버의 RSA 암호부터 당장 양자내성암호로 교체해야겠구나!”라는 우선순위가 나옵니다.

---

STAGE 3 — Evidence and Application: 미국 행정명령의 진실과 한국 정책의 ‘빠진 고리’

소스 출처 자료(제이슨 박, 2026)를 바탕으로, 최근 미국 정책의 진짜 맥락과 한국의 현주소를 짚어보겠습니다.

1. 미국 행정명령 14412호(2026.06.22)의 오해와 진실

뉴스만 보면 미국이 모든 기업에 당장 CBOM 제출을 강제한 것처럼 보이지만, 사실이 아닙니다.

미국 정부가 2027년 3월까지 만들겠다고 한 것은 ‘제출 명령’이 아니라, “컴퓨터(기계)가 암호 위험을 자동으로 평가할 수 있는 최소한의 공통 기준(가이드라인)”입니다. 기업들에게 서류를 내라고 쥐잡듯 잡기 전에, 자동으로 암호를 점검할 수 있는 ‘공통 문법’부터 촘촘하게 정립하겠다는 뜻이죠.

2. 한국 정책의 ‘빠진 고리 (Missing Link)’

현재 한국 정부는 두 가지 큰 축의 보안 정책을 훌륭하게 추진하고 있습니다:

• 축 A: 소프트웨어 부품을 세는 정책 (SBOM 가이드라인 1.0)
• 축 B: 암호를 차세대 양자내성암호로 바꾸는 사업 (KISA PQC 시범전환 사업)

하지만 원문 기고문은 매우 날카로운 질문을 던집니다.

“부품을 세는 사업(A)과 암호를 바꾸는 사업(B)은 시작했는데, 어느 부품에 어떤 암호가 잠겨있어서 무엇을 바꿔야 하는지 이어주는 공통 장부(CBOM)는 어디에 있는가?”

부품 목록(SBOM)만 가지고는 암호를 바꿀 수 없고, 암호 전환(PQC)만 추진해서는 시스템 어디에 암호가 숨어있는지 찾을 수 없습니다. 두 사업을 이어주는 연결고리가 바로 CBOM이라는 점을 원문은 강조하고 있습니다.

---

STAGE 4 — Summary and Extension: 요약 및 자가 점검

오늘 배운 내용을 핵심만 정리해 드릴게요.

1. CBOM의 본질: 단순 행정 제출용 서류가 아니라, 무엇을 먼저 바꿔야 할지 알려주는 실시간 운영 지도입니다.
2. 핵심 구분: ‘설치된 암호’와 ‘실제 쓰이는 암호’를 구분하고, 교체 시 연쇄 영향을 파악하는 4가지 요소가 기록되어야 합니다.
3. 정책적 시사점: 미국은 자동 평가 기준부터 만들고 있으며, 한국도 SBOM(부품)과 PQC(암호 전환) 사업을 이어줄 ‘CBOM 공통 장부’ 구축이 시급합니다.

자, 강의를 마무리하며 스스로 답을 떠올려볼 수 있는 점검 질문을 드립니다!

[자가 점검 질문] 한 보안 담당자가 스캔 도구를 돌려 “우리 회사 소스코드에서 MD5 옛날 암호 알고리즘이 100개 발견되었습니다!”라는 보고서를 가져왔습니다. 이때 저스틴이 강조한 CBOM의 관점에 따른다면, 이 담당자에게 가장 먼저 추가로 확인하도록 지시해야 할 질문은 무엇일까요?

---

 

소프트웨어 자재명세서(SBOM, Software Bill of Materials)를 누구나 직관적으로 이해할 수 있도록 3가지 서로 다른 영역의 비유로 구조를 비교해 드리겠습니다.

---

1. 식품의 ‘원재료명 및 함량 표시판’

• 공통점 (Similarity): 마트에서 과자를 살 때 뒷면에 밀가루, 땅콩, 식품첨가물 등이 적혀 있듯, SBOM은 소프트웨어 안에 어떤 오픈소스 라이브러리와 부품이 들어갔는지 적어둔 목록입니다. 식중독이나 알레르기 사고가 났을 때 “땅콩이 들어간 제품을 전부 회수해라”라고 하듯이, 특정 라이브러리(예: Log4j)에서 보안 취약점이 터지면 어떤 프로그램이 위험한지 즉시 찾아낼 수 있습니다.
• 차이점 (Difference): 과자 반죽은 이미 섞여서 땅콩만 쏙 뺄 수 없지만, 소프트웨어는 문제가 된 부품(라이브러리)만 새 버전으로 교체(패치)할 수 있습니다.

---

2. 자동차의 ‘리콜용 부품 납품 명세서’

• 공통점 (Similarity): 완성차 업체는 특정 브레이크 패드나 에어백 모듈이 어느 차량 모델, 몇 년식 라인에 들어갔는지 상세히 기록합니다. 그래야 결함이 발견되었을 때 해당 부품이 들어간 차량만 정확히 리콜할 수 있습니다. SBOM 역시 소프트웨어 내 특정 부품에 결함이 발견되었을 때 전체 시스템을 다 뒤엎지 않고 해당 부품만 추적하게 해줍니다.
• 차이점 (Difference): 자동차 부품은 1차 하청업체 수준에서 눈으로 확인 가능하지만, 소프트웨어는 부품 안에 또 다른 부품이 들어있는 중첩 의존성(Transitive Dependency, 부품 A가 부품 B를 가져다 쓰고 B가 C를 쓰는 구조)을 가지므로 사람이 눈으로 추적하기 어려워 자동화 도구가 필수적입니다.

---

3. 건물의 ‘시공 자재 내역서’

• 공통점 (Similarity): 건물을 지을 때 어느 철근과 콘크리트 브랜드를 썼는지 기록해 두어야 훗날 균열이 생겼을 때 원인을 규명하고 보강공사를 할 수 있습니다. SBOM도 프로그램 구축 시 사용된 자재의 출처와 버전을 기록하여 구조적 안전성을 보증합니다.
• 차이점 (Difference): 건물 자재는 시간이 지나 ‘물리적 마모’로 위험해지지만, 소프트웨어 자재는 코드가 가만히 있어도 외부에서 ‘새로운 공격 기술(취약점)’이 발명되면서 자재의 가치가 순식간에 위험 상태로 변합니다.

---

💡 응용 질문 (Apply to a new scenario)

위 비유들을 바탕으로 다음 상황을 해결해 보세요:

[시나리오] 귀하는 ‘스마트 가전(예: AI 로봇청소기)’를 만드는 제조사의 보안 책임자입니다. 만약 로봇청소기 안에 탑재된 ‘무선 통신 연결 라이브러리’에서 심각한 해킹 취약점이 발견되었다는 뉴스 보도가 나왔습니다.

질문: 이때 회사에 SBOM 시스템이 잘 갖춰져 있는 경우와 전혀 없는 경우, 문제 해결 과정에서 어떤 구체적인 차이가 발생할까요? 위 비유 중 하나를 인용하여 설명해 주세요.

[답변] SBOM 유무에 따른 보안 사고 대응 차이

1. SBOM이 없는 경우 (자동차 비유: 부품 장부 없이 리콜 조치)

• 상황 분석: 뉴스에서 특정 무선 통신 라이브러리의 취약점이 발표되어도, 당사 로봇청소기(A, B, C 모델) 중 어떤 제품의 몇 번 버전 소프트웨어에 그 부품이 들어갔는지 즉시 알 수 없습니다.
• 대응 과정:
  1. 모든 개발팀을 소환하여 수십 개 제품의 소스 코드를 사람이 직접 일일이 뒤져야 합니다 (전수 조사).
  2. 원인을 파악하는 동안(수일~수주일 소요) 사용자는 해킹 위험에 무방비로 노출됩니다.
  3. 문제없는 제품까지 판매를 중단하거나 서비스 가동을 멈추는 과도한 비용과 혼란이 발생합니다.

2. SBOM이 있는 경우 (자동차 비유: 전산화된 부품 납품 명세서 활용)

• 상황 분석: SBOM 검색 도구(기계 읽기 가능한 데이터)에 문제가 된 라이브러리 이름과 버전을 입력합니다.
• 대응 과정:
  1. 단 몇 초 만에 “로봇청소기 B 모델, 버전 1.2.0”에만 해당 부품이 탑재되어 있다는 사실을 즉시 추적합니다 (정밀 타격).
  2. 영향이 없는 A, C 모델은 정상 판매·운영을 유지합니다.
  3. B 모델 v1.2.0에 대해서만 선별적으로 원격 소프트웨어 업데이트(OTA 패치)를 배포하여 조기에 사태를 종결합니다.

한 줄 요약: SBOM이 없으면 “집 안의 모든 벽을 허물어 전선을 찾는 것”과 같고, SBOM이 있으면 “설계도를 보고 해당 전선만 찾아 교체하는 것”과 같습니다.

---

 

https://github.com/IBM/CBOM/

우리는 지난 3개 강의를 통해 CBOM이 왜 필요한지, 정책적 맥락이 무엇인지, 그리고 어떻게 6단계로 구축하는지 알아보았습니다.

오늘 다룰 주제는 한 단계 더 깊이 들어가 “CBOM 데이터 내부의 실제 기술 스키마 구조”입니다.

이번 강의는 CBOM 표준의 원형을 개발하고 이를 글로벌 표준(CycloneDX 1.6)으로 업스트림 통합시킨 IBM Research의 공식 기술 명세서(IBM/CBOM)를 바탕으로 진행됩니다.

원문에서는 CBOM의 기술적 본질을 이렇게 한 줄로 정의합니다:

“CBOM is an object model” (CBOM은 개체 모델입니다.)

암호 자산과 그 의존관계를 데이터 컴퓨터가 읽을 수 있도록 구조화한 이 ‘개체 모델’의 속살을 저스틴과 함께 하나씩 파헤쳐 봅시다!

---

STAGE 1 — Why It Matters: 왜 CBOM 스키마 필드를 직접 알아야 할까요?

자동화 도구를 돌려 cbom.json이라는 데이터 파일이 뽑혀 나왔다고 해봅시다.

하지만 보안 엔지니어나 개발자가 그 내부 스키마 필드의 의미를 알지 못하면, “이 암호가 소스코드 어디에 숨어있는지”, “단지 라이브러리가 제공만 하는 것인지, 실제 애플리케이션이 호출해서 쓰는 것인지”를 구분할 수 없습니다.

스캔 도구가 수집한 무수한 데이터 중에서 진짜 위험한 ‘실행 중인 암호’를 골라내기 위해서는 CBOM 스키마의 핵심 필드를 읽어내는 눈이 필수적입니다.

---

STAGE 2 — Unpacking the Core Concept: CBOM 스키마의 3대 핵심 기둥

IBM이 설계하고 CycloneDX 1.6에 반영된 CBOM 스키마는 크게 3가지 핵심 축으로 구성되어 있습니다.

 

하나씩 핵심만 짚어드릴게요!

1. cryptoProperties (암호 자산의 정밀 속성)

단순히 “AES 암호를 쓴다”고 적지 않습니다.

• primitive: 암호의 기본 종류 (예: blockcipher, drbg, hash 등)
• variant: 정밀한 암호 변형 (예: AES-128-GCM)
• nistQuantumSecurityLevel: 0부터 5까지의 정수값입니다. 0은 양자컴퓨터에 즉시 해독되는 위험 수준(RSA, ECC 등)을 의미하고, 1~5는 NIST PQC 표준 보안 등급을 뜻합니다.

2. confidenceLevels (신뢰도 점수)

정적 분석 도구가 소스 코드를 스캔할 때 추측성 탐지인 경우 0.0 ~ 1.0 사이의 확률 수치를 부여합니다. 사람이 나중에 검증할 때 이 신뢰도 점수를 보고 판단 우선순위를 정할 수 있죠.

3. detectionContext (소스코드 내 위치 추적)

취약한 암호가 발견되었을 때 “몇 번 파일(filePath), 몇 번째 줄(lineNumbers)”에 해당 코드가 존재하는지 정밀한 위치를 찍어줍니다. 개발자가 소스 코드를 수정할 때 시간을 획기적으로 줄여주는 일등 공신입니다.

---

STAGE 3 — Evidence and Application: implements vs uses 의존성의 기술적 결정판

IBM CBOM 스키마 디자인에서 가장 빛나는 핵심 개념은 바로 의존성 유형(dependencyType)의 분리입니다.

이것을 이해하기 위해 자동차에 비유해 볼게요.

• implements (구현/제공): 자동차 제조사가 차를 만들 때 엔진에 ‘스포츠 모드’, ‘크루즈 콘트롤’ 기능을 탑재해 놓은 상태입니다. (기능이 존재함)
• uses (실제 사용): 운전자가 도로에서 버튼을 눌러 ‘스포츠 모드’를 실제 작동시키는 상태입니다. (기능이 실행됨)

CBOM 스키마 데이터 예시를 볼까요?

만약 OpenSSL 라이브러리가 RSA-2048을 내장하고 있다면 OpenSSL과 RSA 간에는 implements 관계가 성립합니다. 하지만 내 앱이 OpenSSL의 TLS 1.3(ECDHE)만 호출하고 RSA 기능을 전혀 부르지 않는다면, 내 앱과 RSA 간에는 uses 관계가 생성되지 않습니다.

이 기술적 차이 덕분에, “라이브러리엔 들어있지만 우리 앱은 안 쓰니까 안심해도 된다”는 정밀한 판단이 가능해집니다. Does that make sense?

🛠️ IBM 오픈소스 CBOM 도구 생태계 (CBOMkit)

IBM Research는 이 스키마를 실제 현장에서 쓸 수 있도록 다음과 같은 오픈소스 도구 모음(CBOMkit)을 공개했습니다:

1. CBOMkit-hyperion: SonarQube 플러그인 형태로, 소스 코드를 정적 분석하여 CBOM을 정밀 생성.
2. CBOMkit-theia: 컨테이너 이미지(.docker)나 디렉토리를 스캔하여 내부 암호 자산 탐지.
3. CBOMkit-action: GitHub Actions CI/CD 파이프라인 연동용 액션.
4. CBOMkit-coeus: 생성된 CBOM JSON을 시각화해 주는 웹 대시보드 도구.

---

STAGE 4 — Summary and Extension: 요약 및 자가 점검

오늘 강의 내용을 3줄로 깔끔하게 정리해 드립니다.

1. IBM이 개발하고 CycloneDX 1.6 표준에 반영된 CBOM은 암호 자산과 의존성을 컴퓨터가 읽을 수 있게 만든 개체 모델(Object Model)입니다.
2. cryptoProperties를 통해 양자 보안 등급(nistQuantumSecurityLevel)과 소스코드 위치(detectionContext)까지 정밀 기록합니다.
3. implements와 uses 필드를 통해 “탑재된 암호”와 “실제 실행 중인 암호”를 구별하여 정밀하게 위험을 진단합니다.

마지막으로 오늘 배운 스키마 구조를 바탕으로 한 자가 점검 질문입니다. 스스로 답을 고민해 보세요!

[자가 점검 질문] 보안팀이 CBOM JSON 데이터를 파싱하던 중, 어떤 위험한 암호 알고리즘에 대해 dependencyType 값이 implements로만 적혀있고 uses 경로에는 연결되어 있지 않은 것을 발견했습니다. 이 암호 자산이 당장 우리 시스템에 미치는 실질적 위협 수준을 어떻게 평가해야 할까요?

---

📱 비유해 볼까요? : “스마트폰 앱”

여러분 스마트폰을 한번 떠올려 보세요.

1. 탑재된 암호 = “다운로드만 받아둔 앱”
   • 스마트폰을 샀을 때 기본으로 설치되어 있거나, 옛날에 받아두고 한 번도 열어보지 않은 앱입니다.
   • 용량은 차지하고 있지만, 지금 화면에 떠있지도 않고 작동하지도 않습니다.
2. 실제 실행 중인 암호 = “지금 켜서 쓰고 있는 앱”
   • 지금 화면에 켜놓고 계좌이체를 하거나, GPS를 켜고 길을 찾고 있는 실시간 작동 중인 앱입니다.
   • 배터리와 데이터를 실제로 소비하고 있습니다.

---

🔐 이것을 보안과 암호에 연결해 볼게요!

내가 쓰는 컴퓨터 프로그램(소프트웨어)도 스마트폰과 똑같습니다.

• 탑재된 암호: 프로그램 파일 안에 그냥 들어만 있는 암호 기능입니다. (언제든 쓸 수 있게 공구함에 넣어둔 상태)
• 실제 실행 중인 암호: 사용자가 로그인하거나 데이터를 보낼 때, 실제로 엔진이 돌아가며 작동하는 암호입니다.

구분	스마트폰 비유	암호 기술에서의 의미	위험 진단 관점
탑재된 암호	받아만 두고 안 쓰는 앱	파일 내에 코드만 존재하는 암호	당장 나를 공격하는 통로가 되기 어려움
실제 실행 중인 암호	지금 화면에 켜놓고 쓰는 앱	실시간으로 데이터를 암호화하는 암호	해커가 지금 당장 공격할 수 있는 진짜 위험 지점

---

💡 왜 이 둘을 구별해야 “정밀한 위험 진단”이 될까요?

만약 어떤 옛날 암호 기능에 해킹 위험(취약점)이 발견되었다고 해봅시다.

• 구별하지 못하는 사람: “우리 프로그램 안에 그 옛날 암호 코드가 들어있네? 큰일 났다! 당장 전체 시스템을 다 꺼라!” 하고 불필요한 패닉에 빠집니다. (안 쓰는 앱 때문에 휴대폰을 버리는 격이죠.)
• 구별할 줄 아는 보안팀 (정밀 진단): “어? 그 옛날 암호 코드가 프로그램에 들어(탑재)있긴 한데, 실제로 실행되는 경로를 확인해 보니 아무도 안 쓰네? 당장 시스템을 끄지 말고, 다음 업데이트 때 차근차근 제거하자!” 하고 정확하고 침착하게 대응합니다.

즉, “눈에 보이는 위험”과 “진짜 나에게 피해를 주는 위험”을 구분해 내는 것이 바로 이 개념의 핵심입니다.

---

 

https://github.com/IBM/CBOM/blob/main/EXAMPLES.md

우리는 지난 시간에 CBOM의 스키마 명세를 이론적으로 살펴보았습니다. 하지만 백문이 불여일견이죠! 실제 현장에서 돌아가는 JSON 코드가 어떻게 생겼는지 직접 눈으로 확인해봐야 완벽히 내 것으로 만들 수 있습니다.

오늘 강의는 IBM Research 공식 리포지토리의 실전 예시 문서(EXAMPLES.md)를 바탕으로 진행됩니다.

원문에서는 애플리케이션 관점의 의존성을 다음과 같이 다룹니다:

“Dependencies viewed from an application” (어플리케이션 관점의 의존성)

이 실제 예시 코드를 통해 “위험한 옛날 암호가 라이브러리에 버젓이 들어있는데도, 왜 우리 웹 서버는 안전하다고 판단할 수 있는지” 그 해독법을 명쾌하게 풀어드리겠습니다!

---

STAGE 1 — Why It Matters: 예시 코드를 직접 읽어야 하는 이유

보안 자동화 스캐너를 돌리면 수백 줄짜리 cbom.json 데이터가 쏟아져 나옵니다.

거기에는 AES-128-GCM 같은 최신 암호부터 차세대 양자내성암호인 Dilithium-5, 그리고 심지어 20년 된 해킹 위험 암호인 SSL v3나 MD5까지 몽땅 적혀있죠.

이 코드를 제대로 해독할 줄 모르면, “어? 라이브러리에 MD5 암호가 써있네? 당장 웹 서버 끄세요!” 하고 대형 오탐 사고를 치게 됩니다.

실제 JSON 파일 안에서 각 암호 자산이 어떻게 선언되고 연결되는지 예시를 통해 확고하게 익혀봅시다.

---

STAGE 2 — Unpacking the Core Concept: JSON 예시 코드로 보는 암호 자산들

IBM의 EXAMPLES.md에는 우리가 다루는 핵심 암호 요소들이 다음과 같이 정의되어 있습니다.

1. 차세대 양자내성암호 (Dilithium-5 예시)

• 핵심 포인트: 전자서명 알고리즘인 Dilithium-5에 대해 미국 NIST 양자 보안 최고 등급인 nistQuantumSecurityLevel: 5가 명시되어 있습니다. 컴퓨터는 이 숫자를 읽고 “이 자산은 양자컴퓨터에도 완벽히 안전하구나!”라고 판단합니다.

2. X.509 디지털 인증서 및 공개키 예시

인증서(certificate) 데이터에는 발급자(issuerName), 대상자(subjectName), 만료일(notValidBefore/After)이 정밀 기록되며, 연관된 공개키(relatedCryptoMaterial)는 PEM 포맷의 비트 길이(size: 3608)와 함께 독립적인 컴포넌트로 선언되어 서로 연결됩니다.

---

STAGE 3 — Evidence and Application: Nginx 웹 서버는 과연 위험할까?

이제 이번 강의의 하이라이트인 Nginx 웹 서버의 의존성 그래프(Dependency Graph) 예시를 분석해보겠습니다.

지하철 노선도를 생각해보세요.

• 선로가 깔려있는 것 = implements
• 실제로 열차가 달리는 노선 = uses

Nginx 웹 서버가 사용하는 libssl.so 및 libcrypto.so 암호 라이브러리 내부에는 옛날 암호인 SSL v3와 MD5 선로(implements)가 여전히 깔려 있습니다.

그렇다면 Nginx 실제 서비스도 위험한 걸까요? CBOM의 dependencies 배열을 추적해 봅시다!

시작 지점 (ref)	대상 지점 (dependsOn)	의존성 유형 (dependencyType)	실무적 의미
Nginx	libssl	uses	Nginx가 SSL 라이브러리를 실제 호출함
libssl.so	TLS v1.3, TLS v1.2, SSL v3	implements	라이브러리 안에 3가지 프로토콜이 탑재되어 있음
libssl.so	TLS v1.3	uses	라이브러리 중 TLS v1.3만 실제 작동시킴
libcrypto.so	MD5, AES-128-GCM, SHA256	implements	암호 엔진에 MD5, AES 등이 탑재되어 있음
libcrypto.so	AES-128-GCM, SHA256	uses	암호 엔진 중 AES와 SHA256만 실제 실행함

💡 해독 결과 (결정적 결론)

JSON 데이터를 따라가 보면 Nginx → TLS v1.3 → AES-128-GCM / SHA256으로 이어지는 uses 경로(실제 실행 경로)만 존재합니다.

SSL v3나 MD5로 이어지는 uses 경로는 존재하지 않습니다.

따라서 보안팀은 “라이브러리 파일 내에 MD5 코드가 남아있긴 하지만, Nginx 웹 서버가 실제 실행할 때는 안전한 TLS 1.3과 AES만 사용하므로 현재 시스템은 안전하다!”라고 확신을 가지고 보고할 수 있는 것입니다.

---

STAGE 4 — Summary and Extension: 요약 및 자가 점검

오늘 배운 핵심 내용을 3줄로 정리해 드립니다.

1. CBOM JSON 파일은 알고리즘, 인증서, 키 자재의 속성을 OID 및 양자 보안 등급(0~5)과 함께 구체적으로 선언합니다.
2. dependencies 배열은 컴포넌트 간의 연결 관계를 나타내며, implements 선로와 uses 실행 노선을 명확히 구별합니다.
3. 복잡한 CBOM 데이터에서도 uses 연결 경로만 추적하면 실제 보안 위협 여부를 정밀하게 판별할 수 있습니다.

마지막으로 실전 데이터 해독 능력을 점검하는 자가 질문입니다!

[자가 점검 질문] 보안 스캐너가 출력한 CBOM JSON 파일에서 libcrypto.so 항목에 MD5가 implements로 연결되어 있는 것을 발견했습니다. 이때 이 MD5가 우리 서비스에 ‘실제 보안 위협’이 되는지 파악하기 위해 JSON 데이터에서 가장 먼저 찾아보아야 하는 연관 항목은 무엇일까요?