infiltr8 Lab

SLSA 빌드 트랙과 빌드 출처(provenance) 증명 분석

2026-09-06 · ##공급망-보안 ##빌드-무결성-개념

Security · 공급망 보안 · 빌드 무결성 개념 [정보성]

소프트웨어 공급망 공격의 상당수는 “어떤 소스 코드가 취약한가”가 아니라 “내가 받은 이 바이너리가 정말 내가 믿는 파이프라인에서, 손대지 않은 채로 만들어졌는가”라는 질문에서 갈립니다. 소스 저장소는 깨끗한데 빌드 서버가 오염돼 배포 산출물에 몰래 코드가 주입되면, 소스만 봐서는 알아낼 수 없습니다. SLSA는 이 “빌드 단계의 신뢰”를 레벨로 나눠 서술하고, 각 산출물이 어디서·언제·어떻게 만들어졌는지를 기계 검증 가능한 문서인 provenance로 남기게 합니다. 이 글은 특정 도구 사용법이 아니라, OpenSSF가 slsa.dev에 공개한 스펙이 정의한 개념을 우리 말로 정리하는 개념 정리본입니다.

핵심 사실 요약

SLSA는 무엇이고 누가 만드는가

SLSA는 공급망 보안을 서술하고 단계적으로 개선하기 위한 사양입니다. 현재는 OpenSSF(Open Source Security Foundation)가 유지·관리하는 프로젝트이며, 특정 벤더에 종속되지 않는 범산업(cross-industry) 협업으로서 커뮤니티 전문가 합의(community expert consensus)로 수립됐다고 공식 문서는 밝힙니다. v1.0은 2023년 4월 19일 OpenSSF가 릴리스를 발표했으며, SLSA의 첫 안정(stable) 릴리스입니다. (근거: OpenSSF 보도자료 · slsa.dev v1.0 스펙)

버전 주의 — 이 글의 레벨·provenance 개념은 v1.0 기준으로 정리했습니다. 다만 slsa.dev는 현재 v1.2를 최신 사양으로 서비스하며 v1.0은 “Retired(은퇴)” 상태로 표기합니다. 핵심 개념(레벨 체계·in-toto 기반 provenance·predicateType)은 v1.0과 v1.2 사이에서 실질적으로 동일하게 유지되지만, 세부 문구와 위협 라벨은 v1.2 기준으로 갱신됐을 수 있습니다. (근거: slsa.dev v1.0 levels · v1.2 build-track-basics)

v1.0의 가장 큰 변화 — “트랙(track)“으로 요구사항 분리

이전 버전인 v0.1은 하나의 레벨 안에 소스·빌드·provenance 요구사항을 한꺼번에 담았습니다. v1.0은 이 요구사항을 “트랙(track)“으로 분리해, 각 트랙이 공급망의 한 영역(빌드, 소스, 의존성 등)에만 집중하도록 재구성했습니다. 트랙의 목적은 한 영역에서의 진전을 무관한 다른 영역에 막히지 않고 인정받게 하려는 것입니다.

단, v1.0에는 Build(빌드) 트랙만 존재합니다. 소스(Source) 트랙, 빌드 레벨 4, 공통(common) 요구사항은 이후 버전으로 이연(deferred)됐습니다. (근거: slsa.dev whats-new · levels · OpenSSF 보도자료)

빌드 트랙 레벨 — L0부터 L3까지

빌드 트랙은 네 개의 레벨(L0~L3)로 구성됩니다.

  • L0 (No Guarantees) — 요구사항이 없고 보안 보증도 없습니다. 단일 머신에서 돌린 개발·테스트 빌드에 해당합니다.
  • L1 (Provenance Exists) — 생산자가 일관된 빌드 프로세스를 확립하고, 빌드 플랫폼·빌드 프로세스·최상위(top-level) 입력을 서술하는 provenance가 존재해 소비자에게 배포됩니다. 실수 방지와 디버깅이 목적이며, 위변조 방지(tamper protection)는 제공하지 않습니다 — provenance가 불완전하거나 서명되지 않아도 L1을 충족할 수 있습니다.
  • L2 (Hosted Build Platform) — L1에 더해, 빌드가 개인 워크스테이션이 아닌 전용 인프라(호스팅된 빌드 플랫폼)에서 실행되고, provenance가 디지털 서명으로 그 인프라에 묶입니다. 그 결과 빌드 이후(after the build)의 위변조를 막을 수 있습니다.
  • L3 (Hardened Builds) — L2에 더해, 빌드 플랫폼이 실행 간 상호 영향을 막고(격리/isolation), 사용자 정의 빌드 스텝이 비밀 자재(secret material)에 접근하지 못하게 방지합니다. 그 결과 빌드 도중(during the build)의 위변조와 내부자 위협·자격증명 탈취에 대한 방어를 제공합니다.

