제조업 SLSA·OpenSSF·Sigstore 소프트웨어 공급망 보안 실무 완벽 가이드 — 익명 빌드에서 검증 가능한 출처까지 5단계 로드맵

· CONTIS

중소·중견 한국 제조사가 SLSA(Supply-chain Levels for Software Artifacts) v1.0을 SBOM 준비·서명·증명·자동화·고도화까지 진짜 무사히 구축하는 5단계 로드맵. SLSA L1~L4, Build/Source/Verification tracks, in-toto attestation, Sigstore(Cosign·Rekor·Fulcio), OpenSSF Scorecard, SBOM(CycloneDX·SPDX), NIST SSDF SP 800-218, 미 EO 14028·OMB M-22-18·M-23-16, EU CRA·NIS2 공급망 요구사항 실무.

#SLSA#OpenSSF#Sigstore#SBOM#소프트웨어공급망#사이버보안#제조업

1. 왜 소프트웨어 공급망 보안인가 — SolarWinds 이후의 세계

2020년 12월 SolarWinds Orion 사건 — 빌드 시스템 침투로 18,000+ 고객사 SUNBURST 백도어 배포. 2021년 7월 Kaseya VSA, 2021년 12월 Log4Shell(Log4j RCE), 2023년 3월 3CX, 2024년 3월 XZ Utils(jia tan 사회공학 백도어). 모두 소프트웨어 공급망 공격 — 의존성·빌드·배포 어딘가가 침해되면 모든 다운스트림이 감염.

대응: ① SBOM(Software Bill of Materials): 모든 의존성 가시화, ② SLSA(Supply-chain Levels for Software Artifacts): 빌드 무결성·증명, ③ Sigstore: 무료·자동 서명, ④ OpenSSF Scorecard: 오픈소스 보안 점수, ⑤ NIST SSDF(SP 800-218): 보안 SDLC 프레임워크.

법적 압박: 미국 EO 14028(2021.5) → OMB M-22-18(2022.9) → M-23-16(2023.6): 연방 조달 소프트웨어는 NIST SSDF + SBOM + 자가 증명서 제출. EU CRA(2024.10 발효) Article 13: 모든 제조사 SBOM·취약점 처리 의무. NIS2(2024) 공급망 보안 의무 확장. 한국 K-시큐어 소프트웨어 공급망 가이드(2024.4) 발간.

2. SLSA v1.0 핵심 — 4 Levels + 3 Tracks

SLSA(Supply-chain Levels for Software Artifacts, “살사”로 발음) — OpenSSF가 관리하는 소프트웨어 빌드 무결성 프레임워크. Google Binary Authorization for Borg(2014~)에서 유래, v0.1(2021.6), v1.0(2023.4) 정식 출시.

SLSA v1.0 — Build Track:

Level요구사항보호 위협
L0측정 없음-
L1빌드 자동화 + Provenance(증명) 자동 생성빌드 추적 불가
L2호스팅된 빌드 플랫폼 + 서명된 Provenance빌드 위변조
L3빌드 플랫폼이 격리·강화·증명 무위조빌드 서버 침해
L4(v0.1에 존재, v1.0에서 제거 후 추후 Source Track으로 분리)-

3 Tracks (v1.0):

  • Build Track(현재): Provenance 정확성·무결성·격리
  • Source Track(드래프트): 소스 코드 출처·변경 이력
  • Dependency Track(향후): 의존성 무결성

Provenance(증명): in-toto Attestation Framework 기반 JSON 문서 — “누가·언제·어디서·무엇으로 이 아티팩트를 빌드했는가” 기록. predicate type = https://slsa.dev/provenance/v1.

3. OpenSSF 생태계·도구 스택

OpenSSF(Open Source Security Foundation) — Linux Foundation 산하, 2020년 출범. GitHub·Google·Microsoft·Red Hat 등 100+ 기업 참여.

주요 프로젝트:

  • SLSA: 빌드 무결성 프레임워크
  • Sigstore: 무료 키리스 서명 (Cosign·Rekor·Fulcio)
  • Scorecard: 오픈소스 프로젝트 보안 점수 (Maintained·Code-Review·CII-Best-Practices·CI-Tests·SAST·Vulnerabilities 등 18개 체크)
  • Allstar: GitHub 정책 적용 봇
  • GUAC: 공급망 그래프 분석
  • OSV.dev: 오픈소스 취약점 DB
  • CVE Bin Tool: 바이너리 취약점 스캔
  • OSSF Best Practices Badge: 기존 CII Badge

Sigstore 구성:

  • Cosign: 컨테이너 이미지·아티팩트 서명·검증 CLI
  • Fulcio: OIDC 기반 자동 인증서 발급 (단기 인증서 10분)
  • Rekor: 투명 로그 — 모든 서명 공개 기록
  • Witness: 빌드 과정 attestation

