O Padrão de Segurança de Dados do Setor de Cartões de Pagamento (PCI DSS) é a referência para a proteção de dados de portadores de cartão e, em sua versão atual, exige mais das equipes de API do que qualquer versão anterior. Veja a situação atual do padrão, quais requisitos impactam mais suas APIs e como a Salt ajuda você a cumpri-los.
A situação atual do padrão
O PCI DSS v4.0.1 é a versão publicada atualmente. O Conselho a lançou em 11 de junho de 2024 como uma revisão limitada que esclareceu requisitos existentes sem adicionar ou excluir nenhum, e a v4.0 foi descontinuada em 31 de dezembro de 2024.
A mudança mais importante é o cronograma. A versão 4.x introduziu 64 novos requisitos, e 51 deles tinham data futura e entraram em vigor em 31 de março de 2025. Em qualquer avaliação aplicável hoje, eles são requisitos obrigatórios, e não apenas itens de planejamento. Se o seu programa de segurança de API foi estruturado com base no período de transição, este é o momento de revisá-lo.
O Conselho realizou uma Solicitação de Comentários sobre a v4.0.1 até julho de 2026 para definir a próxima iteração. Nenhuma versão sucessora foi publicada, portanto, a v4.0.1 é a base pela qual você será avaliado.
Cadeia de controle PCI da Salt
As APIs impactam o PCI DSS em todas as etapas do ciclo de vida do software, e é por isso que a Salt cobre toda a cadeia, em vez de apenas um ponto de controle. A Plataforma de Segurança Agêntica opera desde fora do seu perímetro, passando pelo seu código, até o tráfego em tempo real:
- Salt Surface realiza varreduras da internet para dentro, sem necessidade de implantação, identificando APIs expostas externamente e endpoints agênticos acessíveis de fora. É ideal para a descoberta de escopo e para revelar endpoints públicos que não foram documentados.
- Salt Connect trabalha de dentro para fora por meio de integrações sem agentes com provedores de nuvem, gateways de API e IA, bancos de dados e plataformas de hospedagem, gerando inventário e postura em nível de configuração sem interceptar o tráfego.
- Descoberta contínua de APIs mantém um panorama em tempo real de APIs internas, externas, de terceiros, shadow e zumbis, com metadados de endpoint, método de autenticação, classificação de dados e padrões de tráfego associados.
- Descoberta de dados sensíveis classifica APIs que lidam com PCI e outros dados regulamentados, mapeia caminhos de acesso, sinaliza dados sensíveis em endpoints públicos ou não autenticados e valida a proteção da camada de transporte.
- Salt Code aplica políticas de segurança e conformidade em assistentes de codificação por IA, pull requests e CI/CD, além de revisar repositórios existentes em busca de autenticação ausente, dados sensíveis desprotegidos, segredos codificados e padrões de log de risco.
- Governança de Postura e o Policy Hub definem padrões de postura com suporte nativo ao framework PCI DSS, detectam desvios, expõem violações e exportam evidências para fluxos de trabalho de auditoria.
- Salt Collect observa o tráfego em tempo real em mais de 70 tecnologias, fornecendo dados comportamentais de runtime que a configuração e a revisão de código não conseguem produzir por conta própria.
- Salt Protect detecta abusos de API e ataques de lógica de negócios por meio de linhas de base comportamentais e oferece suporte a bloqueios direcionados.
- Salt Managed Rules para AWS WAF anexam-se a ACLs da web do AWS WAF para bloqueio em linha de classes de ataque a APIs.
- O Grafo de Segurança Agêntico correlaciona exposição externa, configuração, código e runtime, para que você saiba qual risco de API de pagamento realmente importa.
Essa cadeia é o que faz com que o mapeamento de requisitos abaixo se sustente durante uma avaliação.
Requisito por requisito
6.2.1 e 6.2.3: desenvolvimento seguro e revisão de código
6.2.1 exige que softwares personalizados e sob medida sejam desenvolvidos de forma segura, utilizando padrões da indústria e práticas de desenvolvimento seguro. 6.2.3 exige uma revisão de código apropriada para o código que está sendo escrito, e 6.2.3.1 adiciona controles de independência, conhecimento e aprovação quando essas revisões são realizadas manualmente.
O Salt Code foi criado exatamente para isso. Ele aplica sua política no momento em que o código é escrito, dentro dos assistentes de codificação por IA que seus desenvolvedores já utilizam, e revisa repositórios existentes com base na mesma política. Os resultados são apresentados com referências de arquivo e linha, uma categoria e orientações de remediação, um formato que os engenheiros podem utilizar e os avaliadores podem compreender.
Seu próprio processo de revisão fornece a independência do revisor e a aprovação da gestão exigidas pela 6.2.3.1, juntamente com as etapas de treinamento e aprovação em seu SDLC. O Salt Code oferece a esses revisores um material de base muito melhor para trabalhar.
6.2.4: ataques comuns a software, incluindo abuso de lógica de negócios
Este é o item mais próximo de um requisito de segurança de API criado especificamente no padrão. 6.2.4 solicita técnicas de engenharia de software que previnam ou mitiguem ataques comuns a software, e menciona explicitamente o abuso de lógica de negócios por meio da manipulação de APIs, protocolos e funcionalidades do lado do cliente, juntamente com ataques a mecanismos de controle de acesso.
Falhas de lógica de negócios são a razão pela qual a segurança de API precisa de uma abordagem própria. Não existe CVE para um endpoint que permite que um usuário autenticado recupere os dados do cartão de outro usuário apenas alterando um identificador. A solicitação está bem estruturada, as credenciais são válidas e o canal está criptografado. O que torna isso um ataque é o comportamento, e comportamento é o que o Salt foi projetado para identificar.
O Salt cobre esse requisito em ambas as extremidades do ciclo de vida. Antes da produção, o Salt Code aplica políticas de autenticação, autorização, dados sensíveis e design seguro. Após a implantação, o Collect e o Protect estabelecem uma linha de base do comportamento normal em atributos de API e de usuário para detectar tomada de conta (account takeover), exfiltração de dados, abuso de sessão, abuso de controle de acesso e ataques do tipo "low-and-slow". Poucos controles em sua pilha tecnológica abordam ambos os lados do 6.2.4 da maneira que essa combinação faz.
6.3.1 e 6.3.2: vulnerabilidades e inventário
6.3.1 exige a identificação e o gerenciamento de vulnerabilidades com classificações de risco atribuídas em softwares personalizados, sob medida e de terceiros. 6.3.2 exige um inventário de softwares personalizados e sob medida, além dos componentes de software de terceiros incorporados a eles, mantido para apoiar o gerenciamento de vulnerabilidades e patches.
O Salt Code, o Posture Governance e o contexto de tempo de execução identificam riscos de API e de aplicação, priorizando-os com base na exposição, dados sensíveis e comportamento observado. O Surface, o Connect e a descoberta contínua oferecem uma visão da sua superfície de aplicação personalizada que permanece atualizada conforme os sistemas mudam, em vez de uma que se torna obsoleta no momento em que a próxima implantação é realizada.
Para uma cobertura completa do 6.3.2, combine seu inventário de API do Salt com seu inventário de componentes de software ou SBOM. Os dois são complementares: o seu cataloga os componentes, o Salt cataloga as interfaces que esses componentes realmente expõem, incluindo aquelas que nunca chegaram à documentação.
6.4.2: detecção e prevenção automatizadas para aplicações voltadas ao público
Vale a pena recalibrar se você estiver trabalhando com orientações mais antigas. Segundo o Conselho, após 31 de março de 2025, o requisito 6.4.2 entra em vigor, enquanto o 6.4.1 é substituído e reportado como não aplicável. O caminho de revisão manual de vulnerabilidades foi eliminado. Aplicações web voltadas ao público precisam de uma solução técnica automatizada que detecte e previna continuamente ataques baseados na web.
O Salt oferece suporte a esse requisito em toda a sua superfície de ataque de API. O Salt Protect detecta ataques específicos de API em tempo de execução e permite o bloqueio direcionado. As Salt Managed Rules para AWS WAF vão além, bloqueando inline dentro do AWS WAF ataques de força bruta de credenciais, SSRF, poluição de protótipo, consultas GraphQL excessivas e anomalias em JWT. Para aplicações orientadas por API, esta é uma resposta materialmente mais robusta ao 6.4.2 do que um conjunto de regras de WAF de uso geral oferece por si só, uma vez que esses conjuntos de regras não foram criados pensando nas classes de ataque a APIs.
A cobertura para classes de ataques web não relacionados a APIs provém de seus controles de aplicação web mais amplos e, como sempre, seu avaliador confirmará a suficiência em relação à sua arquitetura.
6.4.3 e 11.6.1: scripts em páginas de pagamento
Estes requisitos também entraram em vigor em 31 de março de 2025 e são a parte da v4.x mais frequentemente subestimada por comerciantes de e-commerce. O Conselho publicou orientações dedicadas sobre segurança em páginas de pagamento e e-skimming em março de 2025.
6.4.3 exige que os scripts carregados e executados na página de pagamento sejam gerenciados: cada um autorizado, com sua integridade garantida e um inventário mantido com justificativa técnica ou de negócio por escrito. 11.6.1 exige um mecanismo que detecte e alerte sobre modificações não autorizadas em cabeçalhos HTTP que impactam a segurança e no conteúdo da página de pagamento conforme recebido pelo navegador do consumidor.
Estes são controles na camada do navegador, e atendê-los exige ferramentas dedicadas de integridade de script que observem a página conforme ela é recebida pelo navegador do consumidor. O Salt opera na camada inferior, onde os dados do titular do cartão realmente residem, e as duas soluções se complementam perfeitamente.
Um controle de integridade de script informa que um script na sua página de pagamento foi alterado. O Salt informa o que essa alteração pode alcançar: quais APIs o script invoca, se essas APIs manipulam dados do titular do cartão, se sua postura de autenticação é sólida e se seu comportamento em tempo de execução mudou após a alteração. O e-skimming só é relevante por causa dos dados na outra extremidade da chamada, e essa extremidade é a do Salt. Comerciantes que utilizam ambos os controles obtêm o caminho completo, desde a página de pagamento até o script, a API e os dados do titular do cartão.
Um esclarecimento importante, já que causa muita confusão: as revisões de 2025 do SAQ A removeram o 6.4.3 e o 11.6.1 desse questionário e adicionaram um critério de elegibilidade exigindo que o comerciante confirme que seu site não é suscetível a ataques de script que afetem seus sistemas de e-commerce. Os requisitos não foram removidos do padrão em si, portanto, isso não é uma isenção geral da segurança de scripts.
6.5.1 e 6.5.2: gerenciamento seguro de mudanças
A norma 6.5.1 exige que as alterações em produção sejam gerenciadas com uma justificativa documentada, análise de impacto de segurança, aprovação, testes e um plano de reversão seguro. A norma 6.5.2 exige a confirmação, após alterações significativas, de que os controles PCI aplicáveis permanecem ativos e que a documentação foi atualizada.
O Salt Code testa o código em relação à política antes da implantação. O Posture Governance detecta desvios posteriormente e exporta as evidências. A conexão e a descoberta contínua revelam APIs recém-expostas introduzidas por uma alteração. Juntos, eles fornecem uma resposta documentada para a pergunta "esta alteração afetou nossa postura de segurança?", que é o que a norma 6.5.2 realmente questiona, e algo difícil de responder de forma confiável sem monitoramento contínuo.
Seu fluxo de trabalho de gerenciamento de mudanças fornece a aprovação, a justificativa de negócio e o procedimento de reversão. O Salt fornece as evidências de segurança de que esse fluxo de trabalho necessita.
4.2.1: dados do titular do cartão em trânsito
A norma 4.2.1 exige criptografia forte e protocolos de segurança para proteger os dados do titular do cartão transmitidos por redes públicas e abertas.
A contribuição do Salt aqui é encontrar os caminhos que você desconhecia. A descoberta de dados sensíveis classifica as APIs que transportam dados PCI, mapeia seus caminhos de acesso, sinaliza dados sensíveis acessíveis em endpoints públicos ou não autenticados e valida a proteção da camada de transporte. É assim que as equipes encontram caminhos de transmissão fracamente protegidos que ninguém documentou, e o Salt Code pode aplicar padrões de API seguros antes que o próximo seja lançado.
Assim que o Salt identifica uma proteção de transporte fraca ou ausente, sua equipe de plataforma realiza a alteração na configuração de TLS e certificados.
12.5.1 e 12.5.2: escopo e inventário
A norma 12.5.1 exige um inventário atualizado dos componentes do sistema no escopo. A norma 12.5.2 exige que você documente e confirme o escopo PCI pelo menos anualmente e após alterações significativas, incluindo fluxos de dados de pagamento.
O escopo é onde a proliferação de APIs causa danos reais. Um endpoint não documentado que processa dados de cartão, acessível pela internet, é uma falha de escopo antes mesmo de ser uma falha de segurança, e é exatamente o tipo de coisa que uma revisão pontual deixa passar.
O Surface, a conexão, a descoberta contínua e o mapeamento de dados sensíveis fornecem, em conjunto, uma visão das APIs expostas e internas, endpoints fantasma e zumbis, propriedade, postura e fluxos de dados do titular do cartão. O Salt cobre a parte de APIs e agentes do seu inventário no escopo com profundidade; sua documentação de escopo do CDE incorpora o restante do ambiente, bem como os diagramas de rede e de fluxo de dados exigidos pelo PCI.
Como o Salt se integra aos seus outros controles PCI
O PCI DSS é uma estrutura que abrange pessoas, processos e tecnologia, e um programa robusto sobrepõe controles em vez de depender de apenas um deles. O Salt é a camada de APIs e agentes desse programa. Veja como ele se posiciona em relação aos demais:
- Seu auditor determina a conformidade. O Salt fornece os controles técnicos e as evidências contínuas que tornam o processo de auditoria mais fluido.
- Sua verificação de ASV e vulnerabilidades atende aos requisitos de verificação do item 11.3. A postura e as descobertas de código da Salt ajudam você a priorizar o que remediar primeiro, usando o contexto de exposição e de dados do titular do cartão que essas verificações não possuem.
- Seus sistemas de identidade cuidam da autenticação, MFA e acesso privilegiado. A Salt identifica lacunas na postura de autenticação e autorização em suas APIs e detecta o uso indevido de credenciais tecnicamente válidas.
- Ferramentas dedicadas de integridade de scripts cobrem os itens 6.4.3 e 11.6.1 no navegador. A Salt cobre as APIs e os dados do titular do cartão que esses scripts acessam.
- Seu programa de gerenciamento de patches e vulnerabilidades rastreia fontes de vulnerabilidade reconhecidas pelo setor. A Salt adiciona os riscos da camada de API que nunca aparecem em um feed de CVE.
- Sua plataforma de logs atende ao Requisito 10 em todos os sistemas no escopo. A telemetria de tempo de execução e as linhas do tempo de ataque da Salt fornecem as evidências de segurança de API que faltariam, por meio de seus fluxos de trabalho de SIEM e SOAR.
- Sua plataforma de dados impõe a retenção e a exclusão segura conforme o item 3.2.1. A Salt mostra onde os dados regulamentados estão realmente fluindo pelas APIs, o que geralmente é a parte que ninguém mapeou.
Dando o próximo passo
As APIs carregam uma parcela maior do peso do PCI DSS na versão 4.x do que em qualquer versão anterior, e os requisitos mais importantes são aqueles que as ferramentas tradicionais de segurança de aplicações lidam menos bem: abuso de lógica de negócios, manipulação de controle de acesso, inventário continuamente atualizado e dados do titular do cartão movendo-se por interfaces que ninguém documentou. Esses são os problemas para os quais a Salt foi criada, abrangendo descoberta, código, configuração, exposição de dados, comportamento em tempo de execução e aplicação, com evidências técnicas contínuas em vez de capturas de tela anuais.
Se você quiser ver quais de suas APIs lidam com dados do titular do cartão e onde estão as lacunas técnicas, solicite uma Avaliação da Superfície de Ataque de API, ou solicite uma demonstração e nossa equipe poderá analisar seu escopo PCI com você.
O PCI DSS v4.0.1 é o padrão vigente publicado em setembro de 2026. A Salt oferece controles técnicos, visibilidade e evidências que dão suporte aos requisitos do PCI DSS. A Salt não certifica uma entidade como compatível com o PCI. A aplicabilidade e a suficiência dependem da sua arquitetura e devem ser validadas pelo seu adquirente, bandeira de pagamento, ISA ou QSA.
Publicado originalmente por Amanda Fitzsimmons em 21 de junho de 2024. Atualizado em 18 de setembro de 2026 por Nika Engberg, Chefe do Departamento Jurídico.