최근 몇 년 사이 소프트웨어 공급망 공격은 급격히 증가했다. 공격자는 더 이상 직접 시스템을 뚫으려 하지 않는다. 대신 우리가 신뢰하는 라이브러리, 빌드 서버, 배포 파이프라인을 노린다.
SolarWinds 사건 이후 많은 조직이 질문을 던지기 시작했다.
“우리는 우리가 사용하는 코드의 출처를 정말 신뢰할 수 있는가?”
이 질문에 대한 구조적 대응으로 등장한 개념이 SLSA(Supply-chain Levels for Software Artifacts)다.
SLSA는 무엇을 보호하려는가
SLSA는 하나의 보안 도구가 아니다. 소프트웨어가 작성되고, 빌드되고, 배포되기까지의 과정을 검증 가능한 체계로 만들기 위한 프레임워크다.
핵심은 “이 아티팩트가 어디서, 어떻게 만들어졌는가”를 증명하는 것이다.
코드가 특정 저장소에서 시작되었는지, 빌드 과정이 변조되지 않았는지, 사람이 아닌 자동화된 프로세스로 생성되었는지 등을 단계적으로 검증한다. 이를 통해 위·변조 가능성을 줄이고 추적 가능성을 높인다.
SLSA는 성숙도에 따라 여러 레벨을 제시한다. 단순히 빌드 기록을 남기는 수준에서 시작해, 재현 가능한 빌드와 강력한 무결성 검증까지 단계적으로 강화된다.
즉, “신뢰하라”가 아니라 “증명하라”에 가깝다.
그러나 모든 위험을 제거하지는 못한다
SLSA는 공급망 보안을 강화하는 중요한 시도이지만, 만능은 아니다.
첫째, 조직 전체가 동일한 수준의 성숙도를 유지해야 효과가 있다. 일부 프로젝트만 SLSA 기준을 충족한다고 해서 전체 위험이 사라지는 것은 아니다.
둘째, 오픈소스 생태계의 복잡성은 여전히 존재한다. 우리가 직접 작성하지 않은 수많은 의존성이 트리 구조로 연결되어 있다. 상위 패키지가 안전해 보여도 하위 의존성에 악성 코드가 숨어 있을 수 있다.
셋째, 내부 위협이나 자격 증명 탈취 같은 문제는 별도의 보안 체계가 필요하다. 빌드가 정당한 프로세스를 거쳤더라도, 그 프로세스 자체가 침해되었다면 신뢰는 무너진다.
SLSA는 공급망을 더 투명하게 만들지만, 공격 표면을 완전히 제거하지는 않는다.
공급망 보안의 핵심은 가시성과 자동화
공급망 공격의 본질은 보이지 않는 곳에서 발생한다는 점이다. 개발자는 코드에 집중하지만, 공격자는 그 코드가 지나가는 경로를 노린다.
따라서 핵심은 가시성이다. 어떤 의존성이 포함되어 있는지, 어떤 빌드 서버를 거쳤는지, 어떤 권한으로 배포되었는지를 명확히 파악할 수 있어야 한다.
SLSA는 이를 구조화하는 기준을 제공한다. 여기에 SBOM(Software Bill of Materials), 코드 서명, 무결성 검증, 접근 통제 정책이 함께 작동해야 실질적인 방어가 가능하다.
공급망 보안은 단일 솔루션의 문제가 아니라 개발 문화와 프로세스의 문제다. 자동화되지 않은 검증은 결국 사람의 실수에 의존하게 되고, 그 지점이 공격 표적이 된다.
SLSA는 공급망 공격을 완전히 막는 방패라기보다, 신뢰를 검증 가능한 체계로 전환하는 출발점에 가깝다.
우리가 신뢰를 증명할 수 있을 때, 공급망은 비로소 통제 가능한 영역이 된다.