4. Stage 1 — 현황 진단·SBOM 시범 (1~2개월)

자가 진단:

  • 사용하는 오픈소스 의존성 수 파악 (보통 평균 200~500개)
  • 직접·전이 의존성 비율 (평균 90% 전이)
  • CI/CD 빌드 시스템 현황 (GitHub Actions·GitLab CI·Jenkins·Azure DevOps)
  • 컨테이너 이미지 레지스트리 (Docker Hub·ECR·ACR·GCR·Harbor)
  • 서명·검증 적용 여부 (대부분 0%)

SBOM 생성 시범:

  • CycloneDX: OWASP 주관, JSON/XML, 컴포넌트·취약점·서비스·라이선스 — 컨테이너·SaaS 적합
  • SPDX: Linux Foundation, ISO/IEC 5962:2021 표준 — Linux·정부 조달 적합
  • 도구: Syft(아무 곳에서나 SBOM 생성), Trivy(스캔 + SBOM), Anchore Grype, CycloneDX CLI

도구 예시:

  • syft dir:. -o cyclonedx-json=sbom.cdx.json — 디렉토리 → CycloneDX SBOM
  • trivy fs . --format spdx-json --output sbom.spdx.json — SPDX SBOM

컴포지션 분석(SCA): Snyk·Dependabot·Renovate·Mend·Sonatype Nexus IQ — 의존성 취약점 자동 알림.

5. Stage 2 — SLSA L1·L2: 빌드 자동화·서명 (2~3개월)

SLSA L1 달성:

  • 빌드 자동화: CI/CD 파이프라인 (수동 빌드 금지)
  • Provenance 자동 생성 — GitHub Actions에서 slsa-framework/slsa-github-generator 사용
# .github/workflows/release.yml
- uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v1.10.0
  with:
    base64-subjects: "${{ needs.build.outputs.hashes }}"

SLSA L2 달성:

  • 호스팅된 빌드 플랫폼 사용 (GitHub Actions·GitLab CI·Google Cloud Build 등 — 본인이 직접 빌드 서버 운영 X)
  • Provenance에 서명 — Sigstore Cosign 사용

Sigstore Cosign 도입:

# 키리스 서명 (OIDC GitHub Actions·Google 등)
cosign sign --yes ghcr.io/org/image:tag

# 서명 검증
cosign verify ghcr.io/org/image:tag \
  --certificate-identity-regexp 'https://github.com/org/.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

SBOM 첨부:

cosign attest --predicate sbom.cdx.json --type cyclonedx ghcr.io/org/image:tag

관리자 측 검증 (Kubernetes Admission Controller — Sigstore Policy Controller·Kyverno·OPA Gatekeeper):

  • 서명 없는 이미지 거부
  • 신뢰 ID 외 서명 거부
  • SBOM 없는 이미지 거부

6. Stage 3 — SLSA L3: 빌드 격리·강화 (4~6개월)

SLSA L3 요구사항:

  • 격리된 빌드: 각 빌드는 독립 환경, 다른 빌드와 상호작용 불가
  • isolated build platform: 신뢰할 만한 호스팅 (예: GitHub Actions reusable workflows + slsa-github-generator)
  • Provenance 위조 불가: 서비스 운영자도 Provenance를 사후 수정 불가
  • Source 자료 기록: 빌드 입력 소스 hash·revision 기록

구현 패턴 (GitHub):

  • Reusable Workflow + OIDC + 자동 Provenance — slsa-github-generator
  • GitHub Artifact Attestations (GA 2024.6): actions/attest-build-provenance@v1
  • 자체 호스팅 Runner 사용 시 L3 도달 어려움 (격리 보장 어려움)

구현 패턴 (GitLab):

  • GitLab CI/CD + gitlab-runner + SBOM·SLSA Provenance 자동 생성 (GitLab 17.0+)

구현 패턴 (자체 환경):

  • Tekton Chains: K8s CI 파이프라인 attestation
  • Jenkins: in-toto plugin

in-toto 도입:

  • Pipeline 각 단계 attestation 생성
  • Final verification에서 모든 단계 무결성 확인
  • Witness(Sigstore): in-toto 통합 도구

7. Stage 4 — 정책·자동 강제·검증 (3~6개월)

정책 엔진(OPA Gatekeeper·Kyverno·Sigstore Policy Controller):

