소프트웨어 공급망 보안 2026, SLSA·SBOM·서명·릴리스 운영 기준

소프트웨어 공급망 보안을 점검하는 코드 리뷰와 릴리스 보안 운영 장면 — 소프트웨어 공급망 보안은 코드 저장소, 빌드 시스템, 패키지, 서명, 배포 승인을 하나의 증거 흐름으로 묶는 일이다.

소프트웨어 공급망 보안을 검색하는 팀은 대개 취약한 오픈소스 하나를 찾으려는 단계가 아니다.

이미 CI/CD, 패키지 저장소, 컨테이너 이미지, 외주 개발 산출물, SaaS 배포 경로가 섞였고 어느 지점에서 릴리스가 바뀌는지 확인해야 하는 단계다.

SLSA 문서는 공급망 보안을 점진적으로 높이는 명세이며, 수준이 올라갈수록 빌드 증거와 무결성 보장이 강해진다고 설명한다.

이 글은 특정 도구 홍보가 아니라 릴리스 전에 무엇을 증명해야 하는지 정리하는 실무 점검 메모다.

핵심 요약

소프트웨어 공급망 보안은 의존성 스캔만으로 끝나지 않고 소스, 빌드, 산출물, 서명, 배포 승인을 연결해야 한다.
SLSA는 Build L1부터 L3까지 provenance 존재, 진정성, 위조 방지, 빌드 격리 수준을 단계적으로 요구한다.
SBOM은 목록이고 provenance는 누가 어떤 빌드 정의로 산출물을 만들었는지 보여주는 증거다.
도입은 전사 차단보다 상위 20개 저장소와 고객 배포 산출물부터 시작해야 운영 반발이 적다.

이 글이 필요한 사람

CI/CD 파이프라인은 많지만 릴리스 산출물과 소스 커밋의 연결 증거가 약한 플랫폼 엔지니어
SBOM 생성은 시작했지만 서명, provenance, 배포 승인까지 한 흐름으로 묶지 못한 보안 담당자
외주 개발물, 오픈소스 패키지, 컨테이너 이미지, 내부 라이브러리의 책임 경계를 구분해야 하는 구매 담당자
GitHub Actions, GitLab CI, Jenkins, 클라우드 빌드가 섞여 있어 공통 릴리스 게이트가 필요한 DevSecOps 팀
고객사 보안 질의서에서 SLSA, SBOM, 코드서명, 취약점 대응 증거를 반복해서 요구받는 B2B SaaS 운영팀

소프트웨어 공급망 보안은 의존성 목록보다 넓다

의존성 취약점만 보면 공급망 보안의 절반을 놓친다.

공격자는 패키지 이름을 속이거나 빌드 스크립트를 바꾸거나 릴리스 파일을 교체하거나 배포 토큰을 훔칠 수 있다.

SLSA provenance 문서는 산출물이 어디서, 언제, 어떻게 만들어졌는지 설명하는 검증 가능한 정보가 필요하다고 정의한다.

이 정의를 실무로 옮기면 저장소 보호, 빌드 플랫폼 신뢰, SBOM, 서명, 배포 승인 로그가 각각 따로 놀면 안 된다.

먼저 확인할 것은 도구 수가 아니라 릴리스 한 건을 소스 커밋까지 되짚을 수 있는지다.

이 조건이면 보안팀은 스캐너 대시보드보다 release evidence 표를 먼저 만들어야 한다.

공식 문서 기준 핵심 사실

SLSA v1.1은 공급망 보안을 설명하고 점진적으로 높이기 위한 명세이며, provenance 같은 권장 attestation 형식을 함께 제시한다.
SLSA requirements 문서는 Build L1, L2, L3를 구분하고 provenance 존재, 진정성, 위조 방지, 호스티드 빌드, 격리 빌드를 단계별 요구로 둔다.
SLSA provenance 문서는 predicateType 문자열을 https://slsa.dev/provenance/v1 로 사용하라고 안내한다.
SLSA provenance 모델은 builder.id, buildType, externalParameters, internalParameters, resolvedDependencies, subject 같은 항목으로 빌드 사실을 설명한다.
OpenSSF Scorecard는 오픈소스 프로젝트의 여러 보안 휴리스틱을 검사하고 각 check에 0점부터 10점까지 점수를 부여한다고 설명한다.
GitHub Docs는 의존성 보안, provenance와 integrity, immutable releases, SBOM export, linked artifacts 같은 공급망 보안 기능을 분리해 안내한다.
Sigstore는 release file, container image, binary, SBOM 같은 산출물을 서명하고 검증하는 오픈소스 프로젝트라고 설명한다.
in-toto Attestation Framework는 소프트웨어가 어떻게 만들어졌는지 검증 가능한 claim을 생성하는 명세를 제공한다고 설명한다.
NIST SP 800-218 SSDF Version 1.1은 취약점 수를 줄이고 취약점 악용 영향을 완화하기 위한 보안 개발 프레임워크다.
CISA Secure by Design은 제품 보안을 핵심 비즈니스 요구로 두고 MFA, logging, SSO 같은 기능을 기본 보안 역량으로 다룬다.