빌드 트랙의 L1L3은 v0.1 시절의 레벨 13에 “대략 대응”하되 소스 관련 요구사항이 빠진 형태입니다. (근거: slsa.dev levels · whats-new · Cycode)

Provenance — 빌드 출처 증명이 뼈대다

provenance는 소프트웨어 아티팩트를 어디서·언제·어떻게 만들었는지를 서술하는 검증 가능한 정보입니다. 무엇이(어떤 엔티티), 어떤 프로세스로, 어떤 입력으로 만들었는지를 기술합니다.

형식은 in-toto attestation 프레임워크를 기반으로 하며, JSON(lowerCamelCase)으로 직렬화되고 Protocol Buffer 스키마도 제공됩니다. provenance의 predicateType은 https://slsa.dev/provenance/v1입니다. predicate는 두 핵심 구획으로 나뉩니다.

  • BuildDefinition — 무엇을 어떻게 빌드했는가.
    • buildType: 빌드 방식을 정의하는 템플릿.
    • externalParameters: 사용자/테넌트가 제어하는 값. 신뢰할 수 없으므로 검증 대상입니다.
    • internalParameters: 플랫폼이 설정하는 값(신뢰됨).
    • resolvedDependencies: 빌드 중 가져온 아티팩트.
  • RunDetails — 실제 실행이 어떻게 일어났는가.
    • builder: 신뢰되는 빌드 플랫폼의 신원/구성요소.
    • metadata: invocation ID, 시작/종료 타임스탬프 등.
    • byproducts: 로그 같은 부가 산출물.

특히 builder.id는 “빌드를 충실히 실행하고 provenance를 기록한다고 신뢰되는 모든 엔티티의 전이 폐쇄(transitive closure)“로 정의되며, 공식 스펙은 이것을 SLSA 빌드 레벨을 결정하는 유일한 기준이라고 명시합니다. 즉 “누구를 빌더로 신뢰하는가”가 레벨을 좌우합니다.

v1.0의 또 다른 진전은 provenance를 생성하는 법뿐 아니라 배포(distributing)·아티팩트 검증(verifying)·빌드 플랫폼 검증에 대한 가이드가 추가됐다는 점입니다. v0.1은 생성법만 있고 검증법이 비어 있던 공백을 메웠습니다. (근거: slsa.dev provenance · whats-new · Cycode)

위협 모델 — SLSA가 다루는 것과 다루지 않는 것

SLSA는 공급망 위협을 크게 소스(source) 위협 / 빌드(build) 위협 / 의존성(dependency) 위협의 세 범주로 정리합니다. 그리고 공식 위협 페이지는 SLSA가 직접 완화하지 못하는 범위 밖(out-of-scope) 항목도 명시합니다 — 타이포스쿼팅(typosquatting), 악의적 생산자(malicious producer) 자체, 소셜 엔지니어링·공모·형식적 승인(“rubber stamping”) 리뷰, 런타임 의존성, 가용성(availability) 위협, SCM 취약점 익스플로잇 등입니다. 즉 SLSA는 “빌드·출처의 무결성”을 보증하는 프레임워크이지, 공급망의 모든 위협을 덮는 만능 대책이 아닙니다.

⚠️미확인 — 공식 위협 페이지가 위협을 몇 개의 “버킷”으로 나누고 각 버킷에 어떤 문자 라벨(A, B, C…)을 붙이는지는 스펙 버전마다 달라질 수 있어, 이 글은 정확한 버킷 개수·문자 매핑을 단정하지 않고 “소스/빌드/의존성 3대 범주”라는 상위 개념으로만 서술합니다. 세부 라벨은 slsa.dev의 해당 버전 threats 페이지로 재확인해야 합니다. (근거: slsa.dev v1.2 threats)

⚠️미확인 — “SLSA L2였다면 특정 과거 사건(예: 빌드 파이프라인 오염형 공급망 침해)을 탐지했을 것”이라는 식의 주장은 1차출처의 단정이 아니라 분석적(2차) 해석입니다. “provenance 서명 검증이 있었다면 서명 없는 주입 코드가 거부됐을 것”이라는 가정적 서술로만 유효하며, 사실로 단정하지 않습니다.

⚠️미확인 — v1.0에서 빌드 레벨 4가 제거·이연된 것은 확실하나, 그것이 향후 어떤 형태로 재도입될지에 대한 로드맵은 유동적입니다(2차출처 언급). 확정된 계획으로 서술하지 않습니다.

