wikiline.dev
·
Wikiline › 소프트웨어 공급망 보안 (Software Supply Chain Security) › 빌드 출처 증명과 서명 (Build Provenance & Signing — SLSA·Sigstore)

빌드 출처 증명과 서명 (Build Provenance & Signing — SLSA·Sigstore)

타임라인 5건업데이트 0건갱신 2026-09-27별칭: SLSA, Sigstore, cosign, 빌드 프로버넌스, Supply-chain Levels for Software Artifacts, keyless signing

한 줄 정의

SBOM (Software Bill of Materials, 소프트웨어 자재명세서)이 "안에 뭐가 들었나"를 적는 목록이라면, 이쪽은 "이 파일이 정말 주장하는 소스 코드·빌드 과정에서 나왔다"는 것을 암호학적으로 증명하는 기술입니다. SLSA는 그 신뢰 수준을 나누는 프레임워크, Sigstore는 실제로 서명·검증하는 무료 공개 인프라입니다.

지금 상태 (2026-09 기준)

2020년 설립된 OpenSSF(Linux Foundation 산하)가 이 분야 표준화를 주도해왔습니다. Sigstore는 2022-10 정식 서비스(GA)로 전환해 개인이 비밀키를 관리할 필요 없이 신원(OIDC) 기반으로 서명하는 "keyless signing"을 실용화했고, SLSA는 2023-04 v1.0으로 빌드·소스·의존성을 별도 트랙으로 나누는 체계를 확정했습니다. npm(2023-05)과 GitHub Actions(2024-06 GA)가 각각 패키지·아티팩트에 출처 증명을 자동 첨부하는 기능을 내놓으면서, 개념 검증 단계를 지나 실제 배포 파이프라인에 들어오는 중입니다.

개념

  • SLSA(Supply-chain Levels for Software Artifacts): "이 빌드가 얼마나 신뢰할 수 있게 만들어졌는가"를 단계(레벨)로 나눠 정의하는 프레임워크. v1.0(2023)부터는 하나의 레벨 체계 대신 Build 트랙을 시작으로 영역별 트랙으로 나뉩니다.
  • Provenance(빌드 출처 증명): "이 아티팩트는 이 소스 커밋에서, 이 빌드 시스템으로, 이 시각에 만들어졌다"를 서명된 메타데이터로 남기는 것. SLSA가 정의하는 핵심 산출물입니다.
  • Sigstore / Fulcio / Rekor: Sigstore는 서명 인프라 전체를, Fulcio는 짧은 수명의 서명 인증서를 발급하는 인증기관을, Rekor는 서명 기록을 남기는 공개 투명성 로그를 가리킵니다.
  • Keyless signing: 개발자가 장기 보관용 개인키를 직접 관리하는 대신, GitHub Actions 같은 CI의 OIDC 토큰으로 신원을 증명받아 그때그때 단기 인증서를 발급받아 서명하는 방식. 키 유출·분실 위험을 크게 줄입니다.

벤더별 비교

구분 SLSA (OpenSSF) Sigstore (OpenSSF) GitHub Artifact Attestations
무엇을 하나 빌드 과정의 신뢰 수준을 트랙·레벨로 정의하는 프레임워크(표준) 코드·아티팩트에 서명·검증하는 무료 공개 인프라 GitHub Actions로 만든 아티팩트에 SLSA 수준 출처 증명을 자동 첨부하는 기능
정식 출시(GA/1.0) v1.0 2023-04-19 GA 2022-10-25 GA 2024-06-25
확인된 채택 사례 npm이 2023-05부터 SLSA Build L2/L3 provenance 생성 지원 Kubernetes·Python 등이 공식 릴리스 서명에 채택(Sigstore GA 발표 기준) GitHub 저장소에서 만든 릴리스 아티팩트

잘 쓰는 법

  • 중요한 의존성을 설치하기 전, provenance가 첨부돼 있다면 실제로 주장하는 소스·빌드 워크플로우와 일치하는지 검증합니다(npm audit signatures, cosign verify 등).
  • 내부 CI/CD 파이프라인을 만들 때 SLSA 레벨을 목표치로 정하고, keyless signing을 도입해 서명 키 관리 부담과 유출 위험을 줄입니다.
  • provenance가 "있다"는 사실만으로 안전을 보장하지 않습니다 — provenance는 "누가 만들었는지"를 증명할 뿐, 그 소스 코드 자체에 악성 코드가 없다는 것까지 보장하지는 않습니다.
  • 다운로드 수·평판만으로 패키지를 신뢰하지 말고, SBOM (Software Bill of Materials, 소프트웨어 자재명세서)과 provenance를 함께 확인하는 습관을 들입니다.

타임라인

2020-08-03 · OpenSSF 출범

  • 이전 대비: 최초 — 이후 SLSA·Sigstore가 이 재단 산하 프로젝트로 개발되는 출발점
  • Linux Foundation이 GitHub·Google·IBM·Microsoft 등과 함께 Core Infrastructure Initiative를 비롯한 여러 오픈소스 보안 활동을 통합해 Open Source Security Foundation(OpenSSF)을 설립
  • 출처: Technology and Enterprise Leaders Combine Efforts to Improve Open Source Security

2022-10-25 · Sigstore 정식 서비스(GA) 전환

2023-04-19 · SLSA v1.0 발표

  • 이전 대비: 단일 레벨 체계였던 이전 버전과 달리, 빌드·소스·의존성별로 트랙을 나누는 구조로 재설계
  • OpenSSF가 커뮤니티 합의로 SLSA v1.0을 발표. Build 트랙을 시작으로 소프트웨어 전달 생명주기의 다른 영역까지 단계적으로 확장하겠다고 명시
  • 출처: OpenSSF Announces SLSA Version 1.0 Release

2023-05-11 · npm provenance attestation 베타

  • 이전 대비: SLSA·Sigstore가 표준·인프라 수준에 머물던 것에서, 대중적 패키지 레지스트리에 실제 기능으로 처음 통합
  • npm CLI와 npmjs.com에 SLSA Build Level 2 provenance를 생성·업로드하는 기능이 공개 베타로 추가됨. 동시에 GitHub Actions용 SLSA3 Node.js 빌더 베타도 함께 발표
  • 출처: Bringing Improved Supply Chain Security to the Node.js Ecosystem

2024-06-25 · GitHub Artifact Attestations GA

  • 이전 대비: npm 패키지에 한정됐던 provenance 기능이, GitHub Actions로 만드는 모든 아티팩트로 범위가 넓어짐
  • 2024-05 공개 베타를 거쳐, GitHub Actions로 빌드한 아티팩트에 서명된 빌드 출처 증명을 자동으로 첨부·검증하는 Artifact Attestations 기능이 정식 출시(GA)됨
  • 출처: Artifact Attestations is generally available

출처

관련 주제

SBOM (Software Bill of Materials, 소프트웨어 자재명세서)오픈소스 패키지 공급망 공격 (Open Source Package Supply Chain Attacks)