Microsoft Introduce Signing Transparency: Een Revolutiet in Codeondertekening

Microsoft heeft de voorlopige versie van Signing Transparency aangekondigd, een beheerde service die het Zero Trust-principe — “vertrouw nooit, verifieer altijd” — naar de wereld van codeondertekening brengt. Dit initiatief is ontworpen om een bekende kwetsbaarheid aan te pakken: geldige handtekeningen zijn in het verleden soms gebruikt om kwaadwillige software te verspreiden. Dit gebeurde wanneer aanvallers certificaten stalen, de bouwketen compromitteerden of misbruik maakten van een vertrouwensidentiteit. Het antwoord ligt in het toevoegen van openbare en verifieerbare bewijzen aan elke handtekening, zodat iedereen kan auditen wat er is ondertekend, wanneer en met welke beleidsregels.

Waarom codeondertekening niet genoeg is

Jarenlang was het ondertekenen van binaire bestanden, containerafbeeldingen of pakketten synoniem met vertrouwen. Echter, traditionele handtekeningen laten geen auditsporen achter buiten het certificaat zelf, en voorkomen niet dat een gestolen sleutel stilzwijgend wordt gebruikt. In dit scenario wordt transparantie de ontbrekende schakel: als elk ondertekenings evenement wordt vastgelegd in een onveranderlijk register, dan verdwijnt de mogelijkheid voor aanvallers om zonder sporen achter te laten te werk te gaan. Veiligheid hangt niet langer alleen af van “wie ondertekent”, maar ook van bewijzen van wanneer en onder welke voorwaarden er werd ondertekend.

Wat is Signing Transparency?

Microsoft beschrijft Signing Transparency als een neutrale notaris voor softwarehandtekeningen. Elke keer dat een artefact — zoals een applicatie release, een OCI-afbeelding of firmware — wordt ondertekend, verifieert de service de handtekening met een verklaard beleid, contrafirma en registreert het evenement in een aanhangregister. In ruil daarvoor wordt er een cryptografisch ontvangstbewijs uitgegeven dat bewijst dat die handtekening bestaat in het register en op welke positie het is opgenomen.

De sleutelbewaking en de integriteit van het register worden gegarandeerd door het gebruik van confidential computing: de service sleutels verlaten nooit de veilige enclave en het register staat geen wijzigingen of verwijderingen toe. Mocht er ooit een ongebruikelijke inzet van een sleutel worden gedetecteerd, dan blijft het spoor vastgelegd voor forensische audit.

Hoe het werkt: COSE, contrafirma’s en Merkle-bomen

De implementatie is gebaseerd op COSE-enveloppen (standaardformaat voor het ondertekenen en verpakken van metadata) en het SCITT-raamwerk voor transparantie in de toeleveringsketen. Het proces is eenvoudig:

1. Het build-systeem genereert een COSE_Sign1 met de handtekening en metadata van het artefact.
2. Deze envelop wordt verzonden naar Signing Transparency, die de identiteit en het beleid controleert (wie kan ondertekenen, vanaf waar, met welke vereisten).
3. De service contrafirmaat de envelop en registreert deze in een Merkle-boom.
4. Er wordt een ontvangstbewijs teruggestuurd met het inclusiebewijs (hashroute) en de huidige root hash van de boom.

De structuur van de Merkle-boom garandeert dat geen enkele invoer kan worden gewijzigd zonder de inclusiebewijzen te breken. Klanten kunnen periodiek de consistentie van de boom controleren, ontvangstbewijzen opslaan en automatiseren validaties in hun CI/CD-pijplijnen.

Wat het biedt ten opzichte van alternatieven en wat het behoudt

Het idee van transparante logs heeft zijn nut al bewezen in het open-source ecosysteem. De vernieuwing hier is een beheerde service met contrafirma’s, portabele ontvangstbewijzen en verankering in enclaves voor organisaties die behoefte hebben aan cryptografische verantwoordelijkheid en traceerbaarheid met auditgaranties. De aanpak breekt de compatibiliteit met bestaande praktijken niet: het kan coëxisteren met traditionele handtekeningen, artifact catalogi of container registers, en voegt een onafhankelijk verificatielaag toe.

Concrete voordelen voor ontwikkeling, beveiliging en compliance

