Een PLC-advisory en tweehonderd machines

Een industriële machine is één product met digitale elementen, gebouwd uit firmware van anderen en software van de machinebouwer zelf. De Cyber Resilience Act vraagt dat die fabrikant kwetsbaarheden in dat geheel kan opvolgen.

Dit stuk volgt een fictieve productiemachine, en één advisory van Siemens, om te laten zien waar de administratie stopt en de engineering begint. De opbouw is die van machines die we bij machinebouwers tegenkomen. Er staat geen klant en geen resultaat in.

De machine is één product

In de kast zit een Siemens S7-1500, met firmware van Siemens en een PLC-programma van de machinebouwer. Daarnaast een HMI op embedded Linux met een eigen Qt-applicatie, een SEW-regelaar, een Basler-camera, een Ewon-gateway en een eigen .NET-backend. In het Linux-image zitten OpenSSL, Qt en de rest van de userspace. De SDK van Basler zit in de Qt-applicatie. De firmware van de camera zit daar niet in.

Er staan tweehonderd van die machines bij klanten. Ze delen een productnaam en niet een softwarestand. Sommige hebben een oudere PLC-firmware, een ander HMI-image, of een camera die bij een hardwarewijziging is vervangen. Een deel hangt via de gateway aan het internet. Een deel staat alleen op het productienetwerk van de klant en meldt niets terug.

Onderdeel	Wie het op de markt brengt	Wat jij bijhoudt
S7-1500	Siemens, voor de PLC	Ordernummer en firmwareversie
Frequentieregelaar	SEW	Type en firmwareversie
Camera	Basler, voor de camera	Firmware van de camera, apart van de SDK
Gateway	Ewon	Firmwareversie en hoe de verbinding openstaat
HMI-image, Qt-applicatie, .NET-backend	De machinebouwer	Releasetag, SBOM, getekende update
OpenSSL, Qt, Linux-libraries	Geïntegreerd door de machinebouwer	purl in de SBOM van het image

De fabrikant van de machine is de machinebouwer. Hij brengt het product met digitale elementen op de markt. Artikel 13 van Verordening (EU) 2024/2847 legt bij hem de risicobeoordeling, de essentiële cybersecurityeisen van bijlage I, en tijdens de ondersteuningsperiode de afhandeling van kwetsbaarheden, ook die in componenten. Siemens blijft fabrikant van de PLC, SEW van de regelaar, Basler van de camera en Ewon van de gateway, voor zover zij die componenten zelf als product op de markt brengen.

Artikel 13, lid 5, vraagt due diligence bij het integreren van componenten van derden, zodat die componenten de cybersecurity van de machine niet ondermijnen. Dat geldt ook voor open source die niet in het kader van een commerciële activiteit op de markt is gebracht. OpenSSL in het image is een component van de machinebouwer. De maintainer upstream meldt een CVE niet in zijn plaats.

Due diligence is een onderzoek dat past bij het risico van die component. Overweging 34 noemt wat daarbij hoort: nagaan of de componentfabrikant conformiteit aantoont, of er security-updates komen, of er gekende kwetsbaarheden zijn, en waar nodig zelf testen. Tot 11 december 2027 verwacht je geen CE-markering onder deze verordening op een PLC. De meldplicht van artikel 14 geldt al sinds 11 september 2026, ook voor producten die dan al bij klanten stonden. In die tussentijd steunt due diligence op het updateverleden, de advisories en de tests die je zelf draait.

De ondersteuningsperiode van de machine is minstens vijf jaar, tenzij het product aantoonbaar korter in gebruik is (artikel 13, lid 8). Bij het vastleggen ervan weeg je mee hoelang de leveranciers van kerncomponenten hun firmware nog bijwerken. Die datum wordt niet automatisch de jouwe. Een security-update die je tijdens de ondersteuning uitgeeft, blijft daarna minstens tien jaar beschikbaar, of tot het einde van de ondersteuningsperiode als die langer loopt.

