Our security is only as good as that of every vendor, supplier and software component we let in — in plain language: four ways the trust gets abused, and the one control that limits each. Onze beveiliging is maar zo goed als die van elke leverancier, dienstverlener en softwarecomponent die we binnenlaten — in gewone taal: vier manieren waarop dat vertrouwen wordt misbruikt, en welke maatregel elk ervan beperkt.
We tell staff to install updates promptly, and rightly so. But an update is code we run with full privileges, on the vendor's word alone. When an attacker gets inside the vendor's build process, the poisoned version is signed with the vendor's real certificate, delivered through the real update channel and installed by our own systems on schedule. Nothing we own was attacked. We invited it in.
Business impact: one compromised vendor reaches every customer at once, so we become collateral in someone else's breach — yet the clean-up, the downtime and the notifications are ours. The tools most likely to be abused are the ones with the deepest access: monitoring, remote management, backup, security software.
We zeggen tegen medewerkers dat ze updates snel moeten installeren, en terecht. Maar een update is code die we met volledige rechten draaien, alleen op het woord van de leverancier. Als een aanvaller binnenkomt in het bouwproces van die leverancier, wordt de besmette versie ondertekend met het echte certificaat, geleverd via het echte updatekanaal en op schema geïnstalleerd door onze eigen systemen. Niets van ons is aangevallen. We hebben het zelf binnengelaten.
Bedrijfsimpact: één gecompromitteerde leverancier raakt al zijn klanten tegelijk, waardoor wij bijvangst worden in het datalek van een ander — maar het opruimen, de stilstand en de meldingen zijn voor ons. De software die het vaakst wordt misbruikt, is juist die met de diepste toegang: monitoring, beheer op afstand, back-up, beveiligingssoftware.
AI helps an attacker phish or socially engineer a way into a vendor's build process and then write malware that blends into the vendor's normal code style, but breaching that process at all is still the hard part.AI helpt een aanvaller een leverancier te phishen of te misleiden om in het bouwproces te komen en malware te schrijven die opgaat in de normale codestijl van de leverancier, maar dat proces binnendringen blijft het moeilijke deel.
AI-driven operations agents increasingly auto-approve and roll out vendor updates across the whole fleet to save time, removing the staged rollout that used to catch a poisoned update before it reached every server.AI-gestuurde operationele agents keuren updates van leveranciers steeds vaker automatisch goed en rollen ze in één keer over het hele park uit om tijd te besparen, waardoor de gefaseerde uitrol wegvalt die een besmette update eerder opving.
AI-based behaviour monitoring learns what a vendor's update normally does on our systems and flags it the moment it does something new, such as reaching an unfamiliar server. Staged rollout still limits the actual damage.AI-gebaseerde gedragsmonitoring leert wat een update van een leverancier normaal op onze systemen doet en signaleert het zodra er iets nieuws gebeurt, zoals een onbekende server benaderen. Gefaseerd uitrollen blijft de maatregel die de schade beperkt.
Our IT partner, our payroll provider, the firm that maintains the building systems — each holds a standing login into our environment. Often it is one shared account, used by a rotating team, valid around the clock, with more rights than the job needs. Attackers know this. Breaking into one supplier hands them the front-door keys of dozens of companies, and every login looks like routine maintenance.
Business impact: we cannot see how that supplier protects our key, and we rarely ask. When it is stolen, the intruder arrives with administrator rights, no alarm, and a perfect excuse in the logs. Every supplier login is an employee we never interviewed.
Onze IT-partner, onze salarisverwerker, het bedrijf dat de gebouwinstallaties onderhoudt — elk heeft een permanente inlog in onze omgeving. Vaak is het één gedeeld account, gebruikt door een wisselend team, dag en nacht geldig, met meer rechten dan het werk vereist. Aanvallers weten dat. Inbreken bij één leverancier levert ze de voordeursleutels van tientallen bedrijven op, en elke inlog lijkt op routineonderhoud.
Bedrijfsimpact: we kunnen niet zien hoe die leverancier onze sleutel beschermt, en we vragen het zelden. Wordt hij gestolen, dan komt de indringer binnen met beheerdersrechten, zonder alarm en met een perfect excuus in de logboeken. Elke leveranciersinlog is een medewerker die we nooit hebben gesproken.
Attackers use an AI-generated voice or video call impersonating a known supplier contact to talk a helpdesk into resetting the shared login, arriving afterwards with real administrator rights and a plausible story in the logs.Aanvallers gebruiken een AI-gegenereerde stem of video die een bekende leverancierscontact nabootst, om een helpdesk het gedeelde account te laten resetten, en komen daarna binnen met echte beheerdersrechten en een geloofwaardig verhaal in de logboeken.
Once a shared supplier account is stolen, AI helps the attacker act like routine maintenance across dozens of customers at once, writing plausible change tickets and timing actions to match the supplier's normal working pattern.Is een gedeeld leveranciersaccount eenmaal gestolen, dan helpt AI de aanvaller om zich bij tientallen klanten tegelijk als routineonderhoud voor te doen, met geloofwaardige wijzigingstickets en timing die past bij het normale werkpatroon van de leverancier.
AI can spot a supplier login that suddenly acts outside its usual hours, scope or pattern, even when the credentials themselves are valid. Named accounts, MFA and access that expires remain the actual fix behind the alert.AI kan een leveranciersinlog signaleren die plotseling buiten de gebruikelijke tijden, reikwijdte of patroon handelt, ook als de inloggegevens zelf geldig zijn. Persoonlijke accounts, MFA en verlopende toegang blijven de echte oplossing.
Modern software is assembled, not written. Our customer portal, our app, our internal tools: each is a thin layer of our own code on top of hundreds of open-source components, written and maintained by people we have never met. When one of those maintainers is tricked, bought or simply hands the project to a stranger, the next version can carry code that steals whatever our application touches. Our developers pull it in with a routine build. In September 2025 the self-spreading Shai-Hulud worm used stolen maintainer tokens to poison over 500 npm packages (CISA).
Business impact: the malicious code runs inside our product, under our name, with access to our customers' data. Contractually and legally it is our breach. And if we cannot list which components are inside our software, we cannot answer the first question a regulator or customer will ask: “are you affected?”
Moderne software wordt samengesteld, niet geschreven. Ons klantportaal, onze app, onze interne tools: elk is een dun laagje eigen code bovenop honderden open-sourcecomponenten, geschreven en onderhouden door mensen die we nooit hebben ontmoet. Wordt zo'n beheerder misleid, omgekocht of geeft hij het project simpelweg aan een vreemde, dan kan de volgende versie code bevatten die steelt wat onze applicatie aanraakt. Onze ontwikkelaars halen die binnen met een routinematige build. In september 2025 besmette de zichzelf verspreidende worm Shai-Hulud met gestolen beheerderstokens ruim 500 npm-pakketten (CISA).
Bedrijfsimpact: de kwaadaardige code draait in ons product, onder onze naam, met toegang tot de gegevens van onze klanten. Contractueel en juridisch is het ons datalek. En als we niet kunnen opsommen welke componenten in onze software zitten, kunnen we de eerste vraag van een toezichthouder of klant niet beantwoorden: “zijn jullie getroffen?”
AI coding assistants sometimes suggest a package name that does not exist, and attackers register that exact name with malicious code inside it, knowing developers will install whatever the assistant confidently recommended.AI-codeerassistenten stellen soms een pakketnaam voor die niet bestaat, en aanvallers registreren precies die naam met kwaadaardige code erin, wetend dat ontwikkelaars installeren wat de assistent zelfverzekerd aanraadde.
Developers now add dependencies an AI assistant suggested mid-task, often without checking who maintains them or how recently, so unvetted code enters the build faster than any review process was ever built to handle.Ontwikkelaars voegen nu afhankelijkheden toe die een AI-assistent tijdens het werk voorstelde, vaak zonder te checken wie ze onderhoudt of hoe recent, waardoor ongecontroleerde code sneller de build binnenkomt dan enig reviewproces aankan.
AI tools can cross-check our component inventory (SBOM) against new vulnerability and takeover reports the moment they are published, alerting the same day a maintainer account changes hands, instead of whenever someone happens to notice.AI-tools kunnen onze componenteninventaris (SBOM) direct vergelijken met nieuwe kwetsbaarheids- en overnamemeldingen zodra die worden gepubliceerd, en dezelfde dag waarschuwen dat een beheerdersaccount van eigenaar wisselt, in plaats van wanneer iemand het toevallig opmerkt.
Our HR records live with a payroll service. Our customer list lives in a marketing tool. Our contracts live in an e-signing platform. Each of those vendors runs on other vendors in turn. When any of them is breached, our data is exposed without a single packet touching our network — and we may only learn about it from the news, or from a customer.
Business impact: under GDPR we remain the controller. The 72-hour notification clock, the regulator and the customer communication are ours, regardless of whose servers leaked. The practical questions are simple and usually unanswered: which vendors hold what data, how fast are they obliged to tell us, and how do we get our data back if we walk away?
Onze personeelsdossiers staan bij een salarisdienst. Onze klantenlijst staat in een marketingtool. Onze contracten staan op een platform voor digitaal ondertekenen. Elk van die leveranciers draait op zijn beurt weer op andere leveranciers. Wordt een van hen gehackt, dan liggen onze gegevens op straat zonder dat één pakketje ons netwerk heeft aangeraakt — en soms horen we het pas via het nieuws, of van een klant.
Bedrijfsimpact: onder de AVG blijven wij de verwerkingsverantwoordelijke. De 72-uursmelding, de toezichthouder en de communicatie naar klanten zijn voor ons, ongeacht wiens servers lekten. De praktische vragen zijn simpel en meestal onbeantwoord: welke leveranciers hebben welke gegevens, hoe snel moeten ze ons informeren, en hoe krijgen we onze gegevens terug als we weglopen?
Once a vendor holding our data is breached, AI helps an attacker sift through the stolen records at scale, matching names, roles and contract details to build convincing follow-on attacks against our own staff and customers.Is een leverancier met onze data eenmaal gehackt, dan helpt AI een aanvaller om de gestolen gegevens op schaal te doorzoeken, en namen, functies en contractdetails te koppelen voor overtuigende vervolgaanvallen op onze eigen medewerkers en klanten.
A vendor's own AI features, such as a support chatbot trained on customer data, can be tricked or misconfigured into answering with information from a different customer's account, a new kind of exposure we cannot audit.De eigen AI-functies van een leverancier, zoals een supportchatbot getraind op klantdata, kunnen door misleiding of misconfiguratie antwoorden met informatie uit het account van een andere klant, een nieuwe vorm van blootstelling die wij niet kunnen controleren.
AI can help build and keep current the map of which vendor holds what data, faster than a manual survey. The notification and exit clauses that decide how fast we hear about a breach still need negotiating up front.AI kan helpen de kaart van welke leverancier welke data heeft actueel te houden, sneller dan een handmatige inventarisatie. De meld- en exitclausules die bepalen hoe snel wij van een lek horen, moeten nog steeds vooraf worden afgesproken.
| Control | Limits | In one line |
|---|---|---|
| Supplier inventory | All four | One list of every supplier that holds our data or can reach our systems, ranked by what they could break. |
| Contract clauses | All four | Security requirements, breach notification within a fixed number of hours, and the right to audit. Agreed before signing, not after the incident. |
| Third-party access | Access (02) | A named account per person, MFA on every login, access that opens on request and closes by itself. |
| Staged updates | Updates (01) | Updates land on a small test group first. We suggest critical systems never take a new version on day one. |
| Vendor behaviour | Updates (01), Access (02) | Supplier tools and logins are watched like any user, and cut off when they act unusually. |
| SBOM + provenance | Code (03) | A bill of materials (SBOM) with an alert the day a component turns bad, VEX notes on which flaws affect us, and signed builds with SLSA provenance. |
| Dependency hygiene | Code (03) | Pin versions, wait a few days before adopting a new release, and publish our own packages with MFA or trusted publishing. |
| Exit & notification | SaaS (04) | How we get our data back, how fast they tell us, who pays. Settled while we can still walk away. |
| Concentration | All four | Know which single supplier's outage stops the business, and decide consciously whether that is acceptable. |
| Maatregel | Beperkt | In één zin |
|---|---|---|
| Leveranciersinventaris | Alle vier | Eén lijst van elke leverancier die onze gegevens heeft of bij onze systemen kan, gerangschikt naar wat ze kunnen breken. |
| Contractclausules | Alle vier | Beveiligingseisen, melding van een lek binnen een vast aantal uren, en het recht om te auditen. Afgesproken vóór het tekenen, niet na het incident. |
| Toegang voor derden | Toegang (02) | Een persoonlijk account per persoon, MFA op elke inlog, toegang die op aanvraag opent en vanzelf weer sluit. |
| Gefaseerd updaten | Updates (01) | Updates landen eerst bij een kleine testgroep. Wij raden aan kritieke systemen nooit op dag één een nieuwe versie te geven. |
| Gedrag van leveranciers | Updates (01), Toegang (02) | Leverancierssoftware en -inlogs worden bewaakt als elke gebruiker, en afgesloten bij ongewoon gedrag. |
| SBOM + herkomst | Code (03) | Een stuklijst (SBOM) met een alarm op de dag dat een component besmet raakt, VEX-verklaringen over welke kwetsbaarheden ons raken, en ondertekende builds met SLSA-herkomstgegevens. |
| Afhankelijkheden | Code (03) | Zet versies vast, wacht een paar dagen met een nieuwe release, en publiceer eigen pakketten met MFA of trusted publishing. |
| Exit & melding | SaaS (04) | Hoe we onze gegevens terugkrijgen, hoe snel ze ons informeren, wie betaalt. Geregeld zolang we nog kunnen weglopen. |
| Concentratie | Alle vier | Weet van welke enkele leverancier een storing het bedrijf stillegt, en beslis bewust of dat acceptabel is. |
We depend on dozens of vendors, hundreds of software components and several standing third-party logins. One of them will be breached; the only question is which.We zijn afhankelijk van tientallen leveranciers, honderden softwarecomponenten en meerdere permanente inlogs van derden. Eén ervan wordt gehackt; de vraag is alleen welke.
Administrator-level intrusion, a data breach we may have to report, and a clean-up we pay for even though the failure was someone else's.Inbraak met beheerdersrechten, een datalek dat wij mogelijk moeten melden, en een opruimactie die wij betalen terwijl de fout bij een ander lag.
Suppliers will still be breached. Tiering, expiring access, staged updates and an SBOM shrink what any single breach can reach and how long it stays unseen.Leveranciers worden nog steeds gehackt. Indeling, verlopende toegang, gefaseerd updaten en een SBOM beperken wat één lek kan bereiken en hoelang het onzichtbaar blijft.
Whoever owns procurement and contracts owns this risk. The CISO advises; the supplier list and its access rights belong to the business.Wie verantwoordelijk is voor inkoop en contracten, is eigenaar van dit risico. De CISO adviseert; de leverancierslijst en de bijbehorende toegang horen bij de business.
Number of suppliers with standing access to our systems · % of those logins with a named account and MFA · % of our applications with a current component inventory · number of critical suppliers without breach-notification and exit clauses.Aantal leveranciers met permanente toegang tot onze systemen · % van die inlogs met een persoonlijk account en MFA · % van onze applicaties met een actuele componenteninventaris · aantal kritieke leveranciers zonder meld- en exitclausules.
“A compromised supplier, software update, open-source component or SaaS provider gives an attacker access to our systems or data without any direct attack on us.”“Een gecompromitteerde leverancier, software-update, open-sourcecomponent of clouddienst geeft een aanvaller toegang tot onze systemen of gegevens zonder dat wij zelf direct worden aangevallen.”
| Framework | What it requires of you | When a supplier hands you their report | When this incident happens |
|---|---|---|---|
| NIS2 | Supply chain security is a named risk-management measure: assess the security of direct suppliers and providers, and reflect it in contracts. NIS2 requires management to approve the measures, and members can be held liable. | There is no NIS2 certificate. Ask how the supplier covers the same measures, and put their duty to warn you of incidents in the contract. | Can count as a significant incident if it meets the thresholds: early warning within 24 hours of becoming aware, incident notification within 72 hours, final report within one month. A supplier's breach can trigger your notification. |
| DORA | For financial entities: a register of information on all ICT third-party arrangements, pre-contract due diligence, prescribed contract clauses, concentration-risk assessment and an exit strategy for critical providers. | A report is input, not a substitute. Critical ICT providers still need the DORA contract clauses, including audit and access rights and termination terms. | Can count as a major ICT-related incident: initial notification within 4 hours of classifying it as major (at most 24 hours after becoming aware), intermediate report within 72 hours of the initial notification, final report within one month. The contract decides how fast the provider tells you. |
| SOC 2 | If you issue one: vendor management is tested as part of the control environment. Auditors ask how you select, monitor and review subservice organisations. | Check the period, the systems in scope and the exceptions. Read the subservice organisations section: that is their supply chain, and the carve-outs are your blind spots. | The incident appears as a deviation in the next report, auditors test how you assessed the supplier, and customers ask what you knew and when. |
| ISAE 3402 | Assurance over outsourced processes relevant to financial reporting. The service organisation defines the scope, so vendor and software security may be outside it. | Read the control objectives first. If the supplier's own subcontractors are carved out, the report says nothing about them. | ISAE 3402 creates no duty to notify user auditors. Expect a deviation in the next report, and ask for interim disclosure in the contract. |
| CRA | If you sell software or connected products: from 11 September 2026, manufacturers report actively exploited vulnerabilities and severe incidents to ENISA. From 11 December 2027: security by design, vulnerability handling, an SBOM and a defined support period. | Ask vendors for their CRA conformity and the end date of their support period. | If the flaw is in a product you make: early warning within 24 hours, notification within 72 hours, via the ENISA Single Reporting Platform. |
| Kader | Wat het van u vraagt | Als een leverancier u zijn rapport geeft | Als dit incident u treft |
|---|---|---|---|
| NIS2 | Beveiliging van de toeleveringsketen is een benoemde risicobeheersmaatregel: beoordeel de beveiliging van directe leveranciers en dienstverleners en leg dat vast in contracten. NIS2 vereist dat het bestuur de maatregelen goedkeurt; bestuurders kunnen aansprakelijk worden gesteld. | Er bestaat geen NIS2-certificaat. Vraag hoe de leverancier dezelfde maatregelen invult, en leg zijn plicht om u bij incidenten te waarschuwen vast in het contract. | Kan als significant incident gelden als het de drempels haalt: vroegtijdige waarschuwing binnen 24 uur nadat u ervan weet, incidentmelding binnen 72 uur, eindrapport binnen een maand. Een lek bij uw leverancier kan uw meldplicht in gang zetten. |
| DORA | Voor financiële instellingen: een informatieregister van alle ICT-uitbestedingen, due diligence vóór het contract, voorgeschreven contractbepalingen, beoordeling van concentratierisico en een exitstrategie voor kritieke leveranciers. | Een rapport is input, geen vervanging. Kritieke ICT-leveranciers vereisen nog steeds de DORA-contractbepalingen, inclusief audit- en toegangsrechten en opzegtermijnen. | Kan als ernstig ICT-gerelateerd incident gelden: eerste melding binnen 4 uur na classificatie als ernstig (uiterlijk 24 uur nadat u ervan weet), tussentijds rapport binnen 72 uur na de eerste melding, eindrapport binnen een maand. Het contract bepaalt hoe snel de leverancier u informeert. |
| SOC 2 | Als u er zelf een afgeeft: leveranciersbeheer wordt getest als onderdeel van de beheersomgeving. Auditors vragen hoe u subserviceorganisaties selecteert, bewaakt en beoordeelt. | Controleer de periode, de systemen binnen scope en de afwijkingen. Lees de paragraaf over subserviceorganisaties: dat is hún toeleveringsketen, en de uitsluitingen zijn uw blinde vlekken. | Het incident verschijnt als afwijking in het volgende rapport, auditors testen hoe u de leverancier heeft beoordeeld, en klanten vragen wat u wist en wanneer. |
| ISAE 3402 | Zekerheid over uitbestede processen die relevant zijn voor de financiële verslaggeving. De serviceorganisatie bepaalt de scope, dus leveranciers- en softwarebeveiliging kunnen erbuiten vallen. | Lees eerst de beheersdoelstellingen. Zijn de eigen onderaannemers van de leverancier uitgesloten, dan zegt het rapport niets over hen. | ISAE 3402 schept geen plicht om de auditors van klanten te informeren. Verwacht een afwijking in het volgende rapport, en vraag in het contract om tussentijdse melding. |
| CRA | Als u software of verbonden producten verkoopt: vanaf 11 september 2026 melden fabrikanten actief misbruikte kwetsbaarheden en ernstige incidenten bij ENISA. Vanaf 11 december 2027: security by design, kwetsbaarhedenbeheer, een SBOM en een vastgelegde ondersteuningsperiode. | Vraag leveranciers naar hun CRA-conformiteit en de einddatum van hun ondersteuningsperiode. | Zit de kwetsbaarheid in een product dat u maakt: vroegtijdige waarschuwing binnen 24 uur, melding binnen 72 uur, via het Single Reporting Platform van ENISA. |
Checked against: CRA (EU) 2024/2847 and EC CRA reporting (2026), NIS2 Art. 21 and 23, DORA, CISA on Shai-Hulud (Sep 2025), SLSA v1.2, CISA VEX (Apr 2023), npm trusted publishing · September 2026.
Gecontroleerd tegen: CRA (EU) 2024/2847 en EC over CRA-meldingen (2026), NIS2 art. 21 en 23, DORA, CISA over Shai-Hulud (sep 2025), SLSA v1.2, CISA VEX (apr 2023), npm trusted publishing · september 2026.