SLSA는 공급망 보안을 단계로 전환하여 도입 가능하게 만들었다

SolarWinds, Codecov 및 기타 빌드 체인 공격 이후, 소프트웨어 소비자는 아티팩트가 예상된 소스와 빌드 프로세스에서 나왔는지 알아야 했다. 바이너리만으로는 그 질문에 답할 수 없었다.

SLSA의 접근은 즉시 완벽을 요구하는 것이 아니었다. 구글의 2021년 제안은 출처 증명을 생성하는 자동화된 빌드에서 시작하여 더 강력한 빌드 격리, 검토 및 재현성으로 나아가는 네 가지 점진적으로 도입 가능한 단계를 설명했다.

v1.0 사양은 이를 트랙과 단계로 정교화했다: 생산자, 소비자 및 인프라 제공자를 위한 공유 어휘, 체크리스트 및 증거 모델. 이 형식은 보안을 전부 아니면 전무로 취급하는 대신 부분적 진전을 가시화함으로써 승리했다.

무결성을 스위치가 아닌 사다리로 만들기

단계는 조직이 모든 의존성이 완벽한 척하지 않고도 특정 무결성 상태를 주장할 수 있게 했다.

출처 증명은 정책 엔진과 소비자가 빌드 프로세스를 검증할 수 있게 했다.

프레임워크는 추상적인 공급망 위험을 구체적인 소스, 빌드 및 배포 통제에 매핑했다.

낮은 단계는 최고 기준으로 곧바로 도약할 수 없는 프로젝트를 위한 업그레이드 경로를 만들었다.

이상적인 표준이 대부분의 사용자에게 너무 비쌀 때, 도입은 여전히 위험을 줄이는 부분적 보장을 명명하는 것에서 시작할 수 있다.

SLSA는 소프트웨어 아티팩트 무결성을 위한 공통 언어가 되었다. 그 단계는 이제 SBOM, Sigstore 및 in-toto 증명과 함께 사용되어 패키지가 예상된 시스템에 의해 예상된 소스에서 빌드되었는지 결정한다.