Een backend die de machine nodig heeft om een functie te vervullen, hoort bij het product. De verordening noemt dat een oplossing voor gegevensverwerking op afstand. De .NET-dienst die recepten stuurt zonder welke de lijn niet produceert, valt dus onder dezelfde fabrikant. Een los dashboard dat de klant er zelf bij neemt, niet.

De versie is de sleutel

Een stuklijst met “S7-1500, HMI, SEW, Basler, Ewon” zegt niets op de dag dat een advisory binnenkomt. Wat je nodig hebt, is een graaf met versies.

Bovenaan staat het product, de machine. Daaronder de configuraties: de hardwarevarianten die je echt bouwt. Een lijn met camera en een lijn zonder zijn twee configuraties, ook al delen ze een brochure. Elke configuratie wijst naar componentversies. Voor de PLC is dat een firmwareversie, samen met het ordernummer. Voor de regelaar, de camera en de gateway hetzelfde. Voor het paneel is het een image-versie. Voor de Qt-applicatie en de .NET-backend een releasetag.

Een hiërarchie van project en subproject is zinvol waar een onderdeel een eigen release heeft. Het HMI-image wordt gebouwd, getest en getekend zonder dat de PLC-firmware mee verandert. Dat image is een subproject, met een eigen SBOM. De machine is het project dat de combinatie vastlegt: image 2.4.1 naast PLC-firmware 2.8.3. De eis blijft de issue-key die het team al gebruikt in Jira, Polarion of Codebeamer. De SBOM en de triage blijven bij de build. Een tweede eisenlijst in het subproject loopt de week erna uit de pas.

De relaties zijn klein in aantal. Een threat hoort bij een element op het diagram. Een eis verwijst naar dat threat en naar de clausule van bijlage I. Een test verwijst naar de eis, en het bewijs noemt de versie waarop hij gedraaid heeft. Een SBOM hoort bij één image-versie, met een purl per component, of een CPE wanneer een purl niet bestaat. Een CVE-triage verwijst naar die purl of naar een firmwareversie, en naar het threat. Bij een fix ook naar de eis. Ontbreekt een sleutel, dan faalt een script na de build de release candidate.

De installed base gebruikt dezelfde sleutels. Serienummer 1847 draait image 2.4.1 en PLC-firmware 2.8.3. De vraag “wie heeft 2.8.3” geeft serienummers terug. De SDK van Basler staat in de SBOM van het image. De firmware van de camera staat er niet in. Wie ze in één regel “Basler” samenvouwt, mengt twee advisories.

Eén grens kleurt het risico

Een risicoanalyse van de machine is een ander document dan het securityadvies van Siemens over de PLC. Artikel 13, leden 2 en 3, vragen een beoordeling van de cybersecurityrisico’s van het product, op basis van het bedoeld gebruik en het redelijkerwijs te verwachten gebruik, gedocumenteerd en bijgewerkt tijdens de ondersteuning. Siemens beantwoordt de risico’s van de PLC als product. Jij beantwoordt wat er gebeurt wanneer die PLC in deze machine zit, met deze gateway, dit netwerk en deze bedienaars.

De methode is een datastroom met trust boundaries, en daarna STRIDE op de elementen die een grens raken. Eén threat is één scenario met één uitkomst. Het diagram past op één pagina. Blokken zijn onderdelen die een eigen vertrouwensbeslissing nemen: de PLC, het HMI-image, de gateway, de backend, de monteur met een laptop.

Op deze machine is de Ewon de grens die de rest kleurt. Achter de gateway ligt een cel met de PLC, de regelaar en het paneel. Profinet of Modbus op dat segment gaan ervan uit dat de deelnemers elkaar vertrouwen. Een kwetsbaarheid in de PLC-firmware is in die cel bereikbaar voor wie al op het segment zit. Via de gateway is ze bereikbaar voor wie de serviceverbinding heeft. Dezelfde CVE wordt twee threats, omdat de aanvaller en de interface verschillen.

