SBOM으로 의존성 가시성 확보하기: Log4Shell이 알려준 교훈

들어가며

공급망 공격 시리즈에서 cooldown은 “새로 게시된 악성 버전을 받지 않는다”는 시간 기반 방어임을 다뤘습니다. 그러나 공급망 보안에는 그 이전 단계의 질문이 있습니다.

새로운 취약점이 공개됐을 때, 우리 프로젝트가 영향권인가?

이 질문에 즉답할 수 없다면, 어떤 정교한 방어를 갖췄든 사고 발생 시 대응 속도가 결정적으로 느려집니다. 이 글에서는 그 문제를 해결하는 SBOM(Software Bill of Materials) 과 GitHub의 자동화된 적용 방법을 다룹니다.

어떤 위험이 있는가: “우리는 영향받는가?”에 답하지 못함

현대 프론트엔드 프로젝트는 수백~수천 개의 의존성을 끌어옵니다. package.json에 직접 적힌 의존성이 50개라면, 그것들이 끌어오는 간접 의존성(transitive dependency)까지 합치면 1,000개를 넘기는 경우가 흔합니다.

이 상황에서 새로운 CVE가 공개되면 다음과 같은 일이 일어납니다.

보안 뉴스에 [유명 라이브러리] CVE-XXXX-XXXXX 발견이라는 헤드라인이 뜬다
팀에서는 “우리도 영향받는가?” 라는 질문이 시작된다
개발자들이 package.json · yarn.lock · pnpm-lock.yaml을 뒤지며 grep으로 라이브러리 이름을 검색한다
직접 의존성에는 없지만 간접 의존성으로 들어와 있는지 추가로 확인한다
영향받는 앱·서비스가 식별되면 그제서야 패치 작업이 시작된다

이 과정이 빠르면 한두 시간, 느리면 며칠이 걸립니다. 그리고 그 시간 동안 우리 시스템이 이미 공격당하고 있을 수 있습니다.

Log4Shell이 보여준 가시성 부족의 대가

2021년 12월 공개된 Log4Shell(CVE-2021-44228)은 Apache Log4j의 임의 코드 실행 취약점이었습니다. CVSS 점수 10점, 사실상 모든 자바 애플리케이션이 직간접적으로 영향권에 있었습니다.

이 사건이 전 세계 보안팀에게 남긴 가장 큰 교훈은 취약점 그 자체가 아니라, “우리 조직 어디에 Log4j가 있는지 아무도 모른다” 는 사실이었습니다.

직접 의존성으로 적은 적이 없어도, 다른 라이브러리가 의존하기 때문에 들어와 있는 경우
빌드된 JAR 파일 안에 fat jar로 포함되어 코드 검색으로는 안 보이는 경우
오래된 서비스의 의존성 트리를 누구도 최신 상태로 알지 못하는 경우

CISA의 공식 권고에서도 가장 먼저 권한 행동으로 명시한 것은 “Log4j 사용 여부를 식별하라(Identify the use of Log4j)” 였습니다. 패치보다 식별이 먼저였던 것입니다.

미국 정부는 이 사고 직후 Executive Order 14028을 통해 연방 정부에 소프트웨어를 납품하는 모든 공급자에게 SBOM 제출을 의무화했습니다 (CISA의 SBOM 정책 페이지). 가시성 자체가 보안의 전제 조건이라는 것이 정책적으로 확인된 순간입니다.

SBOM이란 무엇인가

SBOM(Software Bill of Materials)은 글자 그대로 “소프트웨어 자재 명세서” 입니다. 어떤 라이브러리가, 어떤 버전으로, 어떤 의존 관계로 우리 빌드 결과물에 들어가 있는지를 기계가 읽을 수 있는 형식으로 기록한 것입니다.

SBOM이 있다면 위의 5단계가 다음과 같이 바뀝니다.

보안 뉴스에 CVE가 뜬다
SBOM과 CVE 데이터베이스를 매칭한다 (자동)
영향받는 시스템 목록이 즉시 출력된다
그 목록에 따라 패치를 시작한다

“우리는 영향받는가?”에 대한 답이 사람의 시간이 아니라 컴퓨터의 시간으로 나옵니다.

대표적인 SBOM 표준은 두 가지입니다.

CycloneDX: OWASP가 주도하는 형식. JSON·XML 양쪽 지원
SPDX: Linux Foundation이 주도하는 형식. ISO/IEC 5962 표준