공식 문서가 가리키는 방향은 하나다.

소프트웨어 공급망 보안은 검사 결과 파일이 아니라 산출물의 출처를 검증하는 운영 절차다.

SBOM, SLSA, 서명, 스캐너를 같은 말로 쓰면 안 된다

구분	답하는 질문	강한 지점	먼저 볼 한계	운영 판단
SBOM	이 산출물에 어떤 구성요소가 들어 있는가.	오픈소스 의존성, 라이브러리, 라이선스, 취약점 영향 범위를 추적한다.	누가 어떤 빌드로 만들었는지는 SBOM만으로 충분하지 않다.	고객 배포 산출물과 컨테이너 이미지부터 생성한다.
SLSA provenance	이 산출물은 어떤 소스와 빌드 정의로 만들어졌는가.	빌드 플랫폼, 입력값, 의존성, 산출물 주체를 증거로 남긴다.	검증 게이트가 없으면 증거 파일만 쌓이고 배포는 그대로 통과한다.	릴리스 승인 전에 provenance 검증을 넣는다.
서명·검증	릴리스 파일이 배포 뒤 바뀌지 않았는가.	산출물 변조, 이미지 교체, 배포 저장소 침해를 탐지하기 쉽다.	서명 키와 OIDC identity 관리가 약하면 신뢰 경계가 흐려진다.	고객 제공 binary와 container image부터 적용한다.
Scorecard·스캐너	저장소와 의존성 관리 습관이 위험한가.	branch protection, token permission, dangerous workflow 같은 습관을 찾는다.	aggregate score만 보면 실제 릴리스 위험을 놓칠 수 있다.	개별 check 실패를 정책 항목으로 바꾼다.
SSDF·Secure by Design	조직의 개발 프로세스가 보안 책임을 담고 있는가.	보안 요구, 취약점 대응, 구매자와 공급자 대화 기준을 제공한다.	문서만 만들면 빌드와 배포 현장 증거가 남지 않는다.	계약서와 내부 개발 표준의 기준선으로 쓴다.

이 표를 회의 첫 장에 놓으면 도구 이름 경쟁이 줄어든다.

SBOM은 구성요소 투명성이고 SLSA provenance는 생성 과정 증거이며 서명은 배포 뒤 변경 여부를 확인하는 장치다.

운영 리소스 단위는 숫자로 분리한다

소프트웨어 공급망 보안의 도입 비용은 견적서보다 리뷰 시간, 저장소 수, 산출물 수에서 더 크게 흔들린다.

SLSA Build L1부터 L3까지 한 번에 노리면 빌드 플랫폼 교체와 검증 게이트 변경이 동시에 생긴다.

처음에는 상위 20개 저장소, 고객 배포 10개 산출물, 최근 90일 릴리스부터 기준선을 잡는 편이 안전하다.

운영 항목	공식 근거와 숫자	견적·인력 질문	실무 판단
SLSA 단계	SLSA requirements는 Build L1, L2, L3 요구를 나누고 provenance 존재와 진정성, 위조 방지, 격리 수준을 구분한다.	우리 빌드 플랫폼은 L2 수준의 authentic provenance를 낼 수 있는가.	처음부터 L3를 목표로 삼기보다 고객 배포 산출물 L2를 먼저 본다.
Scorecard 기준	OpenSSF Scorecard는 각 check에 0점부터 10점까지 점수를 부여한다고 설명한다.	aggregate score가 아니라 실패 check 5개를 릴리스 정책으로 바꿀 owner가 있는가.	점수 평균보다 branch protection과 token permission 실패를 우선 고친다.
초기 범위	초기 점검은 상위 20개 저장소와 고객 배포 10개 산출물을 30일 안에 끝내는 방식으로 잡는다.	보안팀 1명과 플랫폼팀 1명이 매주 4시간 이상 증거를 정리할 수 있는가.	범위가 넓으면 스캐너만 켜고 검증 게이트는 미뤄지는 패턴이 나온다.
릴리스 증거 보존	최근 90일 릴리스의 provenance, SBOM, signature, 승인 티켓을 같은 위치에서 조회하게 만든다.	감사나 고객 질의서에 48시간 안에 증거를 낼 수 있는가.	증거 보존 위치가 흩어지면 도구 도입 뒤에도 답변 시간이 줄지 않는다.
예외 승인	위험 예외는 owner, ticket, expiry_days 30일, 재검토 일정을 필수값으로 둔다.	예외가 30일 뒤 자동 리뷰 목록으로 올라오는가.	만료 없는 예외는 공급망 보안 정책을 우회로 바꾼다.

