서명된 빌드 출처를 확인해도 취약점이 없다고 할 수 없는 이유

빌드 provenance는 아티팩트가 어디서, 어떤 입력과 빌더를 거쳐 만들어졌는지 추적하는 근거입니다. 서명과 digest를 기대값에 맞춰 확인하면 생성 경로와 결과물 식별을 검토할 수 있지만, 소스 코드가 취약점 없이 안전하다는 뜻은 아닙니다.

provenance의 신뢰는 올바른 생성 주체·키·입력 목록과 검증 절차에 달려 있습니다. 취약점 예방·검토·시험은 별도의 소프트웨어 보안 활동으로 이어져야 합니다.

빌드 기록은 생성 경로를 설명합니다

가상의 프로그램을 배포하면서 서명된 생성 기록을 함께 제공한다고 합시다. 그 기록은 어떤 빌더가 어떤 소스 revision과 외부 입력을 받아 특정 digest의 아티팩트를 만들었다고 주장할 수 있습니다. 소비자는 서명 검증 뒤 기록 속 소스·빌더·결과 digest를 자신이 기대한 값과 비교합니다. 여기까지 성공하면 ‘검증한 신뢰 체계 안에서 이 결과물이 특정 생성 경로와 연결된다’는 주장이 강해집니다. 하지만 기록은 소스의 논리적 결함, 안전하지 않은 설계, 취약한 의존성의 존재 여부를 자동으로 분석하지 않습니다.

가상 배포 사례를 순서대로 검증합니다

1. 기록의 subject digest를 승인한 빌드 결과의 digest와 비교합니다.
2. 서명 검증에 쓰인 신뢰 앵커가 의도한 빌드 서비스인지 확인합니다.
3. 빌더 식별자와 외부 입력·의존성 목록을 조직의 기대값과 대조합니다.
4. 기록이 실제 생성 과정에서 나온 것이며 임의의 빌드 단계가 내용을 조작하지 못하는지 검토합니다.
5. 그 뒤 소스 리뷰, 취약한 의존성 분석, 보안 시험 등 코드 품질 근거를 별도로 확인합니다.

예를 들어 승인한 revision R의 provenance가 산출물 digest D를 가리키고 실제 배포 파일도 D와 일치한다고 합시다. 이 일치는 ‘검토한 파일과 전달한 파일이 같다’는 공급망 질문에 답합니다. revision R에 입력 검증 누락이 있었다면 빌더가 정직하게 R을 D로 만들었다는 사실은 그 결함을 없애지 않습니다. 반대로 코드 검토를 했더라도 배포한 바이너리가 다른 digest라면 그 검토 결과를 배포 파일에 연결할 수 없습니다. 두 근거는 서로 대체하지 않고 각각 다른 연결을 입증합니다.

규격의 판본과 보증 범위도 적습니다

검토한 SLSA provenance 문서는 아티팩트가 생성된 방법을 기술하고 소비자가 기대와 비교해 검증할 수 있도록 구성됐습니다. 현재 공식 페이지는 이 판본을 Retired로 표시하고 더 최근 판본을 current로 안내하므로, 이를 현행 규격이라고 소개하지 않습니다. NIST의 Secure Software Development Framework는 소프트웨어 취약점 위험을 줄이는 개발 관행을 제시합니다. provenance 확인과 안전한 개발·검토 관행은 함께 쓸 수 있지만, 두 자료 모두 특정 프로그램이 무취약하다고 보증하지 않습니다.

회상 연습: 생성 경로와 결함 부재를 나눕니다

교육용 문제입니다. 서명된 기록이 기대한 소스 revision과 artifact digest를 가리키고 배포 파일도 같은 digest입니다. 이 정보로 말할 수 있는 것과 별도 확인해야 할 것을 각각 말해 보세요.

정답은 ‘검증한 생성 경로에 기록을 연결하고 전달 파일의 동일성을 확인했다’입니다. 코드에 취약점이 없는지는 소스 검토·의존성 분석·시험으로 따로 확인해야 합니다. provenance 검증은 소프트웨어 보안 활동을 대신하지 않습니다.