Reproducerbart build

Et reproducerbart build giver bit for bit identisk output, hver gang nogen bygger den samme kildekode med det samme byggemiljø og de samme byggeinstruktioner. Det er definitionen fra projektet Reproducible Builds. Output betyder her de artefakter, buildet skal frembringe: eksekverbare filer, distributionspakker, container- eller filsystem-images. Logfiler tæller ikke. "Det bygger igen" er ikke det samme; reproducerbart betyder, at bytene stemmer.

Hvorfor de fleste builds ikke er reproducerbare

• Afhængigheder, der opløses under buildet. Uden lockfile vælger en pakkehåndtering versioner, mens buildet kører. Opløsningen mod PyPI kan falde forskelligt ud afhængigt af, i hvilken rækkefølge svarene kommer, et versionsinterval flytter sig, når en ny release kommer, og et foranderligt tag som latest peger et andet sted hen.
• Miljøet. Tidsstempler, filstier, locale og værtens egne værktøjer ender i artefakterne.
• Tilfældighed. Byggetrin kan generere id'er, sortere filer efter hash eller køre arbejde parallelt i en ny rækkefølge hver gang.

At bygge det samme commit to gange i træk giver altså ingen garanti for det samme resultat eller den samme SBOM. Et build, der downloader kode, som lockfilen ikke angiver, en skjult afhængighed, gør det værre.

Hvordan teams gør builds reproducerbare

• Fastlås og lås alle input, også base images via digest og værktøjer via version (se lockfile).
• Brug et fast tidspunkt i stedet for uret: SOURCE_DATE_EPOCH er en standardiseret miljøvariabel med et Unix-tidsstempel, som byggeværktøjer bruger i stedet for det aktuelle tidspunkt.
• Fjern eller normalisér byggestier, sortér fillister og fastlæg locale.
• Byg i et hermetisk miljø, hvis værktøjskæde selv er fastlåst. Nix er én måde at gøre det på.
• Verificér det: byg det samme commit to gange, uafhængigt af hinanden (på en anden maskine, i en anden sti, en anden dag), og sammenlign resultaterne. Hvor hashene er forskellige, viser diffoscope præcis, hvad der er ændret.

Yocto Project viser, hvorfor reproducerbarhed er en egenskab, man skal verificere i stedet for at antage. Dets dokumentation siger, at projektets builds siden release 3.1 har været reproducerbare "helt ned på binært niveau, inklusive tidsstempler", at kun BitBake og OpenEmbedded-Core garanterer fuld reproducerbarhed, og at "i det øjeblik du tilføjer endnu et lag, bortfalder denne garanti". Projektet tester det med oe-selftest.

Reproducerbare builds og SBOM'er

Hvis alle builds var reproducerbare, kunne du bygge en gammel release igen senere og generere dens SBOM. De fleste er det ikke, så et nyt build, eller en scanning af kildekoden i dag, beskriver et lignende build, ikke det, du leverede. Den SBOM, der viser, hvad der er i produktion, er den, der blev registreret fra det CI-build, der frembragte releasen.

Selv et reproducerbart build gør ikke den registrering overflødig. Matchende hashes beviser, at to builds gav det samme output; de oplister ikke, hvad der gik ind. Du har stadig brug for fortegnelsen og en ærlig angivelse af dens SBOM-fuldstændighed. Hvorfor CI er stedet for supply chain-sikkerhed og SBOM best practices uddyber argumentet.

SLSA betragter reproducerbarhed som én måde at verificere, at et build gjorde det, det påstår.

Reproducerbarhed opnår teams i deres byggesystem med værktøjer som Nix, Yocto eller Debians værktøjer. CRACI gør ikke builds reproducerbare: det registrerer hvert builds SBOM, mens buildet kører, så dokumentationen for, hvad der blev leveret, ikke afhænger af et nyt build. Se build-time SBOM'er.