La gestión de riesgo de scripts de terceros es el modelo operativo para ejecutar JavaScript externo como un programa gobernado en vez de una puerta abierta. El marco tiene seis piezas: inventario, ownership, clasificación de acceso a datos, monitorización de cambios, cadencia de revisión y evidencia. Haz que las seis trabajen juntas y podrás responder las únicas preguntas que importan en un incidente o auditoría: qué corre, quién lo posee, qué puede tocar y qué cambió.
La mayoría de equipos tiene tácticas sin programa. Ejecutan una Content Security Policy, quizá fijan unos hashes Subresource Integrity y conservan un spreadsheet de vendors que quedó obsoleto el día que un tag manager añadió un script de cuarta parte que nadie aprobó. Este artículo cubre el modelo de gobernanza donde encajan esas tácticas, los roles que lo ejecutan y la evidencia del lado del navegador que cside produce para hacer real cada parte.
El modelo operativo de seis partes
Cada parte del marco responde una pregunta que hará un atacante o un evaluador. Si alguna columna está vacía, ahí está tu exposición.
| Pilar | La pregunta que responde | Evidencia que conservar |
|---|---|---|
| Inventario | ¿Qué se ejecuta realmente en el navegador? | URL de script, fuente/cuarta parte, fecha first-seen, versión |
| Ownership | ¿Quién es accountable por este script? | Owner nombrado, justificación de negocio, registro de aprobación |
| Tier de acceso a datos | ¿Qué puede leer o enviar este script? | Acceso a campos, cookies, tokens; etiqueta de tier |
| Monitorización de cambios | ¿Qué cambió y estaba autorizado? | Diffs, nuevos destinos, alerta + resolución |
| Cadencia de revisión | ¿Cuándo se reatestó por última vez? | Fecha de última revisión, revisor, próxima fecha |
| Evidencia | ¿Podemos probar todo lo anterior? | Timeline inmutable por PCI 6.4.3 / 11.6.1 |
Construye el inventario desde el navegador, no desde un spreadsheet
Una lista de vendors no es un inventario. Un vendor aprobado puede cargar scripts encadenados que nunca revisaste, y los tag managers inyectan código en runtime que ningún escaneo del servidor ve. Tu inventario debe venir de lo que realmente se ejecuta en navegadores de usuarios reales, incluidas las cuartas partes que tus terceros traen.
cside construye este inventario desde observación en vivo del navegador: cada script, su fuente real, cuándo apareció por primera vez y qué hace cuando corre. Ese es el eje del que cuelgan los otros cinco pilares, porque no puedes asignar owner ni tier de datos a un script que no ves.
Asigna un owner por script y explicita roles con RACI
Un inventario sin ownership es una lista de huérfanos. Cada script necesita una persona nombrada que pueda declarar su justificación de negocio y aprobar sus cambios. Pero "owner" solo se difumina rápido en un incidente, así que reparte el trabajo entre roles con un RACI simple: quién es Responsible, Accountable, Consulted e Informed por cada parte del programa.
| Actividad | Owner del script | Ingeniería | Seguridad | Privacidad | Cumplimiento |
|---|---|---|---|---|---|
| Mantener el inventario vivo | C | R/A | I | I | I |
| Aprobar un script nuevo / justificación | A | R | C | C | I |
| Clasificar tier de acceso a datos | C | I | C | A/R | I |
| Investigar una alerta de cambio | C | C | A/R | C | I |
| Autorizar un bloqueo | A | R | C | I | I |
| Producir evidencia de auditoría | C | I | C | C | A/R |
Una regla mantiene esto honesto: cada fila tiene exactamente un Accountable. Cuando PCI DSS 6.4.3 te pide justificar y autorizar cada script de página de pago, "quién aprobó esto" debe resolverse a un nombre, no a un encogimiento de hombros. El RACI convierte el inventario de lista en programa operado por personas.
Clasifica el acceso a datos en tiers
No todo script merece la misma confianza. Clasifica según lo que puede alcanzar en el navegador y gobierna cada tier de forma distinta. Un píxel de marketing que lee un formulario de checkout es el patrón exacto detrás del robo de Magecart y e-skimming, así que la clasificación debe ser de comportamiento, no solo por reputación de vendor.
| Tier | Datos que el script puede tocar | Gobernanza |
|---|---|---|
| Tier 1, sensible | Campos de pago, credenciales, tokens de sesión | Revisar cada cambio; default-deny para acciones riesgosas |
| Tier 2, personal | Inputs de formularios, cookies identificables | Aprobar acceso, monitorizar destinos |
| Tier 3, bajo | Sin PII, solo assets estáticos | Revisión periódica ligera |
cside permite definir política de comportamiento por script: un widget de chat puede renderizar sin leer el campo de pago junto a él, y una etiqueta de analítica puede correr mientras se le bloquea acceso a cookies o formularios. Eso convierte la etiqueta de tier en una regla aplicada, no una nota en un spreadsheet.
Monitoriza cambios, porque la aprobación es un momento y los scripts son continuos
El hueco peligroso en la mayoría de programas es el tiempo. Un script se aprueba una vez y luego cambia en silencio durante meses. Las comprobaciones estáticas pierden esto: una CSP solo gobierna el origen de carga, y un hash SRI protege un archivo estático pero se rompe en los scripts dinámicos de los que dependen la mayoría de sitios modernos, así que los equipos lo quitan. La aprobación es una foto; el riesgo es una película.
La monitorización de cambios cierra el hueco observando comportamiento runtime, no solo dominio de origen. Cuando un script Tier 1 empieza a leer un campo que nunca tocaba, hace beacon a un destino nuevo o su payload cambia, esa es la señal. cside captura comportamiento runtime, cambios de payload y nuevos destinos de red, y alerta sobre cambios no autorizados. Esa misma captura es lo que espera PCI DSS 11.6.1: detectar y alertar sobre modificación no autorizada de scripts de página de pago y cabeceras HTTP, al menos semanalmente o según tu análisis de riesgo bajo el requisito 12.3.1.
Define una cadencia de revisión ligada al tier de datos
La cadencia evita que el programa se pudra entre incidentes. Hazla depender del tier, no solo del calendario:
- Scripts Tier 1: reatestar en cada cambio y al menos trimestralmente.
- Scripts Tier 2: revisar trimestralmente y ante cualquier destino nuevo.
- Scripts Tier 3: revisar anualmente, o cuando suban de tier.
- Cualquier script nuevo o no aprobado: revisar al detectarlo, sin esperar.
Una revisión que no produce registro es una conversación, no un control. Cada pasada debe dejar una nota fechada: quién revisó, qué comprobó y qué vence después.
Puntúa tu programa contra un modelo de madurez
Un marco solo ayuda si sabes dónde estás. Usa estos cinco niveles para puntuar el programa honestamente, por superficie. Tus páginas de pago pueden estar en un nivel distinto al sitio de marketing, y el hueco entre ambos suele ser donde vive el riesgo.
| Nivel | Estado | Cómo se ve | Postura de auditoría |
|---|---|---|---|
| 1, Ad hoc | Sin inventario | Scripts añadidos por cualquiera, sin lista ni owners | Falla 6.4.3 el primer día |
| 2, Documentado | Spreadsheet estático | Lista de vendors existe pero se vuelve obsoleta; sin cuartas partes | Inventario existe, integridad no probada |
| 3, Con owner | RACI asignado | Owners nombrados, justificaciones, revisión periódica manual | Puede mostrar autorización, débil en detección de cambios |
| 4, Monitorizado | Alertas runtime de cambio | Monitorización de comportamiento, política por tiers, alertas resueltas | Cumple la intención de 11.6.1 |
| 5, Continuo | Evidencia bajo demanda | Inventario vivo, tiers aplicados, timeline inmutable exportable | Listo para auditoría sin simulacro de incendio |
La mayoría descubre que está en nivel 2 en la superficie que más importa. El salto que cuenta es de nivel 3 a nivel 4: pasar de "tenemos lista y owners" a "nos alertan en el momento en que un script Tier 1 cambia comportamiento". Esa es la línea entre un dossier y un control, y ahí gana su lugar la monitorización de navegador.
Conserva evidencia que acepte un auditor
El marco solo cuenta si puedes probar que corrió. Para PCI DSS 4.0.1, eso significa un inventario con justificación documentada para cada script de página de pago (6.4.3) y un rastro de alertas de manipulación para cambios no autorizados en scripts y cabeceras HTTP (11.6.1), ambos obligatorios desde 2025-03-31. Un procesador de pagos como Stripe o Adyen no hace que tu propia página cumpla. Los scripts de tu checkout siguen siendo tu responsabilidad, y un iframe de terceros no mueve esa línea.
cside conserva esto como una línea temporal inmutable y consultable: qué es cada script, quién lo aprobó, a qué datos accedió, cada cambio, cada alerta y cómo se resolvió. Cuando el evaluador pregunta "muéstrame", exportas un registro en vez de reconstruirlo de memoria. La capa de navegador también importa aquí: cside captura señales de dispositivo e IP real, comportamiento de agentes IA y bots, y patrones VPN/proxy, así que la evidencia refleja lo que corrió para usuarios reales en vez de lo que vio un crawler periódico. Las señales están disponibles por API, para que el inventario y las alertas alimenten tus herramientas GRC o SIEM.
Por qué un programa supera una checklist en 2026
La presión de automatización está subiendo del lado atacante. La investigación propia de cside encontró que las instalaciones de playwright-stealth crecieron aproximadamente 10x durante 2025, lo que implica más actividad automatizada y evasiva probando superficies client-side (informe de investigación de cside). Los crawlers que escanean periódicamente son justo lo que la automatización evasiva está diseñada para esquivar: servir código limpio al escáner y payload malicioso a la sesión real. Un spreadsheet estático anual no puede seguir ese ritmo; un modelo operativo continuo con owners, tiers y alertas de cambio en usuarios reales sí. El marco convierte un montón de scripts en algo que gobiernas.
Lecturas adicionales en cside
- Mejores prácticas para proteger scripts de terceros
- Principales plataformas para monitorización de scripts de terceros
- Cómo cumplir PCI 6.4.3 y 11.6.1
- Qué es client-side security
- cside PCI Shield
- Cumplimiento de la directiva NIS2 y obligaciones de scripts de terceros en sitios web
A fecha de 2026-06-18, trata esto como una guía operativa, no como asesoramiento legal. Confirma el texto exacto del control con tu QSA, asesor jurídico o responsable de riesgos.