어느 쪽을 쓰든 도구는 거의 비슷하고, 중요한 것은 “SBOM을 정기적으로 만들고 관리하는 것” 자체입니다.

어떻게 적용하는가

SBOM이라고 하면 별도 도구·워크플로우가 필요하다고 생각하기 쉽지만, GitHub 위에서 작업하고 있다면 가장 중요한 부분은 이미 자동으로 돌고 있을 가능성이 큽니다. 도입 단계를 두 층으로 나눠 보는 것이 정확합니다.

기본: GitHub Dependency Graph는 자동 작동 중

GitHub은 리포지토리에 package.json/yarn.lock/pubspec.yaml/Gemfile/pom.xml 같은 표준 manifest 파일이 있으면, 별도 설정 없이 자동으로 Dependency Graph를 생성합니다. 이 그래프가 GitHub Advisory Database와 매칭되어 Dependabot Alert가 작동합니다.

확인 위치는 다음과 같습니다.

Settings → Security → “Dependency graph” 가 활성화되어 있는지 (기본 활성)
Security 탭 → “Dependabot alerts” 에서 알려진 CVE 매칭 알림 수신

이 두 가지가 정상 동작 중이라면 — npm·pub·gradle 등 GitHub이 지원하는 주류 생태계라면 거의 확실히 — 새 CVE 공개 즉시 영향받는 의존성에 대한 Dependabot Alert가 자동으로 떠 있을 것입니다.

결론적으로, 일상적인 공급망 가시성·CVE 감지 목적이라면 추가 워크플로우는 필요하지 않습니다.

이 글의 도입부에서 다룬 “Log4Shell이 떴을 때 우리가 영향받는지 즉답하기” 같은 가장 큰 실용 가치는, GitHub 사용자에게는 이미 무료로 제공되고 있는 셈입니다.

추가: 표준 SBOM 파일이 필요한 경우

다음 시나리오에서는 SPDX 또는 CycloneDX 형식의 SBOM 파일 을 별도로 생성해야 합니다.

정부·금융 등 컴플라이언스 요구로 SBOM 제출이 의무인 경우
고객·감사자에게 SBOM을 release artifact로 첨부해야 하는 경우
Trivy·Grype·Snyk Container 같은 외부 분석 도구에 SBOM을 파이프라인으로 넘기는 경우
빌드 산출물의 vendored 라이브러리·native binary 등 GitHub이 자동 인식하지 못하는 영역까지 추적해야 하는 경우

이런 요구가 있을 때만 워크플로우를 하나 추가합니다.

# .github/workflows/sbom.yml
name: SBOM
on:
  release:
    types: [published] # 릴리스 시점에 artifact로 첨부
  workflow_dispatch:

permissions:
  contents: write

jobs:
  generate-sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<SHA> # v6
      - uses: actions/setup-node@<SHA> # v6
      - run: corepack enable && yarn install --immutable
      - uses: advanced-security/sbom-action@<SHA>
        with:
          path: ./

advanced-security/sbom-action 외에 Anchore의 sbom-action, CycloneDX의 GitHub Action 등 선택지가 다양합니다. 어떤 도구를 쓰든 결과물은 SPDX/CycloneDX 표준 형식이라 외부 도구와 호환됩니다.

효과 요약

목적	필요한 작업
GitHub에서 Dependabot Alert 받기	자동 (별도 설정 불필요)
의존성 트리 인벤토리 확보	자동 (별도 설정 불필요)
외부 컴플라이언스용 SBOM 파일 첨부	`sbom-action` 워크플로우 필요
외부 분석 도구(Trivy 등)에 SBOM 파이프라인	`sbom-action` 워크플로우 필요

한계

SBOM은 가시성 도구이지 방어 도구가 아닙니다. 다음에 유의해야 합니다.

SBOM이 있어도 사람이 보지 않으면 의미가 없습니다. Dependabot 알림 채널을 Slack 등에 연결하는 후속 작업(/github subscribe <ORG>/<REPO> vulnerability_alerts)이 필요합니다.
SBOM은 빌드 시점의 스냅샷입니다. 그 이후에 의존성이 바뀌면 다시 생성해야 합니다 (그래서 정기 cron이 권장됩니다).
SBOM이 모든 출처를 잡는 것은 아닙니다. CDN으로 로드되는 외부 스크립트(예: Google Fonts)는 SBOM에 잡히지 않습니다. 이 부분은 SRI 같은 다른 도구로 보완합니다.