🏆 소프트웨어 공급망 보안, SLSA와 Attestation이 답이다!

Gartner 보안 서밋 GitHub 발표 요약 & 실전 대응 가이드

오늘은 워싱턴 DC에서 열린 Gartner Security & Risk Management Summit 현장에서 발표된
GitHub의 제품관리 디렉터 Jennifer Schelkopf의 강연을 바탕으로
최근 소프트웨어 공급망 공격과 이에 맞선 SLSA 프레임워크,
그리고 Attestation(산출물 증명)의 실제 적용법까지
실무자가 꼭 알아야 할 핵심 내용을 쏙쏙 뽑아 쉽고 자세하게 정리합니다! 🚀

---

🏴‍☠️ “나는 내 코드가 안전한지 확신할 수 있는가?”

⛓️ 공급망 공격, 왜 점점 더 무서워지나?

2024~2025년을 관통하는 가장 큰 소프트웨어 보안 이슈는
바로 공급망 공격(Supply Chain Attack)입니다.

• SolarWinds 침해(2020)
• Log4Shell, PyTorch의 악성 PyPI 패키지(2022)
• Linux XL Utils 백도어 사건(2023)
• NPM, PyPI, OSS 생태계의 잇따른 악성 패키지

👉 최근 조사에 따르면, 2025년 말까지 45%의 조직이 한 번 이상 공급망 공격을 경험할 것으로 전망됩니다.

이러한 공격은 오픈소스 라이브러리, 서드파티 의존성, 심지어 빌드 서버 등
'내부'라 생각했던 코드와 시스템을 교묘하게 노리고 들어오죠.

Jennifer Schelkopf는 이를 “길거리에서 주운 햄버거를 아무 의심 없이 먹는 것과 다름없다”고 표현했습니다.
우리가 무심코 사용하는 오픈소스 코드, 패키지, 자동화된 빌드 아티팩트가
과연 어디서 왔는지, 어떻게 만들어졌는지, 누가 승인했는지
확인하지 않고 그냥 사용하는 ‘묻지마 신뢰’가 가장 큰 리스크라는 뜻입니다.

---

🏆 SLSA가 가져온 “신뢰의 레벨업”

🧩 SLSA(Supply-chain Levels for Software Artifacts)란?

그렇다면 “이 코드가 안전하다”는 확신,
즉 '신뢰의 근거'를 어떻게 만들 수 있을까요?
이 질문에 대한 답이 바로 SLSA 프레임워크입니다!

🔒 SLSA의 개념 & 핵심 요소

• SLSA란?
  “Tampering(변조) 방지, 무결성 검증, 패키지/인프라 보안”을 위한 체크리스트이자
  아티팩트 생산→프로비넌스 기록→검증의 모든 과정을 체계적으로 관리하는 산업표준 프레임워크
• 주요 레벨
  • SLSA 1: 빌드 아티팩트가 기록되고, 추적 가능해야 함
  • SLSA 2: 빌드 프로세스가 자동화되어 있고, 기록이 보존됨
  • SLSA 3: 빌드 환경이 격리되어 있고, 신뢰할 수 있는 증명(attestation)이 존재
  • SLSA 4: 빌드 환경이 완전히 재현 가능하며, 상시 감사와 검증이 가능

🗂️ Attestation(아티팩트 증명)

• 누가, 언제, 어디서, 어떻게 만들었는지, 어떤 빌드 시스템이, 누구의 승인을 받아 생성됐는지 등
  모든 산출물의 계보와 신뢰성을 체계적으로 보장
• Attestation은 단순한 '로그'가 아니라, 정책에 맞지 않는 산출물을 자동 거부하거나
  변조/위조 가능성을 원천 차단하는 '디지털 서류' 역할

🛡️ SLSA 프레임워크를 도입하면?

• 무심코 사용하는 오픈소스, 내부 패키지, 자동화된 빌드 환경에서
  “이 코드가 정말 안전한가?”라는 근본적 의문에 명확한 근거를 가질 수 있습니다.
