PCI DSS 6.4.3 pide tres cosas en cada página de pago: un inventario de cada script, una confirmación de que cada uno está autorizado y garantías de que la integridad de cada script se mantiene. El inventario y el registro de autorización son donde más equipos se atascan. Este artículo trata solo esos dos artefactos: cómo construirlos, qué campos lleva cada registro y cómo evitar que deriven la semana después de la auditoría.
El control se volvió obligatorio el 2025-03-31. Una captura de spreadsheet hecha una vez y olvidada no lo satisface, porque lo que se controla, JavaScript de terceros, cambia con su propio calendario. Un inventario limpio es un registro vivo con owner, justificación e historial de versiones por script. Acierta primero la estructura del registro; la decisión de tooling viene después.
Para el lenguaje del requisito, el debate comprar-vs-construir y lo que miran los auditores de punta a punta, lee la guía práctica de PCI 6.4.3 y 11.6.1 y la guía de evaluación QSA. Esta página se mantiene estrecha en la mecánica del inventario.
¿Qué alcance debe cubrir el inventario?
El PCI SSC acota 6.4.3 a los scripts cargados y ejecutados en el navegador del consumidor en la página de pago, tanto scripts del entorno propio de la entidad como scripts cargados desde terceros y cuartos. Lee ese alcance de forma literal antes de empezar a listar. Tu inventario debe capturar:
- Scripts first-party / same-origin — tus propios bundles, servidos desde tu dominio.
- Scripts inline — snippets pegados en la plantilla HTML, incluidos bootstraps de tag managers.
- Scripts de terceros — analítica, pruebas A/B, widgets de soporte, SDKs de fraude, helpers de pago.
- Scripts de cuarta parte — cualquier cosa que un script de terceros cargue después de ejecutarse. Estos nunca aparecen en un contrato de vendor ni en un tag manager.
La capa de cuarta parte es la que los equipos pierden. Una sola etiqueta de analítica puede traer una cadena de scripts adicionales en runtime que nadie aprobó directamente. Si tu inventario empieza por una lista de vendors o una exportación de tag manager, esa cadena es invisible. Empieza por lo que el navegador recibe realmente en la página de pago viva.
¿Qué campos necesita cada fila del inventario?
Una fila de inventario es evidencia. Debe responder "qué es esto, de dónde vino y si es lo mismo que era la semana pasada" sin que nadie abra devtools durante la auditoría. Las columnas mínimas útiles:
| Campo | Qué registra | Por qué lo quiere un QSA |
|---|---|---|
| URL / fuente del script | URL completa, o inline para código embebido | Identifica el asset y su dominio de origen |
| Nivel de parte | Primera, tercera o cuarta parte | Demuestra que las cadenas de cuarta parte están contabilizadas |
| Hash de contenido | Hash del payload servido realmente | Ancla comprobaciones de integridad al contenido real, no al nombre de archivo |
| First seen / last seen | Cuándo apareció y cuándo se observó por última vez | Marca scripts que desaparecieron o aparecieron sin registro de cambio |
| Owner | Persona accountable nombrada | Rastrea quién puede justificar el script |
| Justificación de negocio | Por qué corre cerca de la página de pago | Satisface la cláusula de "justificación escrita" |
| Nota de acceso a datos | Qué puede leer el script en la página | Aflora cualquier acceso a campos de formulario |
| Estado de autorización | Autorizado / pendiente / rechazado | La confirmación de autorización de 6.4.3 |
| Historial de versiones | Hashes previos con marcas de tiempo | Muestra que el registro se mantiene, no que es una captura |
Las dos columnas que separan evidencia real de una casilla son hash de contenido e historial de versiones. Una fila que solo lista una URL prueba que el script existe. Una fila que fija el hash del payload servido al navegador y conserva hashes previos prueba que puedes saber cuándo cambió el script, que es el puente entre el inventario de 6.4.3 y la detección de cambios de 11.6.1.
¿Cómo se ve un registro de autorización individual?
La autorización no es una casilla. Es una decisión que alguien tomó y puede defender. Un registro completo vincula el script con una persona, una razón y un momento. Aquí hay una fila completa como ejemplo trabajado:
| Campo | Valor |
|---|---|
| Fuente del script | https://cdn.example-analytics.com/v3/tag.js |
| Nivel de parte | Tercero |
| Hash de contenido | sha256:8f2a…c91d (payload servido 2026-06-15) |
| Owner | Priya N., Web Platform Lead |
| Justificación de negocio | Analítica de embudo para reporting de conversión en checkout |
| Nota de acceso a datos | Lee URL de página y eventos de clic; sin acceso a campos de tarjeta |
| Estado de autorización | Autorizado — aprobado 2026-06-15 |
| Historial de versiones | sha256:8f2a…c91d (2026-06-15), sha256:4b07…aa12 (2026-05-02) |
Fíjate en la nota de acceso a datos. No solo dice que el script está permitido; dice qué puede tocar. Cuando la siguiente versión de esa etiqueta empieza a leer de repente el campo de tarjeta, el hueco entre la nota y el comportamiento observado es la alerta. Una justificación sin límite declarado no puede violarse, así que nunca puede activar nada.
¿Cómo evitas que el inventario se vuelva obsoleto?
El modo de fallo es predecible. Un equipo construye un inventario exhaustivo para la auditoría, aprueba, y en pocas semanas marketing publica una etiqueta nueva, un vendor lanza v3 de su SDK y una dependencia de cuarta parte cambia de dominio. Nada cae en el spreadsheet. El inventario ahora es ficción, y la siguiente evaluación lo expone.
Un inventario mantenible sigue un bucle, no una construcción de una sola vez:
- Semilla desde capturas reales. Inventaría lo que el navegador recibe en la página de pago de producción, no una lista de vendors ni una exportación de tag manager.
- Reduce superficie. Elimina scripts que no necesitan correr en la página de pago. Menos scripts autorizados significan menos registros que mantener honestos.
- Autoriza antes de exponer. Asigna owner, escribe la justificación y el límite de acceso a datos, y define el estado antes de que el script llegue al camino de pago.
- Reautoriza en cada cambio. Cuando el payload servido por un script cambia de hash, la autorización anterior ya no cubre el contenido nuevo. Trata cada cambio como una nueva decisión de aprobación.
- Programa una revisión permanente. Ejecuta una revisión recurrente para mantener precisa la justificación y evitar que algo quede en
pendingindefinidamente.
El paso cuatro es donde colapsan los procesos manuales. Una etiqueta moderna de terceros puede servir un payload distinto por ubicación, navegador u hora del día. Capturar a mano cada cambio de hash en cada script y cada carga no es realista. Por eso el inventario debe conectarse a un mecanismo de detección en vez de reescribirse manualmente cada semana.
Dónde encaja cside en el workflow de inventario
cside construye el inventario desde la capa del navegador: registra los scripts que los navegadores de clientes reales reciben, incluidos scripts inline y cargas de cuarta parte que listas de vendors y exportaciones de tag manager nunca muestran. Cada entrada lleva fuente, payload servido, hash de contenido y marcas de first-seen / last-seen, así que el inventario refleja producción y no una captura obsoleta.
En autorización, cside guarda owner, justificación y contexto de acceso a datos junto a cada script, y marca cuando el contenido servido de un script cambia para revisar la autorización anterior contra el nuevo payload. Eso convierte 6.4.3 de un spreadsheet trimestral en un registro vivo con exportaciones listas para QSA, y alimenta la evidencia de detección de cambios que exige 11.6.1. Consulta cside PCI Shield para la vista de plataforma.
Lecturas adicionales en cside
- Cómo cumplir PCI 6.4.3 y 11.6.1
- Qué deberían mirar los QSAs en 6.4.3 y 11.6.1
- Guía de cumplimiento client-side de PCI DSS 4.0.1
- cside PCI Shield
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.