이 표의 목적은 정확한 구매가를 맞히는 일이 아니다.

조직이 감당할 저장소 수, 산출물 수, 리뷰 시간, 증거 보존 기간을 먼저 숫자로 고정하는 일이다.

도입 순서는 상위 저장소와 고객 배포물부터 잡는다

전사 저장소 전체에 정책을 한 번에 적용하면 예외 티켓이 폭발한다.

먼저 매출과 고객 배포에 직접 연결되는 저장소를 고르고 해당 저장소의 릴리스 증거를 끝까지 연결한다.

GitHub Docs는 provenance와 integrity 범위에서 immutable releases, SBOM export, linked artifacts를 분리해 안내한다.

이 흐름을 실무에 맞추면 저장소 보호, SBOM export, linked artifact, 서명 검증, 배포 승인 티켓이 한 줄로 이어져야 한다.

최근 90일 동안 고객에게 배포된 binary, container image, package, SaaS release 목록을 뽑는다.
각 산출물의 source repository, commit, branch, tag, CI run id, artifact registry 위치를 연결한다.
상위 20개 저장소에 branch protection, reviewer 2명 이상, CODEOWNERS, token permission 기본값을 확인한다.
SBOM은 고객 배포 산출물과 container image부터 SPDX 또는 CycloneDX 중 한 형식으로 고정한다.
SLSA provenance는 build platform, buildType, externalParameters, resolvedDependencies, subject가 비어 있지 않은지 본다.
서명은 keyless 또는 OIDC 기반 identity를 우선 검토하고 장기 키를 쓴다면 보관 owner와 rotation 주기를 정한다.
릴리스 게이트는 서명 검증, provenance builder 검증, source repository 검증, SBOM 존재 검증을 최소 조건으로 둔다.
고객 보안 질의서에 48시간 안에 제출할 release evidence bundle 위치를 정한다.
예외는 30일 만료와 재승인 owner를 요구하고 배포 뒤 자동 리뷰 목록으로 보낸다.
월 1회 실패 check와 예외 목록을 플랫폼팀, 보안팀, 서비스 owner가 같이 리뷰한다.

실무 시나리오 1: B2B SaaS 릴리스 파이프라인

실무 시나리오 1은 고객사가 SBOM과 코드서명 증거를 요구하는 B2B SaaS 회사다.

이 경우는 모든 내부 저장소보다 고객 배포 artifact가 있는 10개 저장소를 먼저 고른다.

릴리스마다 commit, CI run, SBOM, signature, provenance, deployment approval이 같은 ticket에서 조회돼야 한다.

이 조건이면 공급망 보안 도입 성공 기준은 스캐너 대시보드 점수가 아니라 고객 질의서 답변 시간이 48시간 안쪽으로 줄었는지다.

SBOM 생성만 끝난 상태라면 다음 단계는 서명 검증을 배포 게이트로 넣는 일이다.

실무 시나리오 2: 외주 개발물과 오픈소스 의존성이 섞인 조직

실무 시나리오 2는 외주 개발물, 내부 패키지, 공개 오픈소스가 한 서비스 안에 섞인 조직이다.

이 경우는 공급사 보안 설문보다 납품 산출물의 증거 파일을 먼저 요구해야 한다.

외주 산출물에는 source hash, build instruction, SBOM, 취약점 스캔 결과, 서명 여부, 재빌드 가능성 확인이 필요하다.

이 조건이면 계약서에 SBOM 형식과 취약점 대응 SLA를 넣고 납품 acceptance gate에서 증거 파일 누락을 막아야 한다.

오픈소스 의존성은 Scorecard aggregate score보다 maintainer activity, branch protection, release signing, dangerous workflow 여부를 따로 본다.

SLSA를 목표가 아니라 릴리스 질문으로 바꾼다

SLSA L3라는 표어만 걸면 개발팀은 구체적으로 무엇을 바꿔야 하는지 알기 어렵다.

질문을 바꿔야 한다.

우리 artifact의 builder.id는 무엇이고, buildType은 어떤 템플릿이며, 외부 입력값은 누가 검증하는가를 묻는다.

