재현 가능한 빌드(Reproducible Builds)의 중요성과 지난 12년간의 발전 과정을 설명함
소스 코드, 빌드 환경, 빌드 지침이 동일해도 결과물이 달라지는 문제점과 공급망 공격(Supply Chain Attack) 위험을 지적함
SBoM(Software Bill of Materials) 및 `diffoscope`, `rebuilder`와 같은 도구를 활용하여 빌드 재현성을 높이는 방안을 제시함
Debian, Fedora, Arch Linux 등 다양한 배포판에서의 재현 가능한 빌드 현황과 향후 목표를 공유함
발표자는 재현 가능한 빌드(Reproducible Builds)를 '동일한 소스 코드, 빌드 환경, 빌드 지침으로 누구나 동일한 바이너리를 생성할 수 있는 상태'로 정의함. 이는 공급망 공격(Supply Chain Attack)으로부터 소프트웨어를 보호하고, 빌드 결과의 무결성(Integrity)을 검증하는 데 필수적이라고 강조함. 과거 GCC 4.x 시절부터 재현 가능성을 논의해왔으나, 실제 적용은 최근 10여 년간 활발해졌다고 설명함.
빌드 결과가 달라지는 주요 원인으로 타임스탬프(Timestamps), , 등을 지적함. 이를 해결하기 위해 을 활용하고, 와 같은 도구로 빌드 결과물의 차이를 분석하며, 와 같은 도구로 빌드 환경을 격리하는 노력을 소개함. 특히, 가 빌드 결과에 미치는 영향을 줄이기 위한 표준화 노력을 언급함.
Debian은 95% 이상의 패키지가 재현 가능하며, Fedora, Arch Linux 등도 유사한 목표를 추구하고 있다고 설명함. `rebuilder` 도구는 이러한 배포판들의 빌드 환경을 재현하여 검증하는 데 사용됨. 하지만 Go와 같은 언어의 특정 빌드 방식이나 `gossip`과 같은 도구는 재현성 확보에 어려움을 겪는 사례도 있다고 언급함. 현재 약 500개의 미재현 패키지가 남아있으며, 이는 주로 사소한 문제들이라고 분석함.
`diffoscope`는 두 빌드 결과물 간의 차이를 상세히 분석하여 어떤 부분이 다른지 시각적으로 보여주는 도구임. `rebuilder`는 특정 빌드 환경을 격리된 컨테이너에서 재현하여 빌드 결과의 일관성을 검증하는 데 사용됨. 이 도구들은 빌드 결과의 신뢰성을 높이고, 보안 취약점을 조기에 발견하는 데 기여한다고 설명함. `source-date-epoch`와 같은 표준화된 메타데이터 활용도 강조됨.
향후 재현 가능한 빌드 비율을 100%로 높이기 위한 노력이 계속될 것이라고 밝힘. 이는 기술적인 문제뿐만 아니라 정치적 결정(Political Decision)이 중요하며, 재현 불가능한 패키지는 배포하지 않는 정책이 필요하다고 주장함. `rebuilder`는 다양한 배포판과 아키텍처를 지원하며, `source-compare`와 같은 도구도 개발 중이라고 언급함. 궁극적으로는 소프트웨어 공급망의 투명성과 보안을 강화하는 것이 목표라고 요약함.