Een advisory op de PLC is een invoer. Of de machine kwetsbaar is, beslist het threat model van de machine.

Drie scenario’s staan op zo’n diagram bijna altijd als eerste.

De serviceverbinding. Iemand gebruikt een gestolen of een standaardaccount op de gateway en komt op het machine-netwerk. De asset is de besturing en de configuratie. De clausules zijn bescherming tegen onbevoegde toegang en een beperkt aanvalsoppervlak: bijlage I, deel I, punt 2, onder d en j. De eis noemt gedrag: op een productiemachine heeft de gateway geen standaardwachtwoord, de verbinding is gebonden aan een identiteit van de machinebouwer, en een test weigert een lege login.

De update. Een image of een PLC-programma dat zonder herkomstcontrole op de machine komt, vervangt de software die je beoordeeld hebt. Voor het HMI-image is de eis een getekende bundle, met rollback wanneer de nieuwe versie niet gezond wordt. Voor de PLC ligt het cryptografische pad bij Siemens. De procedure waarmee de machinebouwer een programma laadt, is de zijne, en krijgt een eigen eis.

Fysieke toegang. Een debug-interface op het paneel, of een open engineeringpoort op de PLC, geeft iemand in de kast een ander privilege dan de bedienaar. Op een productiemachine is dat voorzienbaar gebruik. De eis noemt de interface: op een productie-image geeft de debug-UART geen shell.

De leverancier hoort in dezelfde analyse. Een firmwaretak waarvan de security-updates stoppen, is een scenario met een datum. Je legt het vast als threat op dat element, met een herziening vóór die datum. De inschatting per threat is laag, midden of hoog, op kans en op impact op de essentiële functie en op het netwerk van de gebruiker. De beslissing is mitigeren, aanvaarden, of het deel dat alleen de componentfabrikant kan patchen bij hem leggen. Aanvaarden heeft een eigenaar en een herzieningsdatum. Het deel dat je bij de leverancier legt, dekt zijn publicatie. Jouw plicht om te weten welke machines die versie draaien, en om de klant te informeren, blijft staan.

Wat de leverancier aanlevert

Van Siemens, SEW, Basler en Ewon verzamel je hetzelfde, in de volgorde waarin je het kunt krijgen.

• De identiteit van de component: ordernummer, type, firmwaretak. Zonder dat kun je een advisory niet koppelen.
• Het securitykanaal: waar de advisories verschijnen, in welk formaat, en wie ze leest wanneer het formaat een pdf is.
• Het updatekanaal: hoe een firmware op de machine komt, hoelang die tak ondersteund blijft, en welke opvolger de leverancier noemt.
• De conformiteitsverklaring, zodra die onder de CRA bestaat.

Een SBOM van de PLC-firmware is welkom en zeldzaam. Bijlage I, deel II, punt 1, verplicht elke fabrikant een SBOM van zijn eigen product, minstens de top-level dependencies, in een gangbaar machineleesbaar formaat. Dat is de SBOM van de machinebouwer voor zijn image, en de SBOM van Siemens voor de PLC. De machinebouwer kan de tweede niet afdwingen, en de verordening vraagt niet dat hij de interne stuklijst van Siemens in zijn dossier plakt. Bijlage VII neemt een SBOM op in de technische documentatie waar een markttoezichtautoriteit er gemotiveerd om vraagt. Tot die vraag bewaar je de SBOM die de eigen build wel schrijft.

Blijft een leverancier stil, dan schrijf je dat op het component: geen advisoryfeed, geen einddatum van support, laatste firmware die je zelf hebt vastgesteld. Dat record is de due diligence. Een lege map “leverancier” is een gat in de risicobeoordeling.