SLSA provenance 문서가 externalParameters를 untrusted로 보고 downstream verification 대상으로 둔다는 점도 여기서 중요하다.

즉 빌드 입력값을 기록하는 것과 그 입력값을 배포 전에 검증하는 일은 별개다.

릴리스 질문	증거 위치	실패하면 생기는 위험	owner
이 artifact의 source commit은 무엇인가.	CI metadata와 release tag	릴리스 파일이 어떤 코드에서 왔는지 설명하지 못한다.	플랫폼팀
이 artifact의 builder.id는 신뢰할 수 있는가.	SLSA provenance와 빌드 플랫폼 설정	개인 runner나 임시 runner에서 만들어진 산출물이 섞인다.	DevOps팀
외부 입력값은 검증됐는가.	provenance externalParameters와 policy gate	workflow_dispatch 입력이나 tag 변조가 배포로 이어진다.	보안팀
SBOM과 취약점 결과는 artifact 버전과 연결됐는가.	SBOM repository와 vulnerability report	취약점 영향 범위를 고객 배포 버전 기준으로 찾지 못한다.	서비스 owner
서명과 검증은 배포 전에 끝났는가.	signature, transparency log, deployment gate	저장소 침해 뒤 바뀐 image를 그대로 배포할 수 있다.	플랫폼팀

Scorecard는 점수보다 실패 check가 중요하다

OpenSSF Scorecard는 여러 보안 휴리스틱에 0점부터 10점까지 점수를 주지만 aggregate score만으로 정책을 만들면 위험하다.

프로젝트마다 필요한 control이 다르고 일부 check는 환경에 따라 false positive가 나올 수 있기 때문이다.

실무에서는 score를 구매 승인 숫자로 쓰기보다 실패 check를 저장소 정책 backlog로 바꾸는 편이 낫다.

예를 들어 branch protection 실패는 release branch rule로 바꾸고 dangerous workflow 실패는 pull_request_target 사용 검토로 바꾼다.

token permission 실패는 CI 기본 권한을 read-only로 낮추는 작업으로 연결한다.

이 조건이면 Scorecard는 평가표가 아니라 저장소 hygiene backlog를 만드는 입력값이다.

서명과 provenance는 배포 게이트에서 검증해야 의미가 있다

서명 파일과 provenance 파일을 생성만 하면 감사 폴더가 하나 더 생긴다.

배포 게이트가 signature, builder.id, source repository, dependency allowlist를 확인해야 공격 표면이 줄어든다.

Sigstore 문서는 Cosign, Fulcio, Rekor 흐름을 통해 artifact가 서명되고 identity와 연결되며 투명성 로그로 감사 가능해진다고 설명한다.

이 구조는 장기 개인 키를 모든 개발자에게 배포하는 방식보다 운영 부담을 줄일 수 있다.

다만 OIDC issuer, repository owner, workflow identity를 검증하지 않으면 keyless signing도 신뢰 경계가 흐려진다.

배포 시스템은 서명 존재가 아니라 어떤 identity가 어떤 workflow에서 어떤 artifact를 만들었는지 확인해야 한다.

릴리스 정책 스켈레톤

아래 YAML은 실제 제품 설정이 아니라 공급망 보안 도입 회의에서 빠진 항목을 찾는 정책 스켈레톤이다.

# supply-chain-release-policy.yml
# 목적: 릴리스 전에 소스, 빌드, 산출물, 증명서, 배포 승인자를 한 줄로 연결한다.
# 실제 적용 전에는 조직의 CI/CD, 패키지 저장소, 클라우드 배포 환경에 맞게 수정한다.

