Reproduceerbare build

Een reproduceerbare build levert bit-voor-bit identieke uitvoer wanneer iemand dezelfde broncode bouwt met dezelfde buildomgeving en dezelfde buildinstructies. Dat is de definitie van het project Reproducible Builds. Uitvoer betekent hier de artefacten waar de build om draait: uitvoerbare bestanden, distributiepakketten, container- of bestandssysteemimages. Logs tellen niet mee. "Hij bouwt weer" is niet hetzelfde; reproduceerbaar betekent dat de bytes overeenkomen.

Waarom de meeste builds niet reproduceerbaar zijn

• Afhankelijkheden die tijdens de build worden opgelost. Zonder lockfile kiest een pakketbeheerder de versies terwijl de build draait. Resolutie bij PyPI kan anders uitpakken afhankelijk van de volgorde waarin antwoorden binnenkomen, een versiebereik verschuift zodra er een nieuwe release uitkomt, en een veranderlijke tag zoals latest wijst ergens anders naartoe.
• De omgeving. Tijdstempels, bestandspaden, de locale en de eigen tools van de host komen in de artefacten terecht.
• Willekeur. Buildstappen kunnen ID's genereren, bestanden op hash sorteren of werk parallel uitvoeren in een steeds andere volgorde.

Dezelfde commit twee keer na elkaar bouwen garandeert dus niet hetzelfde resultaat, en ook niet dezelfde SBOM. Een build die code downloadt die de lockfile niet vermeldt, een verborgen afhankelijkheid, maakt het erger.

Hoe teams builds reproduceerbaar maken

• Pin en lock elke invoer, ook base images op digest en tools op versie (zie lockfile).
• Gebruik een vaste tijd in plaats van de klok: SOURCE_DATE_EPOCH is een standaard omgevingsvariabele met een Unix-tijdstempel die buildtools gebruiken in plaats van de huidige tijd.
• Verwijder of normaliseer buildpaden, sorteer bestandslijsten en zet de locale vast.
• Bouw in een hermetische omgeving waarvan de toolchain zelf gepind is. Nix is een manier om dat te doen.
• Controleer het: bouw dezelfde commit twee keer, onafhankelijk van elkaar (op een andere machine, in een ander pad, op een andere dag), en vergelijk de uitvoer. Waar de hashes verschillen, laat diffoscope precies zien wat er anders is.

Het Yocto Project laat zien waarom reproduceerbaarheid een eigenschap is die u moet controleren in plaats van aannemen. De documentatie zegt dat de builds van het project sinds release 3.1 reproduceerbaar zijn "tot op binair niveau, inclusief tijdstempels", dat alleen BitBake en OpenEmbedded-Core volledige reproduceerbaarheid garanderen, en dat "zodra u nog een laag toevoegt, deze garantie vervalt". Het project test dat met oe-selftest.

Reproduceerbare builds en SBOM's

Als elke build reproduceerbaar was, kon u een oude release later opnieuw bouwen en de SBOM ervan genereren. De meeste zijn dat niet, dus een nieuwe build, of vandaag een scan van de broncode, beschrijft een vergelijkbare build, niet die u hebt geleverd. De SBOM die laat zien wat er in productie draait, is de SBOM die is vastgelegd uit de CI-build die de release produceerde.

Zelfs een reproduceerbare build maakt dat vastleggen niet overbodig. Overeenkomende hashes bewijzen dat twee builds dezelfde uitvoer gaven; ze sommen niet op wat erin ging. U hebt nog steeds de inventaris nodig, en een eerlijke vermelding van de SBOM-volledigheid. Waarom CI de plek is voor supplychainbeveiliging en SBOM best practices werken het argument verder uit.

SLSA ziet reproduceerbaarheid als één manier om te controleren of een build deed wat hij beweert.

Reproduceerbaarheid bereiken teams in hun buildsysteem, met tools zoals Nix, Yocto of de tooling van Debian. CRACI maakt builds niet reproduceerbaar: het legt de SBOM van elke build vast terwijl de build draait, zodat het bewijs van wat er is geleverd niet afhangt van opnieuw bouwen. Zie build-time SBOM's.