Artikel 13, lid 6, legt nog een richting vast. Stel je een kwetsbaarheid vast in een ingebouwde component, dan meld je die aan wie de component maakt of onderhoudt, en je verhelpt ze in de machine volgens deel II van bijlage I. Heb je zelf een wijziging gemaakt om ze te dichten, dan deel je de relevante code of documentatie met die partij, waar dat past in een machineleesbaar formaat. De melding aan Siemens ontslaat je niet van de fix in je product. De fix in je product ontslaat Siemens niet van de zijne.

Einde ondersteuning van een firmwaretak maakt die grens zichtbaar. Siemens beslist over de PLC. Jij beslist over de machine: migreren naar een tak die nog updates krijgt, de interface sluiten zodat het threat niet meer bereikbaar is, of het risico aanvaarden tot de herzieningsdatum. De derde optie schort een melding onder artikel 14 niet op wanneer de kwetsbaarheid actief wordt uitgebuit.

Een advisory van Siemens

Siemens ProductCERT publiceert security advisories, voor een deel van het portfolio als CSAF. CSAF is een machineleesbaar advies: welk product, welke versies, welke CVE, welke remediatie. CVE is het nummer van de kwetsbaarheid. CPE is een naam voor een productversie waarmee een database probeert te matchen. VEX is een uitspraak over exploitability: dit product is getroffen, of dit product is het niet, met een reden.

SEW, Basler en Ewon publiceren die stroom niet op dezelfde manier. Voor hen koppelt een mens de pdf of de webpagina aan een type en een firmwareversie in de registry. Een job die alle leverancierssites zou “verwerken”, verzint treffers op pagina’s die geen advies zijn, en mist de pdf die wel een advies is.

De stappen voor één advisory op de S7-1500.

1. Binnenkomst. Een job leest de CSAF-feed en maakt een advisory-record met het SSA-nummer, de CVE’s en de genoemde firmwareversies. Het record is een kandidaat. Het is nog geen incident en nog geen melding.
2. Koppeling aan een versie. De advisory noemt een product en een versiebereik. Die worden gelegd naast de firmwareversies in de productstructuur. CPE-matching op industriële firmware faalt vaak: de naam in de catalogus wijkt af van de naam in de CSAF, of de tak heeft geen CPE. De primaire sleutel is de firmwareversie die je zelf hebt vastgelegd. Een VEX van de leverancier die “niet getroffen” zegt voor die exacte versie, neem je over, met de VEX als bron. Een ontbrekende VEX zegt niets.
3. Welke machines. De query is: welke serienummers deze firmwareversie hebben. Het antwoord heeft drie kolommen. Getroffen, met klant en serienummer. Een andere versie, buiten dit bereik. Onbekend: geen teruggelezen firmware, omdat de machine offline is of omdat niemand de versie bij ingebruikname heeft genoteerd.
4. Impact. De advisory zegt dat de firmware genoemd wordt. Een mens zegt of het threat op deze machine bereikbaar is. Drie uitkomsten, dezelfde als bij een CVE in het eigen image.
5. Maatregel. Bij een fix heropen je de eis die het threat dekt. De eis is dicht wanneer de getroffen machines die versie niet meer draaien, of wanneer een maatregel de interface sluit en een test dat op deze configuratie aantoont.
6. Test. Een nieuwe PLC-firmware test je op de combinatie die je uitlevert: die firmware, het PLC-programma, en het HMI-image dat ermee spreekt. Een configuratiewijziging op de gateway test je op het punt dat het threat noemt.
7. Klanten. Het advies noemt de CVE, de firmwareversie, de maatregel en de versie waarin ze zit. Het gaat naar de kolom getroffen. Machines met een andere versie krijgen die brief niet. Machines met status onbekend krijgen een vraag om de versie, of een bezoek.
8. Dossier. Het triagebestand, de eis, het testbewijs en de lijst serienummers met de versie na de actie. Wie een half jaar later vraagt wat er met die SSA gebeurd is, opent die keten.