release_policy:
  protected_branches:
    - main
    - release/*
  required_reviewers: 2
  minimum_scorecard_checks:
    branch_protection: pass
    dependency_update_tool: pass
    token_permissions: read_only_by_default
    dangerous_workflow: block
  slsa_target:
    build_level: L2_first
    provenance_required: true
    provenance_predicate_type: https://slsa.dev/provenance/v1
  sbom:
    format: spdx_or_cyclonedx
    required_for:
      - container_image
      - binary_release
      - customer_deployed_package
  signing:
    artifact_signing: required
    key_model: oidc_or_ephemeral_key_preferred
    transparency_log_check: required
  deployment_gate:
    verify_signature: required
    verify_provenance_builder: required
    verify_source_repository: required
    verify_dependency_allowlist: required
  exception:
    owner: security_engineer
    expiry_days: 30
    ticket_required: true
    customer_notice_required_if_public_artifact: true

이 스켈레톤의 핵심은 릴리스 policy가 스캐너 결과 한 줄이 아니라 증거 묶음이라는 점이다.

예외 승인에 만료일과 ticket이 없으면 다음 분기에는 모든 배포가 예외로 통과한다.

증거 누락을 자동으로 찾는 점검 예시

소프트웨어 공급망 보안은 사람이 매번 체크리스트를 읽는 방식으로 오래 가지 않는다.

아래 Python 예시는 릴리스 증거 파일이 빠진 항목을 점수로 찾는 검증용 스켈레톤이다.

# verify_release_evidence.py
# 목적: 특정 벤더 인터페이스가 아니라 릴리스 증거 파일이 빠졌는지 확인하는 검증용 스켈레톤이다.
# 실제 운영에서는 artifact registry, CI 로그, SBOM 저장소, 서명 검증 결과를 입력으로 연결한다.

REQUIRED = {
    "source_repo": 10,
    "protected_branch": 10,
    "reviewer_count_at_least_2": 10,
    "ci_run_id": 10,
    "slsa_provenance": 15,
    "sbom_file": 10,
    "artifact_signature": 15,
    "dependency_scan_result": 10,
    "deployment_approval": 5,
    "exception_ticket": 5,
}

release = {
    "source_repo": True,
    "protected_branch": True,
    "reviewer_count_at_least_2": True,
    "ci_run_id": True,
    "slsa_provenance": False,
    "sbom_file": True,
    "artifact_signature": False,
    "dependency_scan_result": True,
    "deployment_approval": True,
    "exception_ticket": False,
}

score = sum(weight for key, weight in REQUIRED.items() if release.get(key))
missing = [key for key in REQUIRED if not release.get(key)]
print({"release_evidence_score": score, "missing": missing})

운영 데이터가 쌓이면 예외와 증거 누락을 SQL로 찾아 월간 리뷰에 올릴 수 있다.

-- release_evidence_review.sql
-- 목적: 릴리스 뒤 30일 이상 검증 증거가 비어 있는 산출물을 보안 리뷰 목록으로 올린다.
-- 실제 테이블명은 artifact registry export, CI metadata, SBOM 저장소 스키마에 맞게 바꾼다.

select
  artifact_name,
  artifact_version,
  source_repository,
  build_run_id,
  provenance_uri,
  sbom_uri,
  signature_verified,
  deployed_environment,
  released_at
from release_artifact_evidence
where released_at >= current_date - interval '90 day'
  and (
    provenance_uri is null
    or sbom_uri is null
    or signature_verified = false
  )
order by released_at desc;

도입을 보류해야 하는 경우

소프트웨어 공급망 보안 도구를 바로 사면 안 되는 경우도 있다.

저장소 owner가 없고 release branch 보호도 약하면 SBOM 플랫폼보다 저장소 governance가 먼저다.

배포 시스템이 artifact 버전을 기록하지 않으면 서명과 provenance를 붙여도 현장 배포물과 연결되지 않는다.

취약점 SLA가 없으면 SBOM은 위험 목록만 만들고 조치 owner를 만들지 못한다.

이 경우는 30일 동안 저장소 owner, release inventory, artifact registry, 배포 승인 로그부터 정리하는 편이 낫다.

구매 전 체크리스트

상위 20개 저장소와 고객 배포 10개 산출물을 지정한다.
branch protection, CODEOWNERS, reviewer 2명 이상, CI token 기본 권한을 확인한다.
SBOM 형식은 SPDX 또는 CycloneDX 중 하나로 고정하고 artifact version과 연결한다.
SLSA provenance predicateType과 builder.id, buildType, subject, resolvedDependencies를 검증 항목으로 둔다.
서명은 OIDC identity, transparency log, artifact digest 검증 흐름까지 문서화한다.
외주 납품물은 source hash, build instruction, SBOM, scan result, signature, 재빌드 가능성 증거를 요구한다.
Scorecard aggregate score보다 실패 check 5개를 저장소 backlog로 바꾼다.
예외는 owner, ticket, expiry_days 30일, 고객 공지 필요 여부를 필수 필드로 둔다.
고객 보안 질의서 답변용 release evidence bundle을 48시간 안에 만들 수 있는지 모의 점검한다.
월 1회 보안팀, 플랫폼팀, 서비스 owner가 예외와 실패 check를 같이 정리한다.

이 체크리스트에서 다섯 항목 이상 비어 있으면 도구 견적보다 릴리스 인벤토리가 먼저다.

반대로 대부분 채워져 있다면 SLSA L2 수준의 provenance와 서명 검증을 다음 목표로 잡을 수 있다.