Google: Je hebt een beetje 'salsa' nodig voor veilige software

SLSA is gebaseerd op een proces genaamd 'Binary Authorization for Borg' (BAB) dat Google zelf al meer dan acht jaar intern gebruikt om de oorsprong van code vast te stellen en de identiteit van code vast te leggen. Een whitepaper over deze methodiek werd opgepikt door ZDNet.

Het BAB-proces zorgt ervoor dat alle code die gebruikt wordt bij Google, aan een grondige review is onderworpen. Google past BAB zo veel mogelijk toe, maar zeker bij software die toegang heeft tot gegevens van klanten. 

Stap verder met SLSA

SLSA gaat een stap verder en is bedoeld om van begin tot eind alles vast te leggen in de keten waarin software tot stand komt. Van de developer tot de broncode het platform waarop is gebouwd, de continuous integration/continuous delivery-systemen de package repository en de afhankelijkheden.

"Het doel van SLSA is om de industrie een betere bescherming te bieden tegen de meest voorkomende bedreigingen van de integriteit, en dan met name de afhankelijkheden. Met de komst van SLSA kunnen gebruikers een veel betere geïnformeerde keuze maken met betrekking tot de beveiligingsstaat van de software die ze willen gebruiken", stelt Google in een toelichting aan ZDNet.

Onderdeel van SLSA zijn bijvoorbeeld protocollen die Google al eerder dit jaar publiceerde, waarin bij opensource-softwareontwikkeling er een code review plaatsvindt van tenminste twee onafhankelijke partijen en voor het onderhoud aan de code minimaal tweefactor-authenticatie is vereist.

SLSA is nu nog een setje richtlijnen, maar Google ziet wel een toekomst in een meer dwingend karakter ervan. Met het automatisch opstellen van metadata die aan een audit kunnen worden onderworpen, zouden 'policy engines' voor een SLSA-certificering kunnen zorgen van een bepaald softwarepakket of een ontwikkelplatform.

SolarWinds-aanval had met SLSA niet gekund

De aanpak van Google zou bescherming moeten geven tegen de problemen die ontstonden in de SolarWinds-affaire. Daarbij drongen aanvallers binnen bij deze leverancier van een softwarebeheerplatform dat door heel veel grote en voor criminelen en spionnen interessante organisaties werd gebruikt. Met een reguliere, vertrouwde software-update kwam door de aanvallers gewijzigde code binnen bij duizenden organisaties wereldwijd, die daarmee makkelijk toegankelijk werden voor malafide praktijken zonder dat ze er erg in hadden. Met de SLSA-methodiek zou duidelijk zijn geworden dat de door de criminelen aangebrachte wijziging niet op een reguliere manier was ingebouwd.

Hoewel deze SolarWinds-aanval veel aandacht trok wijst Google op meer voorvallen waarbij een digitale inbraak via een toeleverancier werd opgezet.