오픈소스·SBOM 공급망 보안 실무 가이드

개발·빌드·배포·실행 전 경로에서 변조와 공격을 막는 실천. 소스 코드, 서드파티 컴포넌트, 빌드 시스템, 아티팩트 저장소, 전달 채널을 포괄한다. SolarWinds와 Log4Shell로 핵심 이슈가 됐다.

소프트웨어 자재 명세서. 소프트웨어에 포함된 모든 컴포넌트·버전·의존 관계의 완전한 목록으로, 소프트웨어의 '성분표'다. 미국 행정명령 14028은 연방 조달에서 SBOM 확산을 가속했으며, 각 기관은 소프트웨어 중요도에 따라 입찰 요건으로 SBOM을 요구할 수 있고, EU CRA는 EU 시장에 출시되는 디지털 제품에 SBOM 등 투명성 의무를 부과한다 — 대상은 다르지만 방향은 같다. CleanSource SCA의 SBOM 기능 보기 →

직접 의존성은 설정 파일에 명시적으로 선언한 컴포넌트, 전이 의존성은 그 컴포넌트가 다시 끌어오는 컴포넌트다. 취약점 대부분은 전이 의존성에 숨어 있으며 전이 의존성은 통상 현대 애플리케이션 의존성 트리의 대부분을 차지하며, 가장 간과되기 쉽고 추적하기 어려운 리스크 원천이다.

크게 허용적(MIT, Apache-2.0, BSD: 의무 적고 상용 친화)과 카피레프트형(GPL 계열: 파생물도 동일 조건 공개)으로 나뉜다. 도입 전 의무 강도를 확인하라.

GPL 컴포넌트로 만든 파생물을 배포하면 전체를 GPL로 공개하고 소스 전문을 제공해야 한다 — '전염성'. 배포 없는 내부 사용만이라면 통상 의무가 발생하지 않는다. 실제 의무는 수정, 연결 방식, 배포 형태 등에 따라 달라질 수 있으므로 개별 사안은 법률 검토가 필요합니다.

라이선스 유형과 사용 방식에 달렸다: 허용적(MIT/Apache)은 필요하지 않다. 카피레프트(GPL)는 '배포' 시 파생물 공개를 요구하며 사내 사용만으로는 적용되지 않는다. LGPL은 동적 링크 시 대체로 면제. 경계 판정이 복잡해서 라이선스 분석의 도구화가 필요한 것이다. 실제 의무는 수정, 연결 방식, 배포 형태 등에 따라 달라질 수 있으므로 개별 사안은 법률 검토가 필요합니다.

당한다. GPL 집행 소송에는 많은 선례가 있다: 유럽 gpl-violations.org 계열 승소, 미국 SFC 대 Vizio 판결은 소비자도 GPL 권리를 주장할 수 있음을 확립했다. 결과는 판매 금지·강제 공개·배상·신용 훼손 — '오픈소스는 아무도 단속 안 한다'는 낡은 인식이다. 실제 의무는 수정, 연결 방식, 배포 형태 등에 따라 달라질 수 있으므로 개별 사안은 법률 검토가 필요합니다.

공통 취약점 식별자. 알려진 보안 취약점의 전 세계 공통 번호 체계로 CVE-2021-44228(Log4Shell)이 대표적. MITRE가 관리하며 취약점 인텔리전스의 공용어다.

취약점 악용 가능성 교환(Vulnerability Exploitability eXchange). 벤더가 '이 제품이 해당 취약점의 영향을 받는가'를 기계 판독 형식으로 표명한다. SBOM의 동반 문서 — SBOM이 '이 컴포넌트를 포함한다'고 하면, VEX는 '그러나 우리 사용 방식에선 악용 불가'라고 말해 오탐 처리 비용을 크게 줄인다. VEX 지원 보기 →

미국 CISA가 유지하는 '악용이 확인된 취약점' 목록으로, 실제 공격 증거가 있는 것만 수록한다. 핵심 우선순위 판단 기준: KEV 등재 > CVSS 고득점 — 실제 악용되는 중위험이 이론상 치명적으로 평가된 취약점보다 급하다.

익스플로잇 예측 점수 시스템: 머신러닝으로 향후 30일 내 악용될 확률을 0~1로 예측한다. CVSS와 상보적 — CVSS는 '얼마나 심각한가', EPSS는 '실제로 공격받을 확률'. 둘의 결합이 현대 취약점 우선순위의 표준이다.

파이프라인에 자동 검사를 추가: 커밋 시 SCA/SAST 스캔, 정책 기반 차단(치명적 취약점·금지 라이선스면 빌드 실패), 결과를 코드 리뷰로 피드백. 게이트는 등급제로 — 일괄 차단은 개발 흐름을 크게 저해한다.

