Er wordt een lek gemeld in een veelgebruikt component. De vraag is niet of het ernstig is, maar of het u raakt. Wie een actuele SBOM heeft, beantwoordt dat in minuten; wie hem niet heeft, is dagen bezig met bellen. Wij zorgen dat de lijst automatisch bij elke bouw ontstaat en dus niet kan verouderen.
Een Software Bill of Materials is een lijst van alles wat er in uw software zit: per onderdeel de naam, de versie, de herkomst en de licentie. Dat lijkt weinig, en het is precies genoeg om de twee vragen te beantwoorden die er ooit toe doen: raakt dit ons, en mogen wij dit zo gebruiken. Belangrijker dan de velden is de reikwijdte — een lijst met alleen de onderdelen die u zelf heeft gekozen, mist het grootste deel, want de verrassingen zitten in wat daarmee is meegekomen.
De reden dat dit nu overal opduikt, is tweeledig. De Cyber Resilience Act vraagt van fabrikanten een machineleesbare SBOM van ten minste de bovenste laag afhankelijkheden, en afnemers zijn er in hun inkoopvoorwaarden om gaan vragen. Wie dat bij de eerste uitvraag moet gaan samenstellen, is dagen kwijt; wie het automatisch heeft, stuurt een bestand mee en komt sterker voor de dag.
Wat wij doen is het genereren in uw bouwstraat hangen, in SPDX of CycloneDX, en er de twee toepassingen aan koppelen die hem nuttig maken: de licentiecontrole en de koppeling met kwetsbaarheidsbronnen. Dat sluit direct aan op kwetsbaarhedenbeheer en op de eisen uit de Cyber Resilience Act. Vaak doen we het als onderdeel van het inrichten van DevSecOps, omdat het dezelfde plek in de pijplijn raakt.
Waar u begint hangt af van of u iets moet aantonen, iets wilt weten, of allebei. In het eerste gesprek zeggen we welke variant het snelst iets oplevert.
Een lijst die iemand met de hand samenstelt, is bij de eerstvolgende oplevering al verouderd. Dat is geen kwestie van discipline maar van tempo. Wij hangen het genereren daarom aan de bouw zelf, met gereedschap dat bij uw talen en pakketbeheerders past, in SPDX of CycloneDX. De lijst ontstaat als bijproduct van iets wat toch al gebeurt, en hij kan niet verouderen zonder dat de bouw stilstaat. Van elke uitgebrachte versie blijft de bijbehorende lijst bewaard.
De meeste open-sourcelicenties leggen u weinig op, maar een handvol legt verplichtingen op die kunnen doorwerken naar de code die u eromheen bouwt. Dat wilt u weten voordat u bouwt, niet nadat een klant of een koper ernaar vraagt. Wij zetten een controle in de pijplijn die ongewenste licenties tegenhoudt, en leggen de bewuste uitzonderingen vast in een register met de reden erbij.
De lijst wordt pas nuttig als hij zichzelf vergelijkt met wat er bekend is. Wij koppelen hem aan bronnen als de nationale kwetsbaarhedendatabank en open bronnen, en zetten daar een weging op zodat u niet elke melding als even dringend behandelt. Met VEX legt u vervolgens vast dat een gemelde kwetsbaarheid u niet raakt omdat de kwetsbare functie bij u niet wordt aangeroepen — dat scheelt uw team en uw klanten veel vergeefse onrust.
Een lijst die zichzelf bijhoudt, plus de twee toepassingen die hem meer maken dan een bestand in een map.
Vier aanleidingen waarmee organisaties ons hiervoor benaderen. Meestal is er een directe aanleiding en blijkt de opbrengst breder.
U brengt software of een connected apparaat op de Europese markt en moet een machineleesbaar componentoverzicht kunnen overleggen. Dat is de directe aanleiding, maar de echte winst zit in de meldtermijn: zonder overzicht haalt u de 24 uur niet.
In standaardvoorwaarden voor ICT-inkoop staat inmiddels dat een leverancier inzicht geeft in gebruikte software en derden. Wie dat per uitvraag handmatig samenstelt, verliest tijd en geloofwaardigheid tegelijk.
Er wordt een kwetsbaarheid in een veelgebruikt component gemeld en er gaat een dag heen met uitzoeken of u het gebruikt. Dat herhaalt zich een paar keer per jaar, en elke keer met dezelfde onzekerheid aan het einde.
Bij een overname, een investeringsronde of een certificering wordt gevraagd wat er in de software zit en onder welke licenties. Een lijst die er al is, verkort dat onderzoek en voorkomt verrassingen op het slechtst denkbare moment.
Welke talen, pakketbeheerders en bouwstraten gebruikt u, hoeveel producten en versies staan er, en wat is de aanleiding: een wettelijke plicht, een uitvraag van een afnemer, of het inzicht zelf. Dat bepaalt welk formaat en welke diepte zinvol zijn.
We genereren een eerste volledige lijst en lopen die met u door. Bijna altijd blijkt hetzelfde: er zitten meer onderdelen in dan iedereen dacht, een handvol is jaren niet bijgewerkt, en er staat een licentie tussen waarvan niemand had gecontroleerd of die past. Dat is geen slecht nieuws maar de opbrengst.
Het genereren gaat mee in de pijplijn, met opslag per uitgebrachte versie. Tegelijk richten we het licentiebeleid in en zetten we de poort erop, eerst waarschuwend en pas blokkerend als de lijst schoon is. Blokkeren op een berg openstaande bevindingen leidt alleen maar tot uitzetten.
De lijst wordt doorlopend vergeleken met wat er bekend is, met een weging die meeneemt waar een component bij u zit. Waar een melding u niet raakt, leggen we dat vast als VEX-verklaring zodat dezelfde discussie niet elke maand terugkomt.
Een werksessie met uw team, afspraken over wie de uitzonderingen beoordeelt en met welke regelmaat, en een afspraak over wat er gebeurt als de poort iets tegenhoudt. Zonder die laatste afspraak wordt een poort binnen een maand omzeild.
Wat ontwikkelteams, productverantwoordelijken en security-officers ons vragen voordat ze hieraan beginnen.
Een kennismaking van een half uur, vrijblijvend. Vertel wat er draait en wat de aanleiding is, dan zeggen we hoe wij het zouden aanpakken en wat de eerste lijst waarschijnlijk laat zien — ook als we uiteindelijk niet samenwerken.
Appfront gebruikt cookies en vergelijkbare technieken voor een goede werking van de website, voor analyse en voor marketing. Je kiest zelf wat je toestaat. Lees meer in ons privacybeleid.
