공급망
SLSA란 무엇입니까?
SLSA는 "살사"로 발음하며 Supply-chain Levels for Software Artifacts의 약자입니다. 소프트웨어가 생산자가 주장하는 소스에서, 주장하는 방식대로, 도중에 변조 없이 빌드되었음을 증명하기 위한 보안 프레임워크입니다. 각 수준은 생산자에게는 따라갈 경로를, 소비자에게는 이를 요구할 수단을 제공합니다.
업데이트
SLSA는 어떤 문제를 해결합니까?
소스 코드를 한 줄도 빠짐없이 리뷰해도 다른 것을 출시할 수 있습니다. 사용자가 실행하는 것은 빌드의 결과물이기 때문입니다. SolarWinds 사례처럼 빌드가 손상되면 깨끗한 소스에서도 오염된 릴리스가 나옵니다. SLSA는 바로 이 빈틈에 집중합니다. 이 아티팩트가 이 소스에서, 이 프로세스를 거쳐 나왔다는 것을 누구든 검증할 수 있습니까?
SLSA 수준
SLSA는 요건을 트랙으로 구성합니다. 현재 버전인 1.2에는 Build 트랙과 Source 트랙이 있습니다. Build 트랙에는 네 가지 수준이 있습니다.
| 수준 | 명칭 | 요건 | 얻는 것 |
|---|---|---|---|
| Build L0 | 보장 없음 | 없음 | L0은 SLSA가 없는 상태 |
| Build L1 | 출처 증명 존재 | 일관된 빌드 프로세스, 그리고 빌드 플랫폼이 생성해 소비자에게 제공하는 출처 증명 | 실수 방지에 도움이 되지만 우회나 위조가 매우 쉬움 |
| Build L2 | 호스팅 빌드 플랫폼 | 출처 증명을 생성하고 서명하는 호스팅 플랫폼에서 빌드를 실행하고, 소비자가 이를 검증 | 출처 증명을 위조하려면 명시적인 공격이 필요 |
| Build L3 | 강화된 빌드 | 실행이 서로 격리되고, 서명 시크릿이 사용자 정의 빌드 단계의 손이 닿지 않는 곳에 있음 | 출처 증명을 위조하려면 취약점을 악용해야 하며, 대부분의 공격자 능력을 넘어섬 |
수준은 최대한 높여야 하는 등급이 아닙니다. 각 수준은 특정 위협을 막아 주므로, 위험에 맞는 수준을 선택하세요. 호스팅 CI 서비스를 사용하는 오픈 소스 메인테이너는 큰 노력 없이 L2에 도달할 수 있는 경우가 많습니다.
출처 증명이란 무엇입니까?
출처 증명은 아티팩트가 어떻게 만들어졌는지에 대한 기록입니다. SLSA에서는 어떤 플랫폼이, 어떤 소스에서, 어떤 프로세스로, 어떤 최상위 입력을 사용해 빌드했는지를 기술합니다. L2 이상의 출처 증명은 서명되므로, 소비자는 그것이 빌드 플랫폼에서 나왔고 변경되지 않았음을 확인할 수 있습니다.
SBOM이 재료 목록이라면 출처 증명은 요리가 어디서 어떻게 조리되었는지입니다. 둘은 서로 다른 질문에 답하며 함께 잘 작동합니다. SBOM은 안에 무엇이 들어 있는지 나열하고, 출처 증명은 아티팩트가 어디서 왔는지 알려 줍니다.
SLSA 도입 방법
- 매번 같은 방식으로 CI에서 빌드합니다. 노트북에서 릴리스하는 것을 멈추세요. L1에 도달하는 작업의 대부분이 이것입니다.
- 출처 증명을 생성합니다. GitHub에서는 아티팩트 증명(artifact attestations)이 서명된 출처 증명을 생성합니다. GitHub Actions에서 증명이 SBOM과 함께 작동하는 방식을 참고하세요.
- 중요한 곳에서 검증합니다. 아무도 확인하지 않는 서명된 출처 증명은 아무것도 보호하지 못합니다. 배포 단계나 어드미션 컨트롤러에 검증을 추가하세요.
- 빌드를 강화합니다. 실행을 격리하고 서명 키를 빌드 단계와 분리하세요. 러너 보안 비교를 참고하세요.
- 종속성에도 요구합니다. 출처 증명을 게시하는 패키지를 우선 사용하세요. 현재 npm 같은 레지스트리가 이를 지원합니다.
SLSA가 다루지 않는 것
- 취약점. 완벽하게 빌드된 아티팩트에도 결함이 있을 수 있습니다. SLSA는 코드가 안전한지에 대해 아무것도 말하지 않습니다.
- 악의적인 소스. 공격자가 리포지토리에 커밋하면, 출처 증명은 그 코드의 빌드를 충실하게 기록합니다. Source 트랙이 이 문제의 일부를 다룹니다.
- 빌드가 가져온 것. 출처 증명은 최상위 입력을 나열합니다. Build 트랙의 어떤 요건도 종속성의 전체 목록을 요구하지 않으며, 그것이 SBOM의 역할입니다.
- 신뢰받는 내부자. xz 백도어는 신뢰받는 메인테이너를 통해 들어왔으며, SLSA만으로는 막지 못했을 것입니다.
SLSA와 다른 프레임워크
SLSA는 빌드 무결성을 깊이 다룹니다. NIST SSDF는 훨씬 넓은 범위로, 보안 개발 전반을 다루며 SLSA 출처 증명이 뒷받침하는 릴리스 보호 및 보관 관행도 포함합니다. SLSA는 OpenSSF의 프로젝트이며, 많은 팀이 둘을 함께 사용합니다. 더 큰 그림은 소프트웨어 공급망 보안이란 무엇인가를 참고하세요.
CRACI의 역할
CRACI는 서명된 출처 증명을 생성하지 않으며 SLSA 수준을 주장하지 않으므로, 필요하다면 GitHub 아티팩트 증명이나 유사한 서비스를 사용하세요. CRACI가 더하는 것은 SLSA가 다루지 않는 부분, 즉 각 GitHub Actions 작업이 가져온 것의 전체 기록입니다. 각 작업은 격리된 전용 가상 머신에서 실행되고, 작업이 가져오는 모든 패키지는 SBOM에 기록되며, 이그레스 정책은 빌드에 필요 없는 연결을 차단합니다. 빌드 시점 SBOM 생성을 참고하세요.
SLSA: 자주 묻는 질문
SLSA는 무엇의 약자입니까?
Supply-chain Levels for Software Artifacts의 약자이며, "살사"로 발음합니다.
SLSA 수준에는 무엇이 있습니까?
Build 트랙에는 네 가지가 있습니다. L0은 보장 없음, L1은 출처 증명 존재, L2는 출처 증명에 서명하는 호스팅 빌드 플랫폼, L3은 실행이 격리되고 서명 시크릿이 보호되는 강화된 빌드입니다. 버전 1.2에서는 Source 트랙도 추가되었습니다.
SLSA 출처 증명이란 무엇입니까?
아티팩트가 어떤 플랫폼에서, 어떤 소스로, 어떤 프로세스로, 어떤 최상위 입력을 사용해 빌드되었는지에 대한 기록입니다. Build L2 이상에서는 서명되므로 소비자가 검증할 수 있습니다.
SLSA와 SBOM의 차이는 무엇입니까?
SBOM은 소프트웨어 안에 무엇이 들어 있는지 나열합니다. SLSA 출처 증명은 그것이 어떻게, 어디서 빌드되었는지 기술합니다. 일반적으로 둘 다 필요합니다.
SLSA는 의무입니까?
아닙니다. OpenSSF 커뮤니티의 자발적 프레임워크입니다. 일부 고객과 조직이 특정 수준을 요구할 수는 있지만 법은 아닙니다.
어떤 SLSA 수준을 목표로 해야 합니까?
CI에서 빌드하고 출처 증명을 생성해 Build L1부터 시작한 다음, 많은 팀이 빠르게 도달할 수 있는 호스팅 플랫폼 기반의 L2로 넘어가세요. L3은 다른 많은 곳이 의존하거나 위험도가 높은 릴리스에 적합합니다.