소프트웨어 공급망 보안 입문: 무엇을 공부하고 어떤 도구로 검증할까

소프트웨어 공급망 보안은 내가 작성한 코드만 검사하는 일이 아니다. 외부 라이브러리, 빌드 서버, CI/CD 워크플로, 컨테이너 이미지, 레지스트리, 배포 정책까지 코드가 제품이 되어 운영 환경에 도착하는 모든 연결 고리의 신뢰를 관리하는 일이다.

 

그래서 취약점 스캐너 하나를 도입했다고 끝나지 않는다. 무엇이 들어왔는지 목록을 만들고, 누가 어떤 환경에서 빌드했는지 증명하며, 승인한 산출물만 배포되도록 막고, 문제가 생겼을 때 영향을 빠르게 추적해야 한다. 이 글은 그 흐름을 공부 순서와 작은 실습 프로젝트로 연결한다.

먼저 바로잡을 오해: 공급망 보안은 취약점 스캔이 아니다

Log4Shell처럼 이미 알려진 취약 라이브러리를 찾는 일은 중요하다. 하지만 정상 라이브러리의 배포 계정이 탈취되거나, 이름이 비슷한 악성 패키지를 개발자가 설치하거나, 빌드 단계에서 산출물이 바뀐다면 CVE 목록만으로는 잡기 어렵다.

 

NIST는 Cybersecurity Supply Chain Risk Management(C-SCRM)를 설계·개발·배포·획득·운영·폐기까지 전 생애주기의 위험을 식별·평가·완화하는 활동으로 설명한다. 소프트웨어에 좁혀 보면 다음 다섯 질문이 핵심이다.

1. 무엇이 들어갔는가? 직접·간접 의존성과 라이선스를 알고 있는가?
2. 어디서 왔는가? 소스, 패키지, 베이스 이미지와 공급자를 추적할 수 있는가?
3. 어떻게 만들어졌는가? 빌드 과정과 입력을 증명할 수 있는가?
4. 변조되지 않았는가? 산출물의 서명과 다이제스트를 배포 전에 검증하는가?
5. 문제가 생기면 찾을 수 있는가? 영향을 받는 서비스와 배포본을 빠르게 식별할 수 있는가?

전체 흐름부터 그려 보자

공급망은 소스 → 의존성 → 빌드 → 산출물 → 레지스트리 → 배포로 이어진다. 각 단계에는 서로 다른 증거가 필요하다.

단계	대표 위험	남겨야 할 증거	대표 통제
소스	계정 탈취, 무단 변경	커밋과 리뷰 기록	브랜치 보호, MFA, CODEOWNERS
의존성	악성 패키지, Dependency Confusion	Lockfile, SBOM	버전 고정, 사설 레지스트리 우선순위
빌드	CI 권한 오용, 빌드 중 변조	빌드 로그, Provenance	격리된 빌드, 최소 권한, 워크플로 고정
산출물	이미지 교체, 태그 재사용	Digest, 서명, Attestation	Cosign 서명·검증
배포	미승인 이미지 실행	승인·정책 로그	Admission Policy, Digest 배포
운영	뒤늦게 공개된 취약점	배포본과 SBOM 연결	재스캔, VEX, 영향 분석

SBOM(Software Bill of Materials)은 소프트웨어에 포함된 구성요소 목록이다. SPDX와 CycloneDX가 대표 형식이다. Provenance는 “이 산출물이 어떤 소스와 빌드 과정으로 만들어졌는가”를 설명하는 증명 자료다. 둘은 대체 관계가 아니다. SBOM이 재료표라면 Provenance는 제조 이력에 가깝다.

무엇을 어떤 순서로 공부해야 할까

1단계: 의존성 그래프와 신뢰 경계

먼저 직접 의존성과 전이 의존성의 차이, 패키지 저장소의 우선순위, Lockfile의 역할을 이해한다. npm, PyPI, Maven 같은 공개 저장소와 사내 저장소가 만나는 지점이 중요한 신뢰 경계다. 버전을 고정해도 이미 악성인 버전을 고정할 수 있으므로 “고정했으니 안전하다”는 결론은 금물이다.

2단계: SBOM과 취약점 정보

소스 디렉터리와 최종 컨테이너 이미지에서 각각 SBOM을 만들어 차이를 비교한다. Syft는 디렉터리·이미지·아카이브에서 구성요소를 식별해 SPDX나 CycloneDX 형식으로 내보낼 수 있다. Grype, Trivy, OSV-Scanner는 이 구성요소를 알려진 취약점 정보와 대조하는 데 쓸 수 있다.

 

스캔 결과는 판결문이 아니라 조사 목록이다. 실행 경로에 도달하는지, 실제 배포 이미지에 포함됐는지, 보완 통제가 있는지 확인하고 예외에는 담당자·사유·만료일을 남겨야 한다.