대응 관점 — 실무에 옮기면

  • 먼저 provenance를 만드세요(L1). 산출물마다 “어떤 플랫폼에서, 어떤 프로세스로, 어떤 입력으로 만들었는지”를 기록하는 것이 출발점입니다. 서명이 없어도 L1은 시작할 수 있고, 실수 방지·디버깅만으로도 값어치가 있습니다.
  • 개인 머신 빌드를 벗어나세요(L2). 호스팅된 전용 빌드 플랫폼에서 빌드하고 provenance에 디지털 서명을 붙이면, 배포 이후 산출물이 바꿔치기됐는지 소비자가 검증할 수 있습니다(“빌드 이후” 위변조 방지).
  • 빌드 환경을 격리하세요(L3). 실행 간 격리와 비밀 자재 접근 차단으로 “빌드 도중” 주입·자격증명 탈취를 막습니다. 여기까지가 v1.0 빌드 트랙의 최상위입니다.
  • 생성만 하지 말고 검증하세요. provenance는 만들어 두는 것만으로는 의미가 없고, 소비 측에서 서명·빌더 신원·external parameters를 실제로 검증해야 방어가 됩니다. builder.id(신뢰하는 빌더의 전이 폐쇄)를 무엇으로 잡느냐가 레벨의 실효를 좌우합니다.
  • SLSA로 못 막는 것을 별도로 다루세요. 타이포스쿼팅·악의적 생산자·리뷰 공모·런타임 의존성 등은 SLSA 범위 밖입니다 — provenance/SBOM/코드리뷰 등 다른 통제와 함께 써야 합니다.

짧은 논평

SLSA의 핵심은 “믿을 수 있는 소스 코드”에서 “믿을 수 있는 빌드”로 신뢰의 경계를 한 칸 넓힌 데 있습니다. 우리 랩이 공급망 사건을 볼 때 반복해서 마주치는 지점도 같습니다 — 저장소는 멀쩡한데 산출물이 오염되는 순간, 방어자가 기댈 수 있는 건 “이 바이너리가 정말 그 파이프라인에서 나왔다”를 검증 가능한 형태로 남겨둔 provenance뿐입니다. 다만 provenance는 산출물의 성분표인 SBOM과는 다른 문서라는 점(무엇이 들어 있나 ↔ 어떻게 만들어졌나), 그리고 SLSA가 공급망의 모든 위협을 덮지는 않는다는 점을 함께 기억하는 편이 안전합니다. 레벨은 사다리이지 결승선이 아닙니다 — L1의 “일단 남긴다”부터 시작해도, 다음 침해 때 “어디서 왔는지조차 모른다”는 상황은 면할 수 있습니다.

References / 참고자료

1차출처 (공식)

  1. OpenSSF (slsa.dev), “Security levels” (SLSA v1.0), 빌드 트랙 L0~L3의 정의·위변조 방지 시점(빌드 이후/도중)의 1차 근거 — https://slsa.dev/spec/v1.0/levels
  2. OpenSSF (slsa.dev), “What’s new in SLSA v1.0”, 트랙 분리·v0.1 대비 변화·빌드 트랙만 존재·검증 가이드 추가의 근거 — https://slsa.dev/spec/v1.0/whats-new
  3. OpenSSF (slsa.dev), “Provenance”, in-toto 기반·predicateType·BuildDefinition/RunDetails·builder.id가 레벨을 결정한다는 서술의 근거 — https://slsa.dev/spec/v1.0/provenance
  4. OpenSSF (slsa.dev), “Threats & mitigations” (v1.2), 소스/빌드/의존성 범주와 out-of-scope 항목의 근거 — https://slsa.dev/spec/v1.2/threats
  5. OpenSSF, “OpenSSF Announces SLSA Version 1.0 Release” (2023-04-19), 릴리스 날짜·거버넌스(OpenSSF 프로젝트·커뮤니티 전문가 합의)의 근거 — https://openssf.org/press-release/2023/04/19/openssf-announces-slsa-version-1-0-release/
  6. OpenSSF (slsa.dev), “SLSA 홈”, 명칭·발음(“Supply-chain Levels for Software Artifacts, or SLSA (“salsa”)”)·벤더 중립 거버넌스의 근거 — https://slsa.dev/
  7. OpenSSF (slsa.dev), “SLSA specification (v1.0)” 개요, 사양 성격의 근거 — https://slsa.dev/spec/v1.0/

2차 / 독립 분석 8. Cycode, “SLSA 1.0: Improving Software Supply Chain Security”, v1.0 변화·provenance 배포/검증·로드맵 언급의 보조 출처(2차) — https://cycode.com/blog/slsa-1-0-improving-software-supply-chain-security/

이 글은 위 공개 문서·분석을 우리 관점에서 다시 쓰고 정리한 것입니다. 특정 문장·표를 그대로 옮기지 않았으며, 정확한 규범 문구·필드 정의·버전 상태는 slsa.dev 1차 스펙(현재 최신 v1.2)을 참고하세요. 정보성 티어 글로, 원본 소스코드 분석이나 패치 대조는 수행하지 않았으며, ⚠️미확인 표기 항목(위협 버킷 라벨·개수, 과거 사건 탐지 가정, 빌드 레벨 4 로드맵 등)은 3중 팩트체크에서 1차 원문으로 재확인 대상입니다.