• Verifieerbare traceerbaarheid. Elke levering bevat een onafhankelijk ontvangstbewijs dat kan worden opgeslagen als bewijs voor audits en forensische analyse.
• Zichtbare en afdwingbare beleidsregels. Regels kunnen worden gedefinieerd (dubbele handtekening, tijdvensters, gebruik van HSM/TEE, repo-domeinen), en er kan een publiek register zijn voor de naleving.
• Vroege detectie van anomalieën. Handtekeningen die afwijken van het patroon, onverwachte identiteiten of niet-geplande artefacten vallen op bij het monitoren van het log.
• Mitigatie van replay en rollback. De bewijzen van versheid en consistentie van de boom helpen te voorkomen dat oudere kwetsbare versies opnieuw worden geïntroduceerd.
• Interoperabiliteit met bedrijfs tools. De ontvangstbewijzen kunnen meegestuurd worden met de afbeelding of het pakket en lokaal worden geverifieerd in implementaties, pijplijnen en compliance-platforms.

Meer dan alleen software: firmware en hardware

Hetzelfde principe — handtekeningen met auditeerbare transparantie — wordt uitgebreid naar firmware en hardwarecomponenten. Met vertrouwenswortels in silicium en veilige opstartmaatregelen, voegt transparantie een openbaar bewijs toe van wie elke update heeft ondertekend, wanneer en onder welke beleidsregels. Het uiteindelijke doel is een toeleveringsketen met verifieerbare integriteit van end-to-end, vanaf het circuitbord tot de runtime.

Wat het niet oplost (en waarom het nog steeds essentieel is)

Signing Transparency vervangt niet een veilige SDLC of basis hygiëne: afhankelijke analyses, code-review, geheimbeheer, segmentatie van de pijplijn of beveiligingstests blijven essentieel. Transparantie verhindert niet dat een aanvaller een kwetsbaarheid benut als de code schoon de build bereikt. Wat het wel doet, is de kosten van geheimhouding verhogen en de detectietijd verlagen: of de aanvaller verbergt zich voor het log — wat de onregelmatigheid onthult — of laat een onuitwisbaar spoor achter dat actie mogelijk maakt.

Hoe je je kunt voorbereiden op adoptie

1. Inventaris van artefacten. Breng in kaart wat er wordt ondertekend (binaire bestanden, pakketten, afbeeldingen, firmware) en wie ondertekent.
2. Ondertekenbeleid. Definieer identiteiten, voorwaarden, co-handtekeningen en migratiecontroles.
3. Beheer van ontvangstbewijzen. Bepaal waar ze worden opgeslagen, hoe ze aan artefacten worden gekoppeld en wie ze valideert bij implementatie.
4. Automatisering CI/CD. Integreer het indienen aan het log en de verificatie van ontvangstbewijzen als verplichte stappen.
5. Continue monitoring. Houd de consistentie van de boom, gebruikanomaliën, en beleidsinbreuken in de gaten.

Veelgestelde vragen

Wat is een cryptografisch ontvangstbewijs en waarvoor dient het?
Het is een verplaatsbaar bewijs dat de root hash van de boom en de inclusieroute van je handtekening in het log bevat. Hiermee kan op elk moment en zonder toestemming van de leverancier worden aangetoond dat je artefact op een specifieke datum en positie is ondertekend en geregistreerd.

Moet ik mijn handtekeningtools veranderen?
Niet per se. Als je al ondertekent met bedrijfspecifieke certificaten of vanuit HSM, kun je de handtekening verpakken in een COSE-envelope en deze naar de service sturen voor de contrafirma en het ontvangstbewijs. Bij voorkeur automatiseer je deze stap in CI/CD.

Wat als een sleutel gecompromitteerd wordt?
Elk gebruik wordt vastgelegd; onverwachte of buiten beleid handtekeningen kunnen worden gedetecteerd door het log te monitoren. Transparantie voorkomt niet het misbruik, maar maakt het zichtbaar en versnelt de reactie (intrekking, blokkering, rotatie).

Hoe integreert dit met audits en regelgevende kaders?
De ontvangstbewijzen dienen als objectief bewijs van wijzigingscontrole en governance van releases. Ze vergemakkelijken de naleving van vereisten voor traceerbaarheid, niet-ontkenning en demonstratie van controles in certificeringen en audits.

Valt dit ook onder containers en firmware?
Ja. Elk ondertekenbaar artefact — OCI-afbeeldingen, pakketten, binaire bestanden, firmware — kan worden geregistreerd voor obtenir transparantie en inclusiebewijs, wat de integriteit in de hele keten versterkt.

In conclusie, Signing Transparency beoogt niet om de handtekening van code te “vervangen”, maar om verantwoording af te leggen. Door contrafirma’s, onveranderlijke registraties en confidential computing te combineren, transformeert het elke release in een verifieerbaar feit, minimaliseert het de ruimte voor stille aanvallen en verhoogt het de standaard van vertrouwen en verantwoordelijkheid in de toeleveringsketen. Voor engineering- en beveiligingsteams is het een praktische hefboom om van “vertrouw omdat het is ondertekend” naar “vertrouw omdat je het kunt verifiëren” te gaan.

VIA: azure.microsoft