# Kyverno: SLSA Provenance 검증
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-slsa
spec:
  validationFailureAction: enforce
  rules:
  - name: check-slsa-attestation
    match:
      resources:
        kinds: [Pod]
    verifyImages:
    - imageReferences: ["ghcr.io/org/*"]
      attestations:
      - predicateType: https://slsa.dev/provenance/v1
        attestors:
        - keyless:
            subject: "https://github.com/org/.*"
            issuer: "https://token.actions.githubusercontent.com"
        conditions:
        - all:
          - key: "{{ buildDefinition.buildType }}"
            operator: Equals
            value: "https://slsa.dev/.../v1"

Admission Controller 패턴:

  • 미서명·미증명 이미지 차단
  • 알려진 취약점 Critical 차단 (Trivy + OPA)
  • 라이선스 정책 (GPL 차단 등)
  • 베이스 이미지 화이트리스트

OpenSSF Scorecard 도입 (오픈소스 의존성 평가):

# .github/workflows/scorecard.yml
- uses: ossf/scorecard-action@v2.4.0
  with:
    results_file: results.sarif
    results_format: sarif
    publish_results: true

KEV·EPSS 통합: CISA KEV(Known Exploited Vulnerabilities) + FIRST EPSS(Exploit Prediction) 통합 → 실제 악용·악용 가능성 높은 취약점 우선 패치.

8. Stage 5 — 고도화·통합·SLSA L4+ (지속)

자동 패치 파이프라인:

  • Dependabot/Renovate: 자동 PR 생성
  • 보안 패치 자동 머지 (테스트 통과 시)
  • KEV·EPSS 점수 기준 SLA (Critical 7일·High 30일)

GUAC (Graph for Understanding Artifact Composition):

  • SBOM·SLSA·OSV·Scorecard 데이터 통합 그래프
  • 영향 분석 — “이 CVE에 영향받는 우리 시스템은?”
  • Neo4j·GraphQL 기반

Source Track 준비: 소스 코드 출처 보호 — 보호 브랜치·서명된 커밋·코드 리뷰·차단된 force push.

Reproducible Builds: 동일 소스 → 동일 바이너리 보장 (Debian·NixOS), 빌드 위조 탐지 궁극 수단.

Confidential Computing: AMD SEV·Intel TDX·NVIDIA H100 CC — 빌드 워크로드 자체 보호.

Hermetic Builds: 빌드 시 외부 네트워크 차단, 의존성 사전 다운로드 (Bazel·NixOS·Buck2).

9. 비용·ROI

항목비용 (3년 누적)
SBOM 도구·SCA(Snyk·Mend·Sonatype)1억~10억
Cosign·Sigstore (오픈소스)0원 (운영 인력만)
CI/CD 강화 (GitHub Actions·GitLab Premium)5천~3억
정책 엔진(OPA·Kyverno)0원 (오픈소스) + 운영
Container Security(Wiz·Snyk·Aqua)3억~20억
거버넌스·교육·인력(공급망 보안 팀 2~5명)6억~30억
합계 (중견 제조사)11~63억

ROI:

  • SolarWinds 평균 침해 비용 $26M (한 사고)
  • 평균 SW 공급망 공격 한국 손실 5억~50억
  • EU CRA 미준수 과징금 — 매출 2.5% 또는 1,500만유로 中 大
  • 연방 조달 자가증명서 미제출 — 미국 시장 진입 불가
  • 사이버보험 SBOM·SLSA 보유 시 10~20% 할인

10. 자가 점검 — 우리 SW 공급망

  • 모든 컴포넌트 SBOM 생성·저장
  • CycloneDX 또는 SPDX 표준 준수
  • SCA 도구 도입(Snyk·Dependabot 등)
  • CI/CD 빌드 자동화 100%
  • SLSA L1 Provenance 자동 생성
  • SLSA L2 서명된 Provenance
  • SLSA L3 격리된 빌드 환경 검토
  • Cosign 또는 동등 도구 서명
  • Sigstore Fulcio·Rekor 또는 자체 PKI
  • 정책 엔진(OPA·Kyverno) — 서명 검증
  • OpenSSF Scorecard 자체·핵심 의존성 평가
  • KEV·EPSS 우선순위
  • 보안 패치 SLA(Critical 7일)
  • EU CRA·OMB M-22-18 SLSA·SBOM 요구 분석
  • Hermetic·Reproducible Build 로드맵
  • 공급망 침해 IR 플레이북

11. 마무리 — 신뢰 가능한 출처가 새 보안의 기반

소프트웨어 공급망 보안은 ① SBOM으로 가시화, ② SLSA로 빌드 무결성, ③ Sigstore로 검증 가능 서명, ④ 정책으로 자동 강제, ⑤ 그래프 분석·자동 패치로 고도화 — 이 5단계를 점진 구축하면 SolarWinds·Log4Shell·XZ급 공급망 공격을 사전 차단하고 EU CRA·미국 EO 14028 조달 요구를 동시 충족할 수 있다.

통합 사이클