El Estándar de Seguridad de Datos para la Industria de Tarjeta de Pago (PCI DSS) es la vara de medir para proteger los datos de los titulares de tarjetas y, en su versión actual, exige más a los equipos de API que cualquier versión anterior. A continuación, le explicamos la situación actual del estándar, qué requisitos tienen mayor peso en sus API y cómo Salt le ayuda a cumplirlos.
Situación actual del estándar
PCI DSS v4.0.1 es la versión publicada actualmente. El Consejo la lanzó el 11 de junio de 2024 como una revisión limitada que aclaró los requisitos existentes sin añadir ni eliminar ninguno, y la v4.0 se retiró el 31 de diciembre de 2024.
El cambio más importante es el cronograma. La versión 4.x introdujo 64 nuevos requisitos, y 51 de ellos tenían fecha futura y entraron en vigor el 31 de marzo de 2025. En cualquier evaluación aplicable hoy en día, son requisitos obligatorios y no simples objetivos a futuro. Si su programa de seguridad de API se diseñó teniendo en cuenta el periodo de transición, este es el momento de revisarlo.
El Consejo llevó a cabo una solicitud de comentarios sobre la v4.0.1 hasta julio de 2026 para dar forma a la próxima iteración. No se ha publicado ninguna versión sucesora, por lo que la v4.0.1 es la norma bajo la cual será evaluado.
La cadena de control PCI de Salt
Las API afectan al PCI DSS en cada etapa del ciclo de vida del software, por lo que Salt cubre toda la cadena en lugar de un único punto de control. La Plataforma de Seguridad Agéntica funciona desde fuera de su perímetro, a través de su código y hasta su tráfico en tiempo real:
- Salt Surface escanea desde internet hacia adentro sin necesidad de despliegue, detectando API expuestas externamente y puntos finales agénticos accesibles desde el exterior. Es ideal para el descubrimiento del alcance y para identificar puntos finales públicos que nadie documentó.
- Salt Connect funciona desde adentro hacia afuera mediante integraciones sin agentes con proveedores de nube, puertas de enlace de API e IA, bases de datos y plataformas de alojamiento, generando un inventario y una postura a nivel de configuración sin interceptar el tráfico.
- Descubrimiento continuo de API mantiene una imagen en tiempo real de las API internas, externas, de terceros, en la sombra y zombis, junto con metadatos de puntos finales, métodos de autenticación, clasificación de datos y patrones de tráfico.
- Descubrimiento de datos confidenciales clasifica las API que manejan datos PCI y otros datos regulados, mapea las rutas de acceso, señala datos confidenciales en puntos finales públicos o sin autenticar y valida la protección de la capa de transporte.
- Salt Code aplica políticas de seguridad y cumplimiento dentro de asistentes de codificación por IA, solicitudes de extracción (pull requests) y CI/CD, además de revisar repositorios existentes en busca de autenticación faltante, datos confidenciales desprotegidos, secretos codificados y patrones de registro de riesgos.
- Gobierno de postura y el Centro de políticas definen estándares de postura con soporte integrado para el marco PCI DSS, detectan desviaciones, exponen infracciones y exportan evidencia para flujos de trabajo de auditoría.
- Salt Collect observa el tráfico en tiempo real a través de más de 70 tecnologías, proporcionando datos de comportamiento en tiempo de ejecución que la configuración y la revisión de código no pueden generar por sí solas.
- Salt Protect detecta el abuso de API y los ataques a la lógica empresarial mediante el establecimiento de líneas base de comportamiento y permite el bloqueo dirigido.
- Reglas gestionadas de Salt para AWS WAF se integran con las ACL web de AWS WAF para el bloqueo en línea de clases de ataques a API.
- El gráfico de seguridad agente correlaciona la exposición externa, la configuración, el código y el tiempo de ejecución, para que pueda determinar qué riesgo de una API de pago es realmente importante.
Esa cadena es lo que permite que el mapeo de requisitos a continuación se mantenga sólido durante una evaluación.
Requisito por requisito
6.2.1 y 6.2.3: desarrollo seguro y revisión de código
6.2.1 exige que el software a medida y personalizado se desarrolle de forma segura utilizando estándares del sector y prácticas de desarrollo seguro. 6.2.3 exige una revisión de código adecuada al código que se está escribiendo, y 6.2.3.1 añade controles de independencia, conocimiento y aprobación cuando dichas revisiones se realizan manualmente.
Salt Code está diseñado exactamente para esto. Aplica su política en el momento en que se escribe el código, dentro de los asistentes de programación por IA que sus desarrolladores ya utilizan, y revisa los repositorios existentes siguiendo la misma política. Los hallazgos se presentan con referencias de archivo y línea, una categoría y una guía de corrección, lo que constituye un formato sobre el que los ingenieros pueden actuar y los evaluadores pueden leer.
Su propio proceso de revisión proporciona la independencia del revisor y la aprobación de la dirección que exige la norma 6.2.3.1, junto con los pasos de formación y aprobación de su ciclo de vida de desarrollo de software (SDLC). Salt Code ofrece a esos revisores un material de trabajo mucho mejor.
6.2.4: ataques comunes a software, incluido el abuso de la lógica de negocio
Este es el punto de la norma que más se acerca a un requisito de seguridad de API diseñado específicamente para tal fin. 6.2.4 solicita técnicas de ingeniería de software que prevengan o mitiguen los ataques comunes a software, y menciona explícitamente el abuso de la lógica de negocio mediante la manipulación de API, protocolos y funcionalidades del lado del cliente, junto con ataques a los mecanismos de control de acceso.
Los fallos en la lógica de negocio son la razón por la que la seguridad de las API necesita su propio enfoque. No existe un CVE para un endpoint que permita a un usuario autenticado recuperar los datos de la tarjeta de otro usuario simplemente cambiando un identificador. La solicitud está bien formada, las credenciales son válidas y el canal está cifrado. Lo que lo convierte en un ataque es el comportamiento, y el comportamiento es precisamente lo que Salt fue diseñado para detectar.
Salt cubre este requisito en ambos extremos del ciclo de vida. Antes de la producción, Salt Code aplica políticas de autenticación, autorización, datos confidenciales y diseño seguro. Tras la implementación, Collect y Protect establecen una línea base del comportamiento normal en los atributos de la API y del usuario para detectar la apropiación de cuentas, la exfiltración de datos, el abuso de sesiones, el abuso de control de acceso y los ataques de baja intensidad y larga duración. Pocos controles en su infraestructura abordan ambos lados de la norma 6.2.4 de la forma en que lo hace esta combinación.
6.3.1 y 6.3.2: vulnerabilidades e inventario
6.3.1 exige identificar y gestionar las vulnerabilidades con clasificaciones de riesgo asignadas en software a medida, personalizado y de terceros. 6.3.2 exige un inventario del software a medida y personalizado, además de los componentes de software de terceros incorporados en él, mantenido para respaldar la gestión de vulnerabilidades y parches.
Salt Code, Posture Governance y el contexto de tiempo de ejecución identifican los riesgos de las API y las aplicaciones, priorizándolos según la exposición, los datos confidenciales y el comportamiento observado. Surface, Connect y el descubrimiento continuo le ofrecen una imagen de su superficie de aplicación personalizada que se mantiene actualizada a medida que los sistemas cambian, en lugar de una que queda obsoleta en el momento en que se realiza la siguiente implementación.
Para una cobertura completa de la norma 6.3.2, combine su inventario de API de Salt con su inventario de componentes de software o SBOM. Ambos son complementarios: el suyo cataloga los componentes, mientras que Salt cataloga las interfaces que esos componentes exponen realmente, incluidas aquellas que nunca llegaron a incluirse en la documentación.
6.4.2: detección y prevención automatizada para aplicaciones de cara al público
Conviene recalibrar si está trabajando con directrices antiguas. Según el Consejo, a partir del 31 de marzo de 2025, el requisito 6.4.2 entra en vigor, mientras que el 6.4.1 queda sustituido y se reporta como no aplicable. La vía de revisión manual de vulnerabilidades ha desaparecido. Las aplicaciones web de cara al público necesitan una solución técnica automatizada que detecte y prevenga continuamente los ataques basados en la web.
Salt respalda este requisito en toda su superficie de ataque de API. Salt Protect detecta ataques específicos a API en tiempo de ejecución y permite el bloqueo dirigido. Las reglas gestionadas de Salt para AWS WAF van más allá, bloqueando en línea dentro de AWS WAF ataques de fuerza bruta de credenciales, SSRF, contaminación de prototipos, consultas GraphQL excesivas y anomalías en JWT. Para aplicaciones basadas en API, esta es una respuesta sustancialmente más sólida al 6.4.2 que la que ofrece un conjunto de reglas WAF de propósito general por sí solo, ya que dichos conjuntos de reglas no fueron diseñados teniendo en cuenta las clases de ataque a API.
La cobertura para clases de ataques web que no son de API proviene de sus controles de aplicaciones web más amplios y, como siempre, su evaluador confirmará la suficiencia en función de su arquitectura.
6.4.3 y 11.6.1: scripts en páginas de pago
Estos requisitos también entraron en vigor el 31 de marzo de 2025 y son la parte de la versión 4.x que los comerciantes de comercio electrónico subestiman con mayor frecuencia. El Consejo publicó una guía específica sobre la seguridad de las páginas de pago y el e-skimming en marzo de 2025.
6.4.3 exige que los scripts que se cargan y ejecutan en la página de pago sean gestionados: cada uno debe estar autorizado, su integridad garantizada y debe mantenerse un inventario con una justificación comercial o técnica por escrito. 11.6.1 exige un mecanismo que detecte y alerte sobre modificaciones no autorizadas en los encabezados HTTP que afectan a la seguridad y en el contenido de la página de pago tal como lo recibe el navegador del consumidor.
Estos son controles a nivel de navegador, y cumplirlos requiere herramientas dedicadas a la integridad de scripts que observen la página tal como la recibe el navegador del consumidor. Salt opera en la capa inferior, donde realmente residen los datos del titular de la tarjeta, y ambos se complementan perfectamente.
Un control de integridad de scripts le indica que un script en su página de pago ha cambiado. Salt le indica a qué puede acceder ese cambio: qué API invoca el script, si esas API manejan datos del titular de la tarjeta, si su postura de autenticación es sólida y si su comportamiento en tiempo de ejecución cambió tras la modificación. El e-skimming solo es relevante debido a los datos que se encuentran en el otro extremo de la llamada, y ese extremo es el de Salt. Los comerciantes que utilizan ambos controles obtienen la trazabilidad completa desde la página de pago hasta el script, la API y los datos del titular de la tarjeta.
Una aclaración necesaria, dado que genera confusión: las revisiones de 2025 del SAQ A eliminaron el 6.4.3 y el 11.6.1 de ese cuestionario y añadieron un criterio de elegibilidad que requiere que el comerciante confirme que su sitio no es susceptible a ataques de scripts que afecten a sus sistemas de comercio electrónico. Los requisitos no se eliminaron del estándar en sí, por lo que esto no constituye una exención general de la seguridad de scripts.
6.5.1 y 6.5.2: gestión segura de cambios
La sección 6.5.1 exige que los cambios en producción se gestionen con una justificación documentada, un análisis de impacto en la seguridad, aprobación, pruebas y un procedimiento de reversión seguro. La sección 6.5.2 requiere confirmar, tras cualquier cambio significativo, que los controles PCI aplicables siguen vigentes y que la documentación está actualizada.
Salt Code analiza el código frente a las políticas antes de su implementación. Posture Governance detecta desviaciones posteriormente y exporta las evidencias. La conexión y el descubrimiento continuo revelan nuevas API expuestas que hayan sido introducidas por un cambio. En conjunto, ofrecen una respuesta documentada a la pregunta "¿afectó este cambio a nuestra postura de seguridad?", que es lo que realmente plantea la sección 6.5.2 y que resulta difícil de responder de forma creíble sin una monitorización continua.
Su flujo de trabajo de gestión de cambios proporciona la aprobación, la justificación empresarial y el procedimiento de reversión. Salt aporta las evidencias de seguridad que dicho flujo de trabajo necesita.
4.2.1: datos del titular de la tarjeta en tránsito
La sección 4.2.1 exige criptografía robusta y protocolos de seguridad para proteger los datos del titular de la tarjeta transmitidos a través de redes públicas abiertas.
La contribución de Salt en este ámbito consiste en encontrar las rutas que usted desconocía. El descubrimiento de datos confidenciales clasifica las API que transportan datos PCI, mapea sus rutas de acceso, señala los datos confidenciales accesibles en puntos finales públicos o no autenticados y valida la protección de la capa de transporte. Así es como los equipos encuentran las rutas de transmisión con protección débil que nadie documentó, y Salt Code puede aplicar patrones de API seguros antes de que se produzca el siguiente despliegue.
Una vez que Salt detecta una protección de transporte débil o inexistente, su equipo de plataforma realiza el cambio en la configuración de TLS y certificados.
12.5.1 y 12.5.2: alcance e inventario
La sección 12.5.1 exige un inventario actualizado de los componentes del sistema incluidos en el alcance. La sección 12.5.2 requiere que usted documente y confirme el alcance PCI al menos una vez al año y tras cualquier cambio significativo, incluyendo los flujos de datos de pago.
El alcance es donde la proliferación de API causa el daño real. Un punto final no documentado que maneja datos de tarjetas y es accesible desde Internet constituye un fallo de alcance antes incluso de ser un fallo de seguridad, y es exactamente el tipo de problema que una revisión puntual pasa por alto.
Surface, Connect, el descubrimiento continuo y el mapeo de datos confidenciales le ofrecen una visión completa de sus API expuestas e internas, puntos finales fantasma y obsoletos, propiedad, postura y flujos de datos de los titulares de tarjetas. Salt cubre en profundidad la parte de API y agentes de su inventario incluido en el alcance; su documentación de alcance del CDE integra el resto del entorno, así como los diagramas de red y de flujo de datos que exige PCI.
Cómo se integra Salt con sus otros controles PCI
PCI DSS es un marco que abarca personas, procesos y tecnología, y un programa sólido superpone controles en lugar de depender de uno solo. Salt constituye la capa de API y agentes de dicho programa. Así es como se sitúa junto al resto:
- Su evaluador determina el cumplimiento. Salt proporciona los controles técnicos y las evidencias continuas que permiten que la evaluación se desarrolle sin problemas.
- Su escaneo de ASV y vulnerabilidades cumple con los requisitos de escaneo de la sección 11.3. La postura de seguridad y los hallazgos de código de Salt le ayudan a priorizar qué remediar primero, utilizando el contexto de exposición y de los datos del titular de la tarjeta que dichos escaneos no poseen.
- Sus sistemas de identidad gestionan la autenticación, el MFA y el acceso privilegiado. Salt identifica brechas en la postura de autenticación y autorización en todas sus API y detecta el abuso de credenciales que son técnicamente válidas.
- Herramientas dedicadas a la integridad de scripts cubren los puntos 6.4.3 y 11.6.1 en el navegador. Salt cubre las API y los datos del titular de la tarjeta a los que acceden dichos scripts.
- Su programa de gestión de parches y vulnerabilidades realiza un seguimiento de las fuentes de vulnerabilidad reconocidas por la industria. Salt añade los riesgos a nivel de API que nunca aparecen en un feed de CVE.
- Su plataforma de registro cumple con el Requisito 10 en todos los sistemas incluidos en el alcance. La telemetría en tiempo de ejecución y las cronologías de ataques de Salt le proporcionan la evidencia de seguridad de API que de otro modo le faltaría, a través de sus flujos de trabajo de SIEM y SOAR.
- Su plataforma de datos aplica la retención y eliminación segura según el punto 3.2.1. Salt le muestra dónde fluyen realmente los datos regulados a través de las API, que a menudo es la parte que nadie ha mapeado.
El siguiente paso
Las API tienen un mayor peso en el cumplimiento de PCI DSS v4.x que en cualquier versión anterior, y los requisitos más importantes son aquellos que las herramientas tradicionales de seguridad de aplicaciones manejan con menos eficacia: abuso de lógica de negocio, manipulación de control de acceso, inventario continuamente actualizado y datos del titular de la tarjeta moviéndose a través de interfaces que nadie documentó. Esos son los problemas para los que se creó Salt, abarcando descubrimiento, código, configuración, exposición de datos, comportamiento en tiempo de ejecución y cumplimiento, con evidencia técnica continua en lugar de capturas de pantalla anuales.
Si desea ver cuáles de sus API manejan datos del titular de la tarjeta y dónde están las brechas técnicas, solicite una Evaluación de la superficie de ataque de API, o solicite una demostración y nuestro equipo podrá revisar su alcance PCI con usted.
PCI DSS v4.0.1 es el estándar vigente publicado a septiembre de 2026. Salt proporciona controles técnicos, visibilidad y evidencia que respaldan los requisitos de PCI DSS. Salt no certifica que una entidad cumpla con PCI. La aplicabilidad y suficiencia dependen de su arquitectura y deben ser validadas por su entidad adquirente, marca de pago, ISA o QSA.
Publicado originalmente por Amanda Fitzsimmons el 21 de junio de 2024. Actualizado el 18 de septiembre de 2026 por Nika Engberg, directora del departamento legal.