Risicobeheer voor third-party scripts is het operating-model om extern JavaScript als een bestuurd programma te draaien in plaats van een open deur. Het framework heeft zes bewegende onderdelen: inventaris, ownership, data-toegangsclassificatie, change-monitoring, review-cadans en bewijs. Krijg die zes samen aan het werk en je kunt de enige vragen beantwoorden die ertoe doen bij een incident of audit: wat draait, wie owned het, wat kan het aanraken, en wat wijzigde.
De meeste teams hebben tactieken zonder programma. Ze draaien een Content Security Policy, pinnen misschien een paar Subresource Integrity-hashes, en bewaren een vendor-spreadsheet die verouderde vanaf de dag dat een tag-manager een fourth-party-script toevoegde dat niemand goedkeurde. Dit bericht behandelt het governance-model waar die tactieken in pluggen, de rollen die het draaien, en het browser-side bewijs dat cside produceert om elk onderdeel reëel te maken.
Het zesdelige operating-model
Elk onderdeel van het framework beantwoordt een vraag die een aanvaller of beoordelaar zal stellen. Als een kolom leeg is, is dat je blootstelling.
| Pilaar | De vraag die het beantwoordt | Bewijs om te bewaren |
|---|---|---|
| Inventaris | Wat executeert daadwerkelijk in de browser? | Script-URL, source/fourth-party, first-seen-datum, versie |
| Ownership | Wie is accountable voor dit script? | Genoemde owner, business-justificatie, goedkeuringsrecord |
| Data-toegangstier | Wat kan dit script lezen of sturen? | Formulierveld-, cookie-, token-toegang; tier-label |
| Change-monitoring | Wat wijzigde, en was het geautoriseerd? | Diffs, nieuwe bestemmingen, alert + disposition |
| Review-cadans | Wanneer is dit voor het laatst her-geattesteerd? | Laatste review-datum, reviewer, next-due-datum |
| Bewijs | Kunnen we al het bovenstaande bewijzen? | Immutable timeline per PCI 6.4.3 / 11.6.1 |
Bouw de inventaris vanuit de browser, niet vanuit een spreadsheet
Een vendor-lijst is geen inventaris. Eén goedgekeurde vendor kan chained scripts laden die je nooit reviewde, en tag-managers injecteren code op runtime die geen server-side scan ziet. Je inventaris moet komen van wat daadwerkelijk executeert in de browsers van echte gebruikers, inclusief de fourth-parties die je third-parties meebrengen.
cside bouwt deze inventaris vanuit live browser-observatie: elk script, zijn echte source, wanneer het voor het eerst verscheen, en wat het doet zodra het draait. Dat is de ruggengraat waaraan de andere vijf pilaren hangen, want je kunt geen owner of datatier toewijzen aan een script dat je niet ziet.
Ken één owner per script toe, en maak rollen expliciet met RACI
Een inventaris zonder ownership is een lijst wezen. Elk script heeft een genoemde mens nodig die zijn business-justificatie kan uitspreken en zijn wijzigingen kan goedkeuren. Maar "owner" alleen ververvaagt snel bij een incident, dus verspreid het werk over rollen met een simpele RACI: wie is Responsible, Accountable, Consulted en Informed voor elk onderdeel van het programma.
| Activiteit | Script-owner | Engineering | Security | Privacy | Compliance |
|---|---|---|---|---|---|
| De live-inventaris onderhouden | C | R/A | I | I | I |
| Een nieuw script / justificatie goedkeuren | A | R | C | C | I |
| Data-toegangstier classificeren | C | I | C | A/R | I |
| Een change-alert onderzoeken | C | C | A/R | C | I |
| Een blokkade autoriseren | A | R | C | I | I |
| Audit-bewijs produceren | C | I | C | C | A/R |
Eén regel houdt het eerlijk: elke rij heeft precies één Accountable. Wanneer PCI DSS 6.4.3 je vraagt elk betaalpagina-script te rechtvaardigen en autoriseren, moet "wie goedkeurde dit" resolven naar een naam, niet een schouderophalen. De RACI is wat de inventaris van een lijst in een programma verandert dat mensen draaien.
Classificeer data-toegang in tiers
Niet elk script verdient hetzelfde vertrouwen. Classificeer op wat het in de browser kan bereiken, en bestuur elke tier anders. Een marketing-pixel die een checkout-formulier leest is precies het patroon achter Magecart- en e-skimming-diefstal, dus de classificatie moet gedragsmatig zijn, niet alleen op vendor-reputatie.
| Tier | Data die het script kan aanraken | Governance |
|---|---|---|
| Tier 1, sensitive | Betaalvelden, credentials, sessie-tokens | Review elke wijziging; default-deny riskante acties |
| Tier 2, personal | Formulier-inputs, identificeerbare cookies | Access goedkeuren, bestemmingen monitoren |
| Tier 3, low | Geen PII, alleen statische assets | Lichte periodieke review |
cside laat je gedragsbeleid per script instellen: een chat-widget kan renderen zonder het betaalveld ernaast te lezen, en een analytics-tag kan draaien terwijl hij wordt geblokkeerd van cookies of formulier-inputs. Dat verandert het tier-label in een afgedwongen regel in plaats van een notitie in een spreadsheet.
Monitor change, want goedkeuring is een moment en scripts zijn continu
De gevaarlijke kloof in de meeste programma's is tijd. Een script wordt één keer goedgekeurd, en wijzigt vervolgens maanden in stilte. Statische checks missen dit: een CSP bestuurt alleen load-origin, en een SRI-hash beschermt een statisch bestand maar breekt op de dynamische scripts waar de meeste moderne sites van afhankelijk zijn, dus teams laten hem vallen. Goedkeuring is een snapshot; risico is een film.
Change-monitoring sluit de kloof door runtime-gedrag te bewaken, niet alleen het source-domein. Wanneer een Tier 1-script begint een veld te lezen dat het nooit aanraakte, naar een nieuwe bestemming beacont, of zijn payload verschuift, is dat het signaal. cside legt het runtime-gedrag, payload-wijzigingen en nieuwe netwerkbestemmingen vast, en alerteert op ongeautoriseerde wijziging. Diezelfde capture is wat PCI DSS 11.6.1 verwacht: detecteer en alert op ongeautoriseerde wijziging van betaalpagina-scripts en HTTP-headers, minstens wekelijks of volgens je risicoanalyse onder requirement 12.3.1.
Stel een review-cadans in gekoppeld aan de datatier
Cadans voorkomt dat het programma wegrot tussen incidenten. Stuur het af op de tier, niet alleen op de kalender:
- Tier 1-scripts: her-attesteer bij elke wijziging en minstens kwartaallijks.
- Tier 2-scripts: review kwartaallijks en bij elke nieuwe bestemming.
- Tier 3-scripts: review jaarlijks, of wanneer ze een tier opschuiven.
- Elk nieuw of niet-goedgekeurd script: review bij detectie, niet wachten.
Een review die geen record oplevert is een gesprek, geen control. Elke passage moet een gedateerde notitie achterlaten: wie reviewde, wat gecheckt werd, en wat de volgende vervaldatum is.
Score je programma tegen een maturiteitsmodel
Een framework helpt alleen als je weet waar je erop staat. Gebruik deze vijf niveaus om het programma eerlijk te scoren, per oppervlak. Je betaalpagina's kunnen op een ander niveau staan dan je marketing-site, en de kloof daartussen is meestal waar het risico leeft.
| Niveau | Staat | Hoe het eruitziet | Audit-postuur |
|---|---|---|---|
| 1, Ad hoc | Geen inventaris | Scripts toegevoegd door wie dan ook, geen lijst, geen owners | Faalt 6.4.3 op dag één |
| 2, Gedocumenteerd | Statische spreadsheet | Vendor-lijst bestaat maar veroudert; geen fourth-parties | Inventaris bestaat, integriteit onbewezen |
| 3, Owned | RACI toegewezen | Genoemde owners, justificaties, handmatige periodieke review | Kan autorisatie tonen, zwak op change-detectie |
| 4, Monitored | Runtime-change-alerts | Gedragsmonitoring, tiered-beleid, alerts gedispositioneerd | Voldoet aan de intentie van 11.6.1 |
| 5, Continuous | Bewijs on-demand | Live-inventaris, afgedwongen tiers, immutable timeline geëxporteerd op verzoek | Audit-ready zonder brand-oefening |
De meeste teams ontdekken dat ze op Niveau 2 staan op het oppervlak dat er het meest toe doet. De sprong die telt is Niveau 3 naar Niveau 4: de overstap van "we hebben een lijst en owners" naar "we worden gealert zodra een Tier 1-script gedrag wijzigt." Dat is de lijn tussen een binder en een control, en het is waar browserlaag-monitoring zijn plaats verdient.
Bewaar bewijs dat een auditor accepteert
Het framework telt alleen als je kunt bewijzen dat het draaide. Voor PCI DSS 4.0.1 betekent dat een inventaris met gedocumenteerde justificatie voor elk betaalpagina-script (6.4.3) en een tamper-alert-spoor voor ongeautoriseerde wijzigingen aan scripts en HTTP-headers (11.6.1), beide verplicht sinds 2025-03-31. Een betaalprocessor zoals Stripe of Adyen maakt je eigen pagina niet compliant. De scripts op je checkout blijven jouw verantwoordelijkheid, en een third-party-iframe verplaatst die lijn niet.
cside bewaart dit als een immutable, queryable timeline: wat elk script is, wie het goedkeurde, de data die het benaderde, elke wijziging, elke alert, en hoe elke werd gedispositioneerd. Wanneer de beoordelaar vraagt "laat zien", exporteer je een record in plaats van er één uit het geheugen te reconstrueren. De browserlaag telt hier ook: cside legt apparaat- en echt-IP-signalen vast, AI-agent- en bot-gedrag, en VPN/proxy-patronen, dus het bewijs reflecteert wat er echt draaide voor echte gebruikers in plaats van wat een periodieke crawler toevallig zag. Signalen zijn beschikbaar via API, zodat de inventaris en alerts je eigen GRC- of SIEM-tooling kunnen voeden.
Waarom een programma een checklist verslaat in 2026
Automatiseringsdruk stijgt aan de aanvallerskant. cside's eigen onderzoek vond dat playwright-stealth-installaties ruwweg tienvoudig klommen door 2025, wat meer geautomatiseerde, evasieve activiteit betekent die client-side-oppervlakken test (cside research report). Crawlers die periodiek scanen zijn precies wat evasieve automatisering ontwijken moet: schone code serveren aan de scanner, kwaadaardige payload aan de echte sessie. Een statische jaarlijkse spreadsheet kan dat niet bijhouden; een continu operating-model met owners, tiers en change-alerts voor echte gebruikers kan dat wel. Het framework is wat een stapel scripts verandert in iets dat je bestuurt.
Verder lezen op cside
- Best practices voor het beveiligen van third-party scripts
- Top-platforms voor third-party-script-monitoring
- Hoe voldoe je aan PCI 6.4.3 en 11.6.1
- Wat is client-side security?
- cside PCI Shield
- NIS2-richtlijn websiteconformiteit en verplichtingen voor third-party scripts
Met ingang van 2026-06-18, behandel dit als operationele richtlijn, niet als juridisch advies. Bevestig de exacte control-tekst met je QSA, juridisch adviseur of risk-owner.
