Reproduserbart bygg

Et reproduserbart bygg gir bit for bit identisk resultat hver gang noen bygger den samme kildekoden med det samme byggemiljøet og de samme byggeinstruksjonene. Det er definisjonen fra prosjektet Reproducible Builds. Resultat betyr her artefaktene bygget skal lage: kjørbare filer, distribusjonspakker, container- eller filsystem-images. Logger teller ikke. «Det bygger igjen» er ikke det samme; reproduserbart betyr at bytene stemmer.

Hvorfor de fleste bygg ikke er reproduserbare

• Avhengigheter som løses under bygget. Uten lockfile velger pakkebehandleren versjoner mens bygget kjører. Oppløsning mot PyPI kan ende ulikt avhengig av rekkefølgen svarene kommer i, et versjonsintervall flytter seg når en ny utgivelse kommer, og en foranderlig tagg som latest peker et annet sted.
• Miljøet. Tidsstempler, filstier, locale og vertens egne verktøy havner i artefaktene.
• Tilfeldighet. Byggesteg kan generere ID-er, sortere filer etter hash eller kjøre arbeid parallelt i ulik rekkefølge hver gang.

Å bygge samme commit to ganger på rad gir altså ingen garanti for samme resultat, eller samme SBOM. Et bygg som laster ned kode lockfilen ikke oppgir, en skjult avhengighet, gjør det verre.

Slik gjør team bygg reproduserbare

• Fest og lås alle inndata, også baseimages via digest og verktøy via versjon (se lockfile).
• Bruk et fast tidspunkt i stedet for klokken: SOURCE_DATE_EPOCH er en standardisert miljøvariabel med et Unix-tidsstempel som byggeverktøy bruker i stedet for gjeldende tid.
• Fjern eller normaliser byggestier, sorter fillister og fastsett locale.
• Bygg i et hermetisk miljø der også verktøykjeden er låst. Nix er én måte å gjøre det på.
• Verifiser det: bygg samme commit to ganger, uavhengig av hverandre (på en annen maskin, i en annen sti, en annen dag), og sammenlign resultatene. Der hashene er ulike, viser diffoscope nøyaktig hva som er endret.

Yocto Project viser hvorfor reproduserbarhet er en egenskap man må verifisere i stedet for å anta. Dokumentasjonen sier at prosjektets bygg siden utgivelse 3.1 har vært reproduserbare «helt ned på binærnivå, inkludert tidsstempler», at bare BitBake og OpenEmbedded-Core garanterer full reproduserbarhet, og at «i det øyeblikket du legger til et nytt lag, bortfaller denne garantien». Prosjektet tester det med oe-selftest.

Reproduserbare bygg og SBOM-er

Hvis alle bygg var reproduserbare, kunne du bygge en gammel utgivelse på nytt senere og generere SBOM-en for den. De fleste er ikke det, så et nytt bygg, eller en skanning av kildekoden i dag, beskriver et lignende bygg, ikke det du leverte. SBOM-en som viser hva som er i produksjon, er den som ble registrert fra CI-bygget som laget utgivelsen.

Selv et reproduserbart bygg gjør ikke den registreringen overflødig. Like hasher beviser at to bygg ga samme resultat; de lister ikke opp hva som gikk inn. Du trenger fortsatt oversikten, og en ærlig angivelse av SBOM-fullstendigheten. Hvorfor CI er stedet for forsyningskjedesikkerhet og beste praksis for SBOM utdyper argumentet.

SLSA ser på reproduserbarhet som én måte å verifisere at et bygg gjorde det det hevder.

Reproduserbarhet oppnår team i byggesystemet sitt, med verktøy som Nix, Yocto eller Debians verktøy. CRACI gjør ikke bygg reproduserbare: det registrerer hvert byggs SBOM mens bygget kjører, slik at dokumentasjonen av hva som ble levert ikke avhenger av et nytt bygg. Se SBOM-er fra byggetidspunktet.