• 유명한 SolarWinds 공급망 침해 사례도,빌드 서명 오류(Attestation 실패)를 실시간으로 잡아낼 수 있었을 것이라는 게Jennifer Schelkopf의 설명입니다.

---

⚡ 실무 적용을 위한 SLSA & Attestation 전략

🔎 1. 공급망 보안 점검, SLSA 체크리스트로 시작하세요!

• “내가 쓰는 패키지는 어디서, 누가, 어떻게 만들었나?”
• “빌드/배포 파이프라인이 자동화되어 있고, 아티팩트가 추적 가능한가?”
• “모든 아티팩트의 프로비넌스와 증명(attestation)이 남아 있는가?”

위 질문에 “YES”라고 자신 있게 답할 수 없다면
SLSA 프레임워크의 단계별 가이드(SLSA.dev 참고)를 따라
내 환경을 진단하고 개선하세요.

🤖 2. 오픈소스 실무 도구로 자동화

• Sigstore:
  • 오픈소스 개발, 배포 파이프라인 내에서
    자동으로 코드/아티팩트에 서명·검증·체크 기능 제공
  • Google Cloud, GitHub Actions 등 주요 클라우드와 CI/CD에서 바로 사용 가능
  • SLSA 3 레벨 지원, 빌드 결과물의 신뢰성 자동 보증
• OPA Gatekeeper:
  • 쿠버네티스 환경에서 배포 전 단계에서
    정책 위반 아티팩트 자동 차단
  • Kubernetes 정책 기반 보안에 최적화
• GitHub Actions x SLSA
  • 워크플로 자동화 과정에서
    SLSA 3, Sigstore 연동 가능
  • "정책 위반, 미서명, 증명 미확인 아티팩트 = 자동 리젝"
  • 조직 내에서 DevSecOps 실무에 바로 접목 가능

🧾 3. Attestation으로 “내 코드, 내 책임” 실현

• 아티팩트 증명 체계 도입
  • 누가 언제 어떤 빌드 시스템에서 산출물을 만들었는지
    디지털로 기록·서명·보관
  • 위조, 변조, 재현불가 아티팩트는
    배포, 배포 전 단계에서 자동으로 차단
• 디지털 페이퍼 트레일 확보
  • 모든 배포 내역, 아티팩트 검증 이력 자동 기록
  • 추후 침해 사고/감사 등에서도“내가 배포한 코드는 안전하다”는 증빙이 명확

---

💡 실무자가 꼭 기억해야 할 “신뢰의 전환”

🔄 “묻지마 신뢰”에서 “증거 기반 신뢰”로

Jennifer Schelkopf는
“기존에는 ‘내가 가져오는 라이브러리, 패키지, 의존성이 문제없을 것’이라고 막연히 믿었지만
이제는 Attestation 기반으로 명확한 근거를 가진 신뢰 체계를 만들어야 한다”고 강조합니다.

즉,

• "문제가 없을 거야" → "문제가 없는지 근거가 있다"
• "나만 잘하면 된다" → "외부 코드, 서드파티, 전체 파이프라인도 신뢰 체계 내에 둔다"
• "공급망 침해는 남의 일" → "내가 쓰는 코드/패키지가 가장 큰 리스크"

이렇게 신뢰의 기준을 '암묵적'에서 '명시적(Explicit Trust)'로 전환하는 것이
SLSA와 Attestation의 가장 큰 가치입니다.

---

📝 결론: SLSA는 선택이 아닌 필수!

오픈소스와 자동화가 기본이 된 시대,
공급망 공격을 막는 ‘마지막 보루’는
바로 프로비넌스(artifact provenance)와 증명(attestation)
그리고 SLSA 프레임워크에서 시작됩니다.

오늘부터 내 개발팀, DevOps, 보안팀이
SLSA 기반 공급망 신뢰 체계와 Attestation 자동화를 구축하도록
아래와 같이 실천해보세요!