Reproducerbart bygge

Ett reproducerbart bygge ger bit för bit identiskt resultat varje gång någon bygger samma källkod med samma byggmiljö och samma bygginstruktioner. Det är definitionen från projektet Reproducible Builds. Resultatet avser här de artefakter bygget är till för: körbara filer, distributionspaket, container- eller filsystemavbildningar. Loggar räknas inte. "Det bygger igen" är inte samma sak; reproducerbart betyder att byten stämmer.

Varför de flesta byggen inte är reproducerbara

• Beroenden som löses upp under bygget. Utan lockfile väljer pakethanteraren versioner när bygget körs. Upplösningen mot PyPI kan bli olika beroende på i vilken ordning svaren kommer, ett versionsintervall flyttar sig när en ny release kommer ut, och en föränderlig tagg som latest pekar någon annanstans.
• Miljön. Tidsstämplar, filsökvägar, locale och värdens egna verktyg hamnar i artefakterna.
• Slump. Byggsteg kan generera id:n, sortera filer efter hash eller köra arbete parallellt i olika ordning varje gång.

Att bygga samma commit två gånger i rad ger alltså ingen garanti för samma resultat, eller för samma SBOM. Ett bygge som laddar ner kod som lockfilen inte listar, ett dolt beroende, gör saken värre.

Hur team gör byggen reproducerbara

• Lås och fäst varje indata, även basavbildningar via digest och verktyg via version (se lockfile).
• Använd en fast tid i stället för klockan: SOURCE_DATE_EPOCH är en standardiserad miljövariabel med en Unix-tidsstämpel som byggverktyg använder i stället för aktuell tid.
• Ta bort eller normalisera byggsökvägar, sortera fillistor och fixera locale.
• Bygg i en hermetisk miljö vars verktygskedja i sig är låst. Nix är ett sätt att göra det.
• Verifiera det: bygg samma commit två gånger, oberoende av varandra (på en annan maskin, i en annan sökväg, en annan dag), och jämför resultaten. Där hasharna skiljer sig visar diffoscope exakt vad som ändrats.

Yocto Project visar varför reproducerbarhet är en egenskap man måste verifiera i stället för att anta. Dess dokumentation säger att projektets byggen sedan release 3.1 är reproducerbara "ända ner på binärnivå, inklusive tidsstämplar", att bara BitBake och OpenEmbedded-Core garanterar fullständig reproducerbarhet, och att "så snart du lägger till ett nytt lager upphör den här garantin att gälla". Projektet testar det med oe-selftest.

Reproducerbara byggen och SBOM:er

Om varje bygge vore reproducerbart kunde du bygga om en gammal release senare och generera dess SBOM. De flesta är det inte, så en ombyggnad, eller en skanning av källkoden i dag, beskriver ett liknande bygge, inte det du levererade. Den SBOM som visar vad som finns i produktion är den som registrerades från CI-bygget som tog fram releasen.

Inte ens ett reproducerbart bygge gör den registreringen överflödig. Matchande hashar bevisar att två byggen gav samma resultat; de listar inte vad som gick in. Du behöver fortfarande förteckningen, och en ärlig uppgift om dess SBOM-fullständighet. Varför CI är platsen för leveranskedjesäkerhet och bästa praxis för SBOM utvecklar resonemanget.

SLSA ser reproducerbarhet som ett sätt att verifiera att ett bygge gjorde det det påstår.

Reproducerbarhet uppnår team i sitt byggsystem, med verktyg som Nix, Yocto eller Debians verktyg. CRACI gör inte byggen reproducerbara: det registrerar varje bygges SBOM medan bygget körs, så att underlaget för vad som levererades inte hänger på en ombyggnad. Se SBOM:er från bygget.