빌드 재현성, 보안의 핵심!

발표자는 재현 가능한 빌드(Reproducible Builds)를 '동일한 소스 코드, 빌드 환경, 빌드 지침으로 누구나 동일한 바이너리를 생성할 수 있는 상태'로 정의함. 이는 공급망 공격(Supply Chain Attack)으로부터 소프트웨어를 보호하고, 빌드 결과의 무결성(Integrity)을 검증하는 데 필수적이라고 강조함. 과거 GCC 4.x 시절부터 재현 가능성을 논의해왔으나, 실제 적용은 최근 10여 년간 활발해졌다고 설명함.

빌드 결과가 달라지는 주요 원인으로 타임스탬프(Timestamps), 빌드 경로(Build Paths), 컴파일러 최적화(Compiler Optimizations) 등을 지적함. 이를 해결하기 위해 SBoM(Software Bill of Materials)을 활용하고, `diffoscope`와 같은 도구로 빌드 결과물의 차이를 분석하며, `rebuilder`와 같은 도구로 빌드 환경을 격리하는 노력을 소개함. 특히, 시간 정보(Time Information)가 빌드 결과에 미치는 영향을 줄이기 위한 표준화 노력을 언급함.

Debian은 95% 이상의 패키지가 재현 가능하며, Fedora, Arch Linux 등도 유사한 목표를 추구하고 있다고 설명함. `rebuilder` 도구는 이러한 배포판들의 빌드 환경을 재현하여 검증하는 데 사용됨. 하지만 Go와 같은 언어의 특정 빌드 방식이나 `gossip`과 같은 도구는 재현성 확보에 어려움을 겪는 사례도 있다고 언급함. 현재 약 500개의 미재현 패키지가 남아있으며, 이는 주로 사소한 문제들이라고 분석함.

`diffoscope`는 두 빌드 결과물 간의 차이를 상세히 분석하여 어떤 부분이 다른지 시각적으로 보여주는 도구임. `rebuilder`는 특정 빌드 환경을 격리된 컨테이너에서 재현하여 빌드 결과의 일관성을 검증하는 데 사용됨. 이 도구들은 빌드 결과의 신뢰성을 높이고, 보안 취약점을 조기에 발견하는 데 기여한다고 설명함. `source-date-epoch`와 같은 표준화된 메타데이터 활용도 강조됨.

향후 재현 가능한 빌드 비율을 100%로 높이기 위한 노력이 계속될 것이라고 밝힘. 이는 기술적인 문제뿐만 아니라 정치적 결정(Political Decision)이 중요하며, 재현 불가능한 패키지는 배포하지 않는 정책이 필요하다고 주장함. `rebuilder`는 다양한 배포판과 아키텍처를 지원하며, `source-compare`와 같은 도구도 개발 중이라고 언급함. 궁극적으로는 소프트웨어 공급망의 투명성과 보안을 강화하는 것이 목표라고 요약함.