Wat Astrals beveiligingsplaybook onthult over de kracht van SBOM's
Ritesh Noronha
Er is een gezegde in de SBOM-gemeenschap waar we steeds op terugkomen: SBOM's zijn geen wondermiddel. Dat is waar. Ze zullen je organisatiestructuur niet herstellen, 2FA niet afdwingen, en een malafide insider niet tegenhouden om een slechte release te pushen.
Maar na het lezen van Astral's opmerkelijke uiteenzetting over hoe zij Ruff, uv en ty beveiligen, viel ons iets op: in onze analyse kan ongeveer 60% van de praktijken die zij beschrijven direct worden bereikt, uitgebreid of controleerbaar gemaakt via SBOM's, attestaties en gerelateerde supplychain-artefacten.
Dat is niet alles. Maar het is veel — vooral als je bedenkt dat het meeste van wat Astral vandaag doet diepe institutionele kennis, handmatige beoordeling en op maat gemaakte tooling vereist die maar weinig projecten kunnen reproduceren.
Hier is onze analyse van waar SBOM's en Astral's praktijken elkaar raken, waar dat niet zo is, en waarom die schatting belangrijker is dan het resterende deel dat nog steeds afhankelijk is van menselijke en organisatorische controles.
Zichtbaarheid van afhankelijkheden: de basis
Het meest SBOM-native deel van Astrals bericht gaat over afhankelijkheidsbeveiliging. Ze beschrijven het gebruik van Dependabot en Renovate voor updates, het onderhouden van sociale contacten met upstream-maintainers, terughoudend zijn met het toevoegen van nieuwe afhankelijkheden, en zelfs het financieel ondersteunen van projecten waar ze van afhankelijk zijn via hun OSS Fund.
Dit alles begint met een fundamentele vraag: waar ben je eigenlijk van afhankelijk?
Een SBOM kan hierop antwoord geven, mits deze met voldoende dekking wordt gegenereerd. Een goed opgesteld CycloneDX- of SPDX-document voor uv somt niet alleen directe Cargo-afhankelijkheden op — het kan ook transitieve afhankelijkheden, gevendor-de bibliotheken, buildtools en platformspecifieke componenten vastleggen die bij handmatige audits vaak worden gemist. Bij Interlynk verwerkt ons SBOM-beheerplatform deze documenten en biedt het continue zichtbaarheid in de afhankelijkheidsgrafiek, waardoor het mogelijk wordt om:
Trends in het aantal afhankelijkheden over releases heen te volgen (verminder je je aanvalsoppervlak daadwerkelijk?)
Componenten te markeren die binaire blobs introduceren of buitensporig veel transitieve afhankelijkheden binnenhalen
Verweesde of niet-onderhouden upstream-projecten te identificeren voordat ze risico's worden
Te prioriteren welke upstream-projecten financiële steun verdienen op basis van de werkelijke criticaliteit in je afhankelijkheidsboom
Wat Astral doet via institutionele kennis en sociale connecties, kunnen SBOM's herhaalbaarder en beter controleerbaar maken — vooral belangrijk naarmate organisaties opschalen voorbij het vermogen van één team om mentale modellen van hun toeleveringsketen te onderhouden.
Afhankelijkheidsafkoelperioden: een beleid dat SBOM's kunnen afdwingen
Een van de interessantere praktijken die Astral beschrijft, zijn dependency-cooldowns — het bewust uitstellen van de adoptie van nieuwe dependency-versies om het tijdsvenster te vermijden waarin tijdelijk gecompromitteerde pakketten het gevaarlijkst zijn. Ze merken op dat Renovate, Dependabot en uv zelf allemaal cooldowns ondersteunen.
Dit is een risicobeheerbeleid dat SBOM's kunnen helpen afdwingbaar te maken. Een platform zoals Interlynk haalt de meest recente release-metadata rechtstreeks op bij pakketbeheerders — PyPI, crates.io, npm en andere — en kan beleidsregels definiëren die componenten markeren of blokkeren die te snel na publicatie worden geadopteerd. In plaats van alleen te vertrouwen op Renovate- of Dependabot-configuraties die kunnen afwijken of worden overschreven, creëert dit een continue, controleerbare handhavingslaag: als een component in je SBOM 12 uur geleden is gepubliceerd en je cooldown-beleid 72 uur vereist, kan het beleid dit opvangen zolang de component en versie zijn vastgelegd en de release-metadata beschikbaar is.
Release-integriteit: waar SBOM's en attestaties samenkomen
De releasebeveiligingssectie van Astral beschrijft Sigstore-attestaties, onveranderlijke releases, Trusted Publishing en checksums die zijn ingebed in hun zelfstandige installer. Dit zijn allemaal mechanismen om vast te stellen dat een artefact authentiek is — dat het uit een bekend buildproces komt en niet is gemanipuleerd.
SBOM's passen van nature in deze keten. In de praktijk is het artefact doorgaans het onderwerp van de attestatie, terwijl de SBOM wordt toegevoegd of gerefereerd als de ondertekende verklaring over dat artefact. Goed uitgevoerd beantwoordt dit gelijktijdig drie vragen:
Wat zit er in dit artefact? (de componenteninventaris van de SBOM)
Waar komt het vandaan? (de builder-identiteit en workflowverwijzing van de attestatie)
Is ermee geknoeid? (de cryptografische handtekening die beide aan elkaar bindt)
Astral genereert al Sigstore-attestaties voor hun binaire en Docker-releases. Door deze te koppelen aan SBOM's — en die SBOM's beschikbaar te maken via een beheerplatform — kunnen downstream-afnemers niet alleen verifiëren dat ze een legitieme build van uv hebben ontvangen, maar ook inspecteren wat er in die build is opgenomen. Dit is met name relevant voor de gebruikers van Astral in gereguleerde sectoren waar documentatie van herkomst niet optioneel is.
Bij Interlynk is dit fundamenteel.
CI/CD als een toeleveringsketen: de build-SBOM
Een deel van Astral's meest intensieve beveiligingswerk is gericht op hun CI/CD-pipelines — hash-pinning van GitHub Actions, handmatige beoordeling van actions op wijzigbare keuzes, isolatie van secrets in deploymentomgevingen, en het verbieden van gevaarlijke workflow-triggers. Dit zijn arbeidsintensieve taken die een hoog vaardigheidsniveau vereisen.
CycloneDX introduceerde formulation in versie 1.5 en heeft dit sindsdien verder uitgebreid, waardoor het formaat een manier kreeg om build-pipelines als gestructureerde data te beschrijven — de tools, actions, omgevingen en configuraties die betrokken zijn bij het produceren van een artifact. Dit bevindt zich nog in een vroege fase binnen het ecosysteem, maar de richting is duidelijk: buildprocessen zijn zelf supply chain-componenten en moeten als zodanig worden geïnventariseerd.
Een SBOM die formulation-data bevat, zou delen van Astral's CI/CD-hardening beter controleerbaar kunnen maken voor downstream-consumenten, waar tooling dit ondersteunt. In plaats van volledig te vertrouwen op de beschrijving van een project, kunnen consumenten gestructureerde buildmetadata inspecteren naast andere supply chain-artifacts. Dit creëert ook verantwoordelijkheid: als je build-SBOM een unpinned action toont, daalt je SBOM-kwaliteitsscore — precies het soort signaal dat onze SBOM-kwaliteitstool sbomqs is ontworpen om zichtbaar te maken.
Kwetsbaarheidsbeheer op afhankelijkheidsniveau
Astral beschrijft het onderhouden van sociale verbindingen met projecten zoals het Python Security Response Team en PyPA om kwetsbaarheidsinformatie over projectgrenzen heen te delen — bijvoorbeeld wanneer een melding tegen pip ook uv beïnvloedt.
Dit is een sociaal proces dat een dataprobleem oplost. Met SBOM's wordt kwetsbaarheidscorrelatie tussen projecten veel systematischer. Als zowel pip als uv een gemeenschappelijke component delen, en die component een CVE heeft, kan een SBOM-bewust kwetsbaarheidsplatform beide projecten gelijktijdig markeren. Dat vervangt geen mailinglijsten, vertrouwensrelaties of gecoördineerde openbaarmaking, maar het vermindert wel hoeveel ervan afhangt.
Bij Interlynk doet onze laag voor kwetsbaarheidsinformatie precies dit. We matchen SBOM-componenten met NVD, OSV en leveranciersadviezen met behulp van PURL's en CPE's, en we behandelen de lastige grensgevallen — vals-positieven door distro-backports, gevendoriseerde forks met niet-standaard versiebeheer, CPE-dekkingslacunes voor embedded en nichecomponenten — die naïeve kwetsbaarheidsmatching onbetrouwbaar maken.
VEX (Vulnerability Exploitability eXchange) voegt hier nog een laag aan toe. Wanneer Astral vaststelt dat een CVE in een afhankelijkheid uv in feite niet beïnvloedt omdat het kwetsbare codepad niet bereikbaar is, kan die beoordeling worden vastgelegd als een VEX-verklaring die aan de SBOM is gekoppeld. Dit verandert een eenmalige triagebeslissing in een herbruikbaar, machineleesbaar artefact waar elke downstreamgebruiker van profiteert.
De andere 40%: wat SBOM's niet dekken — en waarom dat juist de bedoeling is
Dit is waar de eerlijkheid van "geen wondermiddel" belangrijk wordt. In onze analyse valt een aanzienlijk deel van Astrals beveiligingshouding duidelijk buiten het SBOM-domein:
Organisatorische controles — Het afdwingen van 2FA, het beperken van beheerdersrechten, het verbieden dat beheerders beveiligingen omzeilen. Dit zijn problemen op het gebied van identiteits- en toegangsbeheer.
CI/CD-triggerbeleid — Het organisatiebreed verbieden van
pull_request_targetenworkflow_run. Dit is platformgovernance.Tweepersoonsgoedkeuring voor releases — Een menselijke procescontrole die geen enkel documentformaat kan vervangen.
Geen caching in release-builds — Een beleidsbeslissing voor builds.
GitHub App-isolatie — Een architectuurpatroon om geprivilegieerde handelingen te scheiden van CI/CD.
SBOM's doen niet alsof ze deze problemen oplossen, en iedereen die je iets anders vertelt, probeert je iets te verkopen. Het juiste mentale model bestaat uit lagen: organisatorische controles zorgen ervoor dat het proces veilig is, SBOM's documenteren de inhoud, attestaties authenticeren beweringen over artefacten, en kwetsbaarheidsbeheer beoordeelt of die inhoud veilig is. Elke laag versterkt de andere. Geen enkele laag is op zichzelf voldoende. Maar zonder de SBOM-laag zeggen de andere lagen minder over wat er daadwerkelijk in het artefact zit dat je beveiligt.
Het grotere geheel: 60% is veel
Wat Astrals bericht indrukwekkend maakt, is ook wat het ontnuchterend maakt: de enorme hoeveelheid handmatige inspanning, institutionele kennis en op maat gemaakte tooling die nodig is om een goed gefinancierd open-sourceproject te beveiligen. De meeste projecten — vooral in de embedded firmware- en IoT-omgevingen waarmee we bij Interlynk werken — hebben niet de middelen om dit te repliceren.
SBOM's brengen je niet naar 100%. Niets zal dat doen. Beveiliging bestaat uit lagen, en iedereen die een wondermiddel belooft, negeert het deel dat nog steeds menselijk beoordelingsvermogen, organisatorische discipline en controles op platformniveau vereist.
Maar het gedeelte dat SBOM's raken — zichtbaarheid van afhankelijkheden, correlatie van kwetsbaarheden, herkomst van releases, handhaving van cooldowns, controleerbaarheid van builds, VEX-gestuurde triage — vertegenwoordigt het deel van supplychainbeveiliging dat geautomatiseerd, gemeten en continu gemonitord kan worden in plaats van te vertrouwen op heroïsche individuele inspanning. En voor de overgrote meerderheid van projecten die Astrals investering niet kunnen evenaren, is dat vaak het verschil tussen een beveiligingshouding hebben en hoop hebben.
SBOM's zijn geen wondermiddel. Ze vormen de basis die al het andere verifieerbaar maakt.