Onbekend behandel je volgens het risico dat je al had. Of je leest de firmware uit vóór je ingrijpt, of je behandelt de machine als getroffen tot de versie vaststaat. Die keuze schrijf je op, met een eigenaar.

Triage	Wanneer	Wat het record noemt
Fix	Het scenario uit het threat model is bereikbaar	Het threat, en de eis die heropend wordt
Niet bereikbaar	De kwetsbare dienst staat uit, of de interface bestaat op deze machine niet	Het threat dat je nagelopen hebt, en de test die de dichte interface toont
Aanvaard	Je laat de versie bewust staan tot een datum	Eigenaar en herzieningsdatum. Artikel 14 blijft gelden bij actieve uitbuiting

Automatisch kan: de feed binnenhalen, het versiebereik naast de registry leggen, de serienummers opzoeken, en een release tegenhouden zolang een hoge of kritieke treffer geen triage heeft. Een mens blijft: de pdf van een leverancier zonder CSAF koppelen, bereikbaarheid beoordelen, een restrisico aanvaarden, en de tekst van het klantadvies tekenen.

Eigen software in dezelfde keten

De Qt-applicatie en de .NET-backend zijn het deel waarvan de SBOM uit de build komt. Voor het HMI-image schrijft de build een CycloneDX-bestand. De versie in de metadata is de image-versie. Elk package heeft een purl. Yocto kan daarnaast SPDX schrijven. Het bestand waar de gate op scant, is de CycloneDX van het rootfs. Hoe die SBOM zich verhoudt tot een CVE op het image, staat in wat je doet als er een CVE op je Yocto-image verschijnt.

In de pipeline, op dezelfde commit als de release:

• Statische analyse op de eigen C++ en C#, en een scan op secrets. Dat vangt fouten in code die je schrijft.
• Een afhankelijkhedenscan op de SBOM. Grype of OSV-Scanner levert kandidaten. De scan beslist niet of het lek in dit product bereikbaar is.
• De gate leest de eisen, de tests, het bewijs en de triage. Een eis zonder geslaagde test op deze versie faalt de candidate. Een hoge of kritieke CVE zonder triagebestand faalt haar ook.

Een testrapport dat alleen “security ok” zegt, heeft geen sleutel en telt niet mee voor die release. Updates van het HMI-image gaan getekend naar het toestel, met rollback. Otaryx houdt bij welk serienummer welke image-versie meldt. De PLC, de regelaar en de gateway zitten niet in die melding. Hun versie komt uit de inbedrijfstelling en uit een uitlezing.

Tweehonderd machines, een deel stil

De installed base is een tabel. Per serienummer: klant, configuratie, image-versie, PLC-firmware, regelaar, camera, gateway, en de datum waarop die stand is vastgesteld. Een leeg veld heeft de status onbekend, met een reden.

Een versie komt op drie manieren in die tabel. Bij de bouw, als baseline van het serienummer dat de fabriek verlaat. Bij een update die terugmeldt: een geslaagde rollout zet de nieuwe image-versie, een rollback zet de versie terug die het toestel effectief draait. De tabel volgt het toestel. En bij een uitlezing. PLC-firmware wijzigt een technieker ter plaatse, of via de engineeringsoftware, zonder dat het paneel dat merkt. Zonder een uitlezing na die interventie klopt de kolom niet meer. Offline machines krijgen die uitlezing bij onderhoud. Tot dan blijft de status onbekend, of de laatst geziene versie met een datum die oud genoeg is om wantrouwen te wekken.

Een updatecampagne is een query plus een actie. De query levert de serienummers met PLC-firmware in het bereik van de advisory, waarvan de triage op fix staat. De actie is de nieuwe firmware, getest op de combinatie met het HMI-image dat die machines draaien. Machines met een ander image test je niet mee omdat de PLC-firmware toevallig dezelfde is. De combinatie is het product. Na afloop klopt de tabel, of je ziet welke serienummers de actie niet gehaald hebben.

Melden of adviseren