OpenSSF가 주도하는 소프트웨어 공급망 무결성 프레임워크. 현행 1.2판은 단일 1~3등급이 아니라 '트랙'으로 구성된다: 빌드 트랙은 빌드 과정의 변조 방지와 출처 증명을, 소스 트랙은 저장소 변경 관리를 측정하며 각 트랙에 보증 레벨이 있다. 실천 경로: 빌드 출처 증명(Build L1)부터 시작해 단계적으로 올린다 — SLSA 레벨은 대형 고객과 재단이 산출물 무결성을 평가하는 공통 언어가 되고 있다. SLSA 1.2 공식 사양 →

5개 축: 탐지력(조각 수준 스캔인가, 매니페스트만 읽는가), 데이터 품질(취약점 DB 커버리지와 신선도), 오탐 거버넌스(도달성 분석·정책 정의), 엔지니어링 융합(CI/IDE 통합·속도), 컴플라이언스 출력(SBOM 형식·감사 보고서). 자사 실제 코드베이스 POC 비교가 스펙표보다 확실하다. Community Edition 시작하기 →

3종 세트: 내부 저장소 미러(외부에서 통제 하에 정기 동기화), 취약점 DB 오프라인 업데이트 패키지(SCA는 오프라인 배포·인텔 임포트 지원 필수), 도입 허용 목록 절차(신규 컴포넌트는 DMZ 심사 후 내부 반입). 금융·방산·에너지의 표준 형태 — 선정 시 '완전 오프라인 지원'은 절대 조건이다. 오프라인 배포 데모 예약 →

모델과 데이터셋 자체가 컴포넌트가 되어(오염될 수 있고), 빠르게 진화하는 AI 프레임워크는 취약점이 밀집하며, 에이전트의 플러그인/도구 메커니즘이 코드 실행 면을 연다. 2026년 이후 AI 컴포넌트는 치명적 취약점 최다 영역이다.(출처: Sectrend CSSA 월간 통계) CleanCode 보기 →

Model Context Protocol — AI Agent가 외부 도구·데이터 소스를 호출하는 개방 프로토콜. 리스크: MCP 서버 자체가 새로운 공급망 컴포넌트(변조되거나 악용될 가능성), 도구 설명에 대한 지시 주입(프롬프트 인젝션), Agent 권한 남용. 도입 전 오픈소스 컴포넌트와 동일한 수준으로 MCP 서버를 감사해야 한다. SkillSec 보기 →

Agent는 '읽은 텍스트'를 '실행하는 행동'으로 바꾼다: 웹 페이지·문서·메일 속 숨은 지시가 작업으로 실행될 수 있다(간접 프롬프트 인젝션). 게다가 Agent는 실제 자격 증명과 시스템 권한을 가진다. 방어선: 도구 권한 최소화, 민감 작업 인간 승인, Agent가 읽는 콘텐츠의 인젝션 검사.

한국인터넷진흥원(KISA)이 발표한 「SW 공급망 보안 가이드라인 1.0」은 한국 기업의 실무 출발점이다: SBOM 기반 공급망 관리 체계, 단계별 도입 방법, 조직·프로세스 요건을 제시한다. 정부는 시범사업과 기업 지원 프로그램으로 확산을 추진 중 — 지금 체계를 갖추는 기업이 향후 조달·납품 요건 변화에 먼저 대응할 수 있다. KISA 가이드라인 원문 →

3층 구조로 접근한다: 생성(CI에 내장해 매 빌드 자동 산출), 관리(중앙 저장소에서 버전·제품별 이력 관리), 유통(고객·공급사와 형식/범위/갱신 주기 합의). 일회성 문서가 아니라 '살아 있는 SBOM'이어야 KISA 가이드라인이 요구하는 지속 관리가 가능하다. CleanSource SCA의 SBOM 기능 보기 →

확인 4항목: 요구 형식(SPDX/CycloneDX), 대상 범위(전체 제품인지 납품 모듈인지), 취약점 대응 계획 첨부 여부, 갱신 의무(신규 취약점 발생 시 통보 절차). 미리 자동 생성 체계를 갖춘 기업에게 SBOM 제출 요구는 부담이 아니라 신뢰 증명의 기회다.

시장별로 다르다: 미국 연방 조달은 EO 14028 계열의 SBOM·증명 요구, EU는 CRA의 '디지털 요소를 가진 제품' 의무(2027년 본격 적용), 의료기기는 FDA의 SBOM 제출 요구. 공통 분모는 하나 — 컴포넌트 인벤토리와 취약점 대응 체계를 지금 구축해 두면 어느 시장 요건에도 대응할 수 있다.

5가지: ①자사 실제 코드에서의 재현율(스니펫 수준 탐지 포함) ②오탐률과 트리아지 부담 ③대형 저장소 스캔 속도와 증분 스캔 ④오프라인/망분리 배포 지원 ⑤한국어 지원과 현지 대응 체계. 스펙 비교표보다 실코드 POC가 확실하다. Community Edition으로 시작하기 → (영문) SCA 평가 체크리스트 PDF ↓