3단계: 빌드 무결성과 SLSA

SLSA(Supply-chain Levels for Software Artifacts)는 공급망 보증을 단계적으로 높이는 사양이다. 2026년 9월 현재 승인된 SLSA 1.2의 Build Track은 Provenance 존재, 호스팅된 빌드 플랫폼이 생성한 서명된 Provenance, 강화된 빌드 환경으로 보증 수준을 나눈다.

 

처음부터 최고 수준을 선언하기보다 “어떤 위협을 막기 위해 어느 수준의 증거가 필요한가”를 정한다. CI 안에서 애플리케이션이 자기 자신에 대한 증명서를 마음대로 작성하게 하지 않고, 신뢰할 수 있는 빌드 제어 계층이 Provenance를 생성하는 이유도 여기 있다.

4단계: 서명과 검증

Sigstore의 Cosign은 OCI 이미지와 다른 산출물의 서명·검증, Attestation 작업에 사용한다. 중요한 것은 서명 명령보다 검증 정책이다. 배포 단계에서 신뢰할 발행자, OIDC 발급자, 저장소와 워크플로 조건을 확인하지 않으면 서명 파일이 있어도 승인 통제가 되지 않는다.

 

운영에서는 변경 가능한 태그보다 이미지 Digest를 기준으로 배포하고, 서명 검증이 실패하면 실행을 거부하도록 만든다. Kubernetes라면 Kyverno나 OPA Gatekeeper 같은 정책 엔진을 배포 게이트에 연결할 수 있다.

5단계: CI/CD와 대응 절차

워크플로 토큰은 기본 읽기 권한으로 시작하고 필요한 작업에만 쓰기 권한을 부여한다. 외부 CI 액션은 변경 가능한 태그보다 검토한 커밋 SHA로 고정하고, 장기 비밀키 대신 가능한 범위에서 짧은 수명의 자격증명을 사용한다.

 

마지막 공부 주제는 사고 대응이다. 새 CVE나 악성 패키지가 발견됐을 때 어떤 제품과 배포본이 영향을 받는지 SBOM으로 찾고, 수정 빌드를 만들고, 새 서명과 Provenance를 검증한 뒤 재배포하는 과정을 연습해야 한다.

도구는 역할별로 고른다

목적	도구·표준	잘하는 일	주의점
SBOM 생성	Syft, Trivy	디렉터리·이미지 구성요소 목록화	누락 여부와 생성 시점을 검증해야 함
SBOM 형식	SPDX, CycloneDX	조직·도구 사이 교환 가능한 표현	형식만 만들고 보관하지 않으면 쓸모가 작음
취약점 탐지	Grype, Trivy, OSV-Scanner	패키지와 알려진 취약점 매칭	실행 가능성·환경 맥락은 별도 판단
저장소 위생	OpenSSF Scorecard	브랜치 보호, 토큰 권한 등 휴리스틱 점검	총점 하나로 안전 여부를 판정하지 않음
서명·검증	Sigstore Cosign	OCI 산출물 서명과 신원 기반 검증	배포 지점의 검증 정책이 함께 필요
빌드 증명	SLSA, in-toto	빌드 입력·과정·산출물의 Provenance와 Attestation	선언과 실제 빌드 플랫폼 보증을 구분
배포 정책	Kyverno, OPA Gatekeeper	미서명·정책 위반 산출물 차단	비상 예외 절차와 감사 로그 필요

한 제품으로 표 전체를 채우려 하지 않는 편이 좋다. 예를 들어 Trivy가 여러 검사를 지원하더라도 SBOM 표준, 빌드 Provenance, 서명 신뢰 정책까지 자동으로 해결해 주는 것은 아니다.

4주 실습 프로젝트: 작은 컨테이너 하나를 끝까지 보호하기

학습용 프로젝트는 API 하나와 컨테이너 이미지 하나면 충분하다. 목표는 도구를 많이 설치하는 것이 아니라, 검증 가능한 증거와 차단 지점을 하나씩 추가하는 것이다.

1주차: 기준선 만들기

• 애플리케이션의 소스, 패키지 저장소, CI, 레지스트리, 배포 환경을 한 장에 그린다.
• 직접·전이 의존성과 베이스 이미지를 기록한다.
• 보호 브랜치, 리뷰 규칙, CI 토큰 권한과 외부 액션 고정 여부를 점검한다.
• 완료 기준: 임의의 변경이 어느 경로로 운영 이미지에 도달할 수 있는지 설명할 수 있다.

2주차: SBOM과 취약점 게이트