Vier situaties lopen door elkaar in een inbox. De verordening scheidt ze.

Situatie	Wat de tekst vraagt
Gekende kwetsbaarheid	Bij het op de markt brengen geen gekende exploiteerbare kwetsbaarheden (bijlage I, deel I, punt 2, onder a). Tijdens de ondersteuning zonder onnodig uitstel verhelpen (deel II, punt 2). Een record in een database is nog geen exploiteerbare kwetsbaarheid in dit product. Daar dient de triage.
Actief uitgebuite kwetsbaarheid	Artikel 14, via het meldplatform van ENISA. Vroege waarschuwing binnen 24 uur nadat je het weet, notificatie binnen 72 uur, eindrapport uiterlijk 14 dagen nadat een corrigerende maatregel beschikbaar is. De klok start bij kennis van de uitbuiting.
Ernstig incident	Ook artikel 14: 24 uur, 72 uur, en een eindrapport binnen een maand na de notificatie. Een mislukte update of een bevinding uit een eigen test is dat incident niet, zolang de beveiliging van het product bij de gebruiker niet geraakt is.
Update beschikbaar	Deel II, punten 4 en 8: gebruikers informeren, en de update tijdig aanbieden, zonder bijkomende kost tenzij daar voor een maatproduct anders over is afgesproken. Dat advies gaat naar de kolom getroffen. Artikel 14 komt erbij zodra de kwetsbaarheid ook actief wordt uitgebuit, of het incident ernstig is.

Bij een melding onder artikel 14 informeer je ook de getroffen gebruikers, en waar dat kan over de maatregel die zij kunnen nemen. Een onderhoudscontract dat elke advisory deelt, is een afspraak met die klant. Hij vervangt de drempel van artikel 14 niet, en hij maakt een gewone CVE ook niet meldplichtig aan de autoriteit.

De meldroute oefen je. Eén keer per release-trein doorloop je de 24 uur en de 72 uur aan tafel, met het meldadres en de eigenaar uit de risicobeoordeling. Het bewijs van die oefening toont dat de route bestaat. Het is geen melding.

De meldplicht geldt sinds 11 september 2026, ook voor machines die al bij klanten staan. De overige fabrikantenplichten, waaronder het technisch dossier en de CE-markering onder deze verordening, gelden vanaf 11 december 2027. De tekst van de verordening en de toelichting van de Commissie blijven de bron. Dit stuk is geen juridisch advies.

Het dossier is een index

Bijlage VII beschrijft de technische documentatie. Daarin zitten de beschrijving van het product, het ontwerp en de kwetsbaarheidsafhandeling, de risicobeoordeling, de onderbouwing van de ondersteuningsperiode, de toegepaste normen of de oplossingen die je in hun plaats gebruikt, de testrapporten, de EU-verklaring, en waar een toezichthouder erom vraagt de SBOM.

Die stukken zijn de keten die de release al moest hebben: context, threat model, diagram, SBOM uit de build, bewijs per versie, het leveranciersrecord inclusief de gaten, en de stapel triages. Een script dat na een groene gate een index schrijft, met clausule, eis, test, bewijs en CVE-beslissing, is het dossier voor die versie. De fabrikant tekent de EU-verklaring. De index wijst naar de bestanden.

Geharmoniseerde normen onder de CRA staan nog niet voor elk onderdeel in het Publicatieblad. Tot dan beschrijft het dossier de oplossing die je hebt gekozen. IEC 62443 kan die beschrijving voeden waar een zone of een eis ermee samenvalt. De Machineverordening blijft ernaast gelden voor de veiligheid van de machine. NIS2 kan gelden voor de klant als exploitant. Elk van die teksten heeft zijn eigen verplichting. Artikel 13 blijft de tekst voor de fabrikant van deze machine.

