Jag ser Build provenance och SLSA-tänk som en praktisk säkerhetsfråga där tekniken behöver kunna verifieras, inte bara beskrivas. Build provenance handlar om att kunna visa vilka källor, verktyg och steg som producerade en artefakt och därmed göra leveranskedjan svårare att manipulera i det tysta.
Build provenance och SLSA-tänk i praktiken
Första byggstenen: Provenance bör binda artefaktens digest till buildprocessen. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
En annan viktig del: Hermetiska eller kontrollerade byggmiljöer minskar dold input. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: Signerad attestering kan verifieras separat från själva artefakten. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det som ofta avgör kvaliteten: SLSA är ett ramverk för att höja assurance stegvis snarare än en enskild produkt. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Ett arbetsflöde jag skulle använda
- Identifiera alla externa inputs till build.
- Pinna versioner på byggverktyg och dependencies där möjligt.
- Bygg i isolerad CI-miljö.
- Skapa digest och provenance efter build.
- Verifiera attestering före promotion till produktion.
För Build provenance och SLSA-tänk håller jag därför införandet i små steg. Då går det att skilja ett säkerhetsproblem från ett rent driftfel och att rulla tillbaka just den ändring som gav ett oväntat resultat.
Ett konkret scenario
Om två binärer har samma versionsnummer men olika hash vill jag kunna svara på vilken pipeline som skapade respektive fil. Provenance gör den frågan till data i stället för muntlig historik.
Vanliga sätt att göra kontrollen svagare
- Att signera en artefakt utan att veta vilken build som skapade den.
- Att låta utvecklarens lokala miljö vara enda releasevägen.
- Att använda föränderliga externa resurser utan digest eller version.
Vad som måste gå att bevisa
För Build provenance och SLSA-tänk vill jag avsluta med mätbara efterkontroller i stället för att nöja mig med att en statusruta visar ”enabled”. De viktigaste kontrollerna här är:
- Artefaktens digest matchar provenance.
- Build-id går att spåra till commit och pipeline.
- Promotion stoppar artefakter som saknar godkänd attestering.
Ett negativt test hör också till Build provenance och SLSA-tänk: den väg, identitet eller operation som inte ska vara tillåten ska misslyckas på ett förutsägbart sätt. Då kan nästa tekniker upprepa kontrollen och förstå både avsikten och gränsen.
Slutsats
Build provenance och SLSA-tänk – kunna svara på hur en binär blev byggd handlar därför inte om att samla fler säkerhetsinställningar. Det handlar om att minska en konkret risk med en kontroll som har tydligt scope, tydlig ägare och ett verifierbart resultat. När före-läge, förändring och eftertest dokumenteras blir säkerhetsarbetet både säkrare och lättare att förvalta.