• Syft 또는 Trivy로 소스와 최종 이미지의 SBOM을 각각 생성한다.
• Grype, Trivy 또는 OSV-Scanner로 결과를 스캔한다.
• 심각도만 보지 말고 실제 포함 여부, 도달 가능성, 수정 버전과 예외 만료일을 기록한다.
• 완료 기준: 특정 패키지를 입력하면 어느 이미지와 서비스에 배포됐는지 찾을 수 있다.

3주차: 서명과 Provenance

• 이미지를 태그가 아닌 Digest로 식별한다.
• CI가 만든 이미지에 Cosign으로 서명하고, 별도의 검증 단계에서 발행자 조건을 확인한다.
• 빌드 입력과 빌더를 설명하는 SLSA Provenance 또는 in-toto Attestation을 보관한다.
• 완료 기준: 로컬에서 임의로 만든 같은 이름의 이미지는 검증을 통과하지 못한다.

4주차: 배포 차단과 사고 훈련

• 테스트 Kubernetes 클러스터에 미서명 이미지를 거부하는 정책을 적용한다.
• 정상 이미지, 미서명 이미지, 서명 후 변조된 이미지 세 가지를 배포해 결과를 비교한다.
• 취약 패키지 하나가 새로 공지됐다고 가정하고 영향 조회부터 수정·재서명·재배포까지 시간을 잰다.
• 완료 기준: 차단 로그와 승인 예외가 감사 가능한 형태로 남는다.

실습은 별도 테스트 저장소와 클러스터에서 진행한다. 공개 레지스트리에 비밀이나 내부 SBOM을 올리지 말고, 자동 수정 명령은 신뢰하지 않는 프로젝트에서 패키지 설치 스크립트를 실행할 수 있으므로 먼저 동작을 확인한다.

CI 파이프라인에 넣을 최소 게이트

처음에는 아래 순서만 구현해도 공급망의 연결이 보인다.

소스 검증
  → 의존성 설치와 테스트
  → 이미지 빌드
  → SBOM 생성
  → 취약점 정책 평가
  → 이미지 Digest 확정
  → 서명·Provenance 발행
  → 배포 전 신원·서명 검증
  → 승인된 Digest만 배포

스캔 실패를 모두 빌드 실패로 바꾸면 예외가 남발될 수 있다. 반대로 경고만 쌓으면 게이트가 아니다. 예를 들어 “악용 가능성이 확인된 치명적 취약점은 차단, 나머지는 기한이 있는 예외 티켓으로 관리”처럼 조직의 위험 기준을 기계가 판정할 수 있는 규칙으로 바꿔야 한다.

흔히 실패하는 방식

• SBOM을 한 번 만들고 끝낸다. 배포본과 연결하지 않으면 나중에 영향을 찾기 어렵다.
• 스캐너 점수만 믿는다. 패키지 출처, 빌드 변조와 계정 탈취는 별도의 통제가 필요하다.
• 이미지 태그를 신뢰한다. 태그는 바뀔 수 있으므로 Digest와 서명 검증이 필요하다.
• CI에 광범위한 권한을 준다. 빌드 시스템은 공급망의 강력한 허브이므로 최소 권한과 격리가 중요하다.
• 서명만 하고 검증하지 않는다. 정책 집행 지점이 없으면 서명은 참고 자료에 머문다.
• 예외에 만료일이 없다. 임시 허용이 영구 정책으로 굳는다.

현실적인 시작점

공급망 보안의 첫 목표는 “완벽한 제품”이 아니라 어떤 소스와 의존성이 어떤 빌드를 거쳐 현재 어디에 배포됐는지 증명할 수 있는 상태다. 그 위에 취약점 대응, 서명 검증과 배포 차단을 차례로 올린다.

 

이번 주에는 서비스 하나를 골라 소스와 최종 이미지의 SBOM을 만들고 차이를 비교해 보자. 다음 주에는 같은 이미지의 Digest를 고정하고 서명 검증을 붙인다. 마지막으로 미서명 이미지가 실제 배포 단계에서 거부되는지 확인한다. 이 세 단계가 연결되면 공급망 보안은 추상적인 구호가 아니라 반복 가능한 엔지니어링 절차가 된다.

공식 참고 자료

• NIST SP 800-161 Rev. 1: Cybersecurity Supply Chain Risk Management Practices
• NIST SP 800-218: Secure Software Development Framework 1.1
• SLSA 1.2 Build Track
• Sigstore Cosign 문서
• SPDX
• CycloneDX
• Syft 공식 저장소
• Grype 공식 저장소
• Trivy 공식 문서
• OSV-Scanner 공식 문서
• OpenSSF Scorecard 공식 저장소

카테고리: 일반IT/IT보안

 

태그: 공급망보안, 소프트웨어공급망, SBOM, SLSA, Sigstore, Cosign, DevSecOps