Manifestbestand: de digitale paklijst achter software
Wie een pakket bestelt, krijgt er vaak een paklijst bij: een overzicht van wat erin zit, hoeveel stuks, en soms een waarschuwing als er iets breekbaars tussen zit. Een manifestbestand is de digitale versie daarvan, maar dan voor software. Het is een klein tekstbestand dat bij een programma, app of pakket wordt meegeleverd en dat vertelt wat het is, welke onderdelen het bevat, welke versie het heeft en wat het nodig heeft om te werken.
Een concreet voorbeeld: installeer je een app op je Android-telefoon, dan zit daar een bestand in met de naam AndroidManifest.xml. Daarin staat onder meer welke rechten de app nodig heeft, bijvoorbeeld toegang tot je camera of contacten. Je telefoon leest dat bestand voordat de app ook maar één regel eigen code uitvoert, en toont je op basis daarvan de bekende vraag: "Deze app wil toegang tot...". Zonder manifest zou het besturingssysteem in het duister tasten over wat het te installeren onderdeel eigenlijk is.
Wat is het precies?
Technisch gezien is een manifestbestand meestal gewoon platte tekst, geschreven in een gestructureerd formaat dat zowel mensen als computers kunnen lezen. Veelgebruikte formaten zijn JSON (JavaScript Object Notation, een simpele manier om gegevens als sleutel-waardeparen op te schrijven), XML (eXtensible Markup Language, met tags zoals in HTML) en soms YAML, een variant die nog leesbaarder probeert te zijn.
Wat er precies in staat verschilt per toepassing, maar een aantal elementen komt steeds terug. Ten eerste identificerende gegevens: de naam van het programma of pakket en het versienummer. Ten tweede afhankelijkheden: een lijst van andere software-onderdelen die nodig zijn om het geheel te laten werken, vaak met het exacte versienummer erbij. Ten derde rechten of permissies: waar mag dit onderdeel bij, denk aan bestanden, netwerk of hardware. Ten vierde technische verwijzingen, zoals het "entry point" — het bestand waarmee het programma start — en soms checksums: een soort digitale vingerafdruk (een berekende reeks tekens) waarmee je kunt controleren of een bestand niet onderweg is aangepast of beschadigd.
Software leest het manifest op een cruciaal moment: bij installatie, bij het bouwen (compileren) van een programma, of bij het opstarten ervan. De computer of het besturingssysteem controleert dan eerst het manifest voordat het de rest van het pakket in gebruik neemt. Ontbreekt er iets, of komt een checksum niet overeen, dan kan de installatie of start worden geweigerd.
Wat wil men ermee bereiken?
De kern van het idee is standaardisatie: als iedereen dezelfde soort "paklijst" gebruikt, kunnen verschillende programma's, systemen en zelfs bedrijven elkaars software automatisch begrijpen zonder dat een mens er steeds naar hoeft te kijken. Dat maakt automatisering mogelijk: installatieprogramma's, app-stores en bouwsystemen kunnen op basis van het manifest zelfstandig beslissen wat ze moeten downloaden, installeren of weigeren.
Een tweede doel is reproduceerbaarheid: als een manifest precies vastlegt welke versies van welke onderdelen zijn gebruikt, kan iemand anders — of dezelfde ontwikkelaar een jaar later — exact dezelfde software opnieuw opbouwen. Dat is belangrijk voor betrouwbaarheid en voor het opsporen van fouten.
Een derde, steeds belangrijker doel is verifieerbaarheid en beveiliging. Met een manifest kun je nagaan of software niet stiekem is aangepast, en welke onderliggende componenten erin zitten. Dat laatste is relevant omdat veel software tegenwoordig is opgebouwd uit tientallen of honderden kleinere, vaak extern gemaakte bouwstenen. Als in zo'n bouwsteen een kwetsbaarheid wordt ontdekt, wil je snel kunnen nagaan welke van je eigen programma's die bouwsteen gebruiken — en dat kan alleen als er ergens een betrouwbare lijst van bestaat.
Voorbeelden uit de praktijk
AndroidManifest.xml maakt sinds de allereerste release van Android in 2008 deel uit van elke Android-app. Het legt onder meer de benodigde apparaatrechten en de minimale Android-versie vast.
package.json is het manifestbestand van npm, de in 2010 gelanceerde pakketbeheerder voor JavaScript. Vrijwel elk modern webproject bevat zo'n bestand, met de naam van het project, de versie en een lijst van alle externe code-bibliotheken waarvan het afhankelijk is.
Het Web App Manifest is een W3C-standaard (World Wide Web Consortium, de organisatie die webstandaarden beheert) die rond 2015 populair werd, mede dankzij Google, in de context van zogeheten Progressive Web Apps: websites die zich als een app op je telefoon laten installeren. Het manifest bevat dan bijvoorbeeld de naam van de "app", het icoon en de kleur van de statusbalk.
Bij containers — een manier om software met al zijn benodigdheden in een afgesloten, overdraagbaar pakket te stoppen, populair gemaakt door Docker sinds 2013 — hoort een image-manifest dat beschrijft uit welke lagen de container is opgebouwd. Sinds de oprichting van het Open Container Initiative (OCI) in 2015, met een eerste formele image-specificatie in 2017, is dit manifestformaat een breed gedragen industriestandaard geworden.
Recenter, en met een sterk beveiligingsdoel, zijn SBOM's (Software Bill of Materials, letterlijk "materiaallijst van software"). Twee bekende formaten zijn CycloneDX, een project van de beveiligingsorganisatie OWASP dat rond 2017 ontstond, en SPDX, een initiatief van de Linux Foundation dat al zo'n tien jaar eerder begon en in 2021 werd geformaliseerd tot de internationale norm ISO/IEC 5962:2021.
Hoe ver is de techniek?
Manifestbestanden voor het verpakken en installeren van software zijn allang geen nieuwigheid meer: formaten als AndroidManifest.xml en package.json zijn volwassen, breed gestandaardiseerd en worden dagelijks door miljoenen ontwikkelaars gebruikt zonder dat daar veel discussie over bestaat.
Het jongere gebruik van manifesten als beveiligingsinstrument — de SBOM — staat nog volop in ontwikkeling. Regelgeving zet hier stevig vaart achter. In de Verenigde Staten verplichtte een presidentieel decreet (Executive Order 14028, mei 2021) leveranciers van software aan de federale overheid om een SBOM te leveren. In de Europese Unie moet de in 2024 aangenomen Cyber Resilience Act fabrikanten van producten met digitale elementen verplichten om beter zicht te houden op de software-componenten die zij gebruiken.
Toch zijn er nog flinke obstakels. Er bestaat geen enkel universeel manifestformaat: CycloneDX en SPDX bestaan naast elkaar en zijn niet altijd naadloos uitwisselbaar. Tooling om manifesten automatisch te genereren, te controleren en te vergelijken is nog volop in ontwikkeling en verschilt sterk in kwaliteit. Een manifest kan bovendien onvolledig of verouderd zijn — het is uiteindelijk een document dat iemand (of een programma) moet bijhouden, en fouten of omissies sluipen er makkelijk in. Belangrijk om te beseffen: het hebben van een manifest of SBOM betekent niet automatisch dat software veilig is, het is een hulpmiddel om sneller te kunnen zien waar risico's kunnen zitten, niet een garantie.
Wie werken eraan?
Aan de kant van software-verpakking en apps zijn het vooral de makers van platforms zelf die de standaarden bepalen: Google voor Android en voor het Web App Manifest (samen met de bredere webgemeenschap via het W3C), en npm Inc. (tegenwoordig onderdeel van GitHub) voor package.json.
Bij containers trekt het Open Container Initiative (OCI), een samenwerkingsverband van meerdere techbedrijven onder de paraplu van de Linux Foundation, de standaarden voor image-manifesten.
Op het gebied van SBOM's zijn de belangrijkste spelers OWASP (Open Worldwide Application Security Project, een non-profit gericht op softwarebeveiliging) met CycloneDX, en de Linux Foundation met SPDX. Daarnaast bemoeien overheidsinstanties zich er steeds nadrukkelijker mee: in de VS onder meer CISA (Cybersecurity and Infrastructure Security Agency), NIST (National Institute of Standards and Technology) en NTIA (National Telecommunications and Information Administration), en in Europa ENISA (het Europese agentschap voor cyberbeveiliging) en de Europese Commissie via de Cyber Resilience Act.