Of de machine in bijlage III of IV valt, als belangrijk of kritiek product, bepaalt de conformiteitsprocedure. Voor een productiemachine als deze is dat per product na te gaan. Valt ze buiten die bijlagen, dan is de beoordeling de interne controle door de fabrikant. De gateway kan als eigen product van Ewon wel in een categorie vallen. Dat dossier is van Ewon.

Wat er automatisch kan

De keten die dit draagt, koppelt wat de build, de leverancier en de installed base al kunnen zeggen. Ze weigert een release waarin de koppeling ontbreekt. Hoe we die keten in de engineering zetten, staat op de pagina over onze CRA-aanpak. Hier de gegevens die ze voor deze machine moet kunnen joinen.

Zes gegevens volstaan.

• Product en configuratie. Welke componentversies een variant vastlegt.
• Leveranciersstroom. CSAF waar die bestaat, een handmatig gekoppeld advies waar ze niet bestaat, en het record “geen feed”.
• Kwetsbaarheid. CVE, versiebereik, triage, threat, eis.
• Eis. Het ID dat het team al gebruikt, gekoppeld aan de clausule.
• Bewijs. Testrapport op een benoemde versie.
• Serienummer. De laatst vastgestelde versies, of de status onbekend.

Bestaande tools vullen de randen. Syft of de Yocto-SBOM schrijft de inventaris van het eigen image. Grype, OSV-Scanner of cve-check in de build leveren kandidaten. SonarQube en een secrets-scan zitten in dezelfde pipeline. Jira houdt de eis. De CSAF-feed van Siemens ProductCERT levert advisories die een parser kan leggen. EMBA helpt wanneer je een firmware-image van een leverancier wél in handen hebt en wilt zien wat erin zit. Het vervangt zijn advisory niet.

De applicatie die we bij de fabrikant zetten, houdt die zes gegevens bij in zijn eigen omgeving. Een release is groen wanneer de sleutels kloppen. Een advisory wordt een lijst serienummers, plus de kolom onbekend. Het technisch dossier, de gebruikersinformatie en het concept van de EU-verklaring worden uit die gegevens gezet. De termijnen van artikel 14 staan op het product, zodat de 24 uur een timer is.

Een paar beslissingen blijven een handtekening. Of een CVE in deze machine bereikbaar is. Wat je doet wanneer de leverancier zwijgt over het einde van de support. De tekst van het klantadvies. Het aanvaarden van een restrisico. Een melding naar de autoriteit. De applicatie verzint geen SBOM voor een PLC die er geen publiceert, en ze markeert een offline machine niet als bijgewerkt.

Wat je aan het eind moet kunnen

Een advisory op de S7-1500 is een versiebereik. Dat bereik leg je naast de firmware die je per serienummer hebt vastgelegd. Daaruit komen drie kolommen: getroffen, een andere versie, onbekend. Onbekend is een bevinding. Een mens zegt daarna of het threat op deze machine bereikbaar is. Pas dan volgt een eis, een test op de combinatie die je uitlevert, en een advies aan de klanten in de kolom getroffen. Artikel 14 komt erbij wanneer de kwetsbaarheid actief wordt uitgebuit, of het incident ernstig is.

Siemens, SEW, Basler en Ewon blijven fabrikant van hun component. De machinebouwer blijft fabrikant van de machine. Zijn deel is de due diligence, de SBOM van het eigen image, de vastgelegde firmwareversie van de leverancier, en de vraag welke installatie die versie nog draait. Een PLC zonder gepubliceerde SBOM krijgt het record “geen SBOM”. Een offline machine blijft onbekend tot iemand de versie uitleest.

Kan je voor firmware 2.8.3 nog de serienummers, de triage en het bewijs leggen, dan is de volgende advisory een beoordeling. Kan je dat niet, dan begint elk record met dezelfde zoektocht: wat staat er bij die klant.

Bij Invisto zetten we die keten op in de engineering van de machinebouwer. Het threat model, de eisen in de tools die het team al heeft, de SBOM uit de build, en de koppeling naar de machines die de versie echt draaien.