O PCI DSS 6.4.3 pede três coisas em toda página de pagamento: um inventário de cada script, uma confirmação de que cada um está autorizado, e garantia de que a integridade de cada script se mantém. O inventário e o registro de autorização são onde a maioria das equipes trava. Este post é apenas sobre esses dois artefatos — como construí-los, quais campos cada registro carrega, e como impedir que fiquem desatualizados na semana seguinte à auditoria.
O controle tornou-se obrigatório em 2025-03-31. Um snapshot de planilha feito uma vez e esquecido não o satisfaz, porque a coisa sendo controlada — JavaScript de terceiros — muda em seu próprio cronograma. Um inventário limpo é um registro vivo com um responsável, uma justificativa, e um histórico de versões por script. Acerte a estrutura do registro primeiro; a decisão de tooling decorre dela.
Para a linguagem do requisito em si, o debate comprar-vs-construir, e o que auditores procuram de ponta a ponta, leia o guia prático de PCI 6.4.3 e 11.6.1 e o guia de avaliação QSA. Esta página se mantém estreita na mecânica do inventário.
Qual escopo o inventário precisa cobrir?
O PCI SSC limita o 6.4.3 aos scripts carregados e executados no navegador do consumidor na página de pagamento — tanto scripts do próprio ambiente da entidade quanto scripts carregados de terceiros e quartos. Leia esse escopo literalmente antes de começar a listar. Seu inventário deve capturar:
- Scripts first-party / same-origin — seus próprios bundles, servidos do seu domínio.
- Scripts inline — snippets colados no template HTML, incluindo bootstraps de tag managers.
- Scripts de terceiros — analytics, testes A/B, widgets de suporte, SDKs de fraude, helpers de pagamento.
- Scripts de quarta parte — qualquer coisa que um script de terceiros carrega depois de rodar. Esses nunca aparecem em um contrato de vendor ou em um tag manager.
A camada de quarta parte é a que as equipes perdem. Uma única tag de analytics pode puxar uma cadeia de scripts adicionais em runtime que ninguém aprovou diretamente. Se o seu inventário começa de uma lista de vendors ou de uma exportação de tag manager, essa cadeia é invisível. Comece a partir do que o navegador de fato recebe na página de pagamento ao vivo.
Quais campos cada linha do inventário precisa?
Uma linha de inventário é evidência. Ela tem que responder "o que é isso, de onde veio, e é a mesma coisa que era na semana passada" sem que ninguém abra o devtools no meio da auditoria. As colunas mínimas úteis:
| Campo | O que registra | Por que um QSA quer |
|---|---|---|
| URL / fonte do script | URL completa, ou inline para código embutido | Identifica o asset e seu domínio de origem |
| Nível de parte | Primeira, terceira ou quarta parte | Prova que cadeias de quarta parte estão contabilizadas |
| Hash de conteúdo | Hash do payload de fato servido | Ancora checagens de integridade ao conteúdo real, não a um nome de arquivo |
| First seen / last seen | Quando apareceu, quando observado pela última vez | Sinaliza scripts que sumiram ou apareceram sem registro de mudança |
| Responsável (Owner) | Pessoa accountable nomeada | Rastreia quem pode justificar o script |
| Justificativa de negócio | Por que roda perto da página de pagamento | Satisfaz a cláusula de "justificativa escrita" |
| Nota de acesso a dados | O que o script pode ler na página | Expõe qualquer coisa tocando campos de formulário |
| Status de autorização | Autorizado / pendente / rejeitado | A própria confirmação de autorização do 6.4.3 |
| Histórico de versões | Hashes anteriores com timestamps | Mostra que o registro é mantido, não um snapshot |
As duas colunas que separam evidência real de uma caixa de verificação são hash de conteúdo e histórico de versões. Uma linha que lista apenas uma URL prova que o script existe. Uma linha que fixa o hash do payload servido ao navegador, e mantém os hashes anteriores, prova que você consegue dizer quando aquele script mudou — o que é a ponte entre o inventário do 6.4.3 e a detecção de mudanças do 11.6.1.
Como se parece um registro de autorização individual?
Autorização não é uma coluna que você marca. É uma decisão que alguém tomou e pode defender. Um registro completo vincula o script a uma pessoa, uma razão, e um momento no tempo. Aqui está uma linha preenchida como exemplo trabalhado:
| Campo | Valor |
|---|---|
| Fonte do script | https://cdn.example-analytics.com/v3/tag.js |
| Nível de parte | Terceiro |
| Hash de conteúdo | sha256:8f2a…c91d (payload servido 2026-06-15) |
| Responsável (Owner) | Priya N., Web Platform Lead |
| Justificativa de negócio | Analytics de funil para relatório de conversão de checkout |
| Nota de acesso a dados | Lê URL da página e eventos de clique; sem acesso a campos de cartão |
| Status de autorização | Autorizado — aprovado 2026-06-15 |
| Histórico de versões | sha256:8f2a…c91d (2026-06-15), sha256:4b07…aa12 (2026-05-02) |
Note a nota de acesso a dados. Ela não apenas diz que o script é permitido — afirma o que o script tem permissão de tocar. Quando a próxima versão daquela tag subitamente começa a ler o campo de cartão, a lacuna entre a nota e o comportamento observado é o alerta. Uma justificativa sem um limite declarado não pode ser violada, então nunca pode disparar nada.
Como você impede o inventário de ficar desatualizado?
O modo de falha é previsível. Uma equipe constrói um inventário minucioso para a auditoria, passa, e dentro de semanas o marketing publica uma nova tag, um vendor lança a v3 do SDK, e uma dependência de quarta parte troca de domínio. Nada disso cai na planilha. O inventário agora é ficção, e a próxima avaliação o expõe.
Um inventário sustentável segue um ciclo, não uma construção única:
- Semeie a partir de capturas ao vivo. Inventarie o que o navegador recebe na página de pagamento de produção, não uma lista de vendors ou uma exportação de tag manager.
- Reduza a superfície. Remova scripts que não precisam rodar na página de pagamento. Menos scripts autorizados significam menos registros para manter honestos.
- Autorize antes da exposição. Atribua um responsável, escreva a justificativa e o limite de acesso a dados, e defina o status antes que o script chegue ao caminho de pagamento.
- Reautorize a cada mudança. Quando o payload servido de um script muda de hash, a autorização anterior não cobre mais o novo conteúdo. Trate cada mudança como uma nova decisão de aprovação.
- Agende uma revisão permanente. Rode uma revisão recorrente para manter o texto de justificativa preciso conforme os scripts evoluem, e para que nada fique em
pendingindefinidamente.
O passo quatro é onde processos manuais colapsam. Uma tag moderna de terceiros pode servir um payload diferente por localização do usuário, navegador, ou hora do dia. Capturar toda mudança de hash manualmente em cada script em cada carregamento não é realista. É por isso que o inventário precisa estar conectado a um mecanismo de detecção em vez de redigitado por um humano a cada semana.
Onde cside se encaixa no fluxo de inventário
cside constrói o inventário a partir da camada do navegador — ele registra os scripts que os navegadores de clientes reais de fato recebem, incluindo cargas inline e de quarta parte que listas de vendors e exportações de tag manager nunca mostram. Cada entrada carrega a fonte, o payload servido, um hash de conteúdo, e timestamps de first-seen / last-seen, então o inventário reflete produção em vez de um snapshot desatualizado.
No lado de autorização, cside armazena o responsável, a justificativa, e o contexto de acesso a dados junto a cada script, e sinaliza quando o conteúdo servido de um script muda para que a autorização anterior possa ser revisada contra o novo payload. Isso transforma o 6.4.3 de uma planilha trimestral em um registro vivo com exportações prontas para QSA, e alimenta a evidência de detecção de mudanças que o 11.6.1 exige. Veja cside PCI Shield para a visão de plataforma.
Leitura adicional na cside
- Como cumprir PCI 6.4.3 e 11.6.1
- O que QSAs devem procurar em 6.4.3 e 11.6.1
- Guia de conformidade client-side do PCI DSS 4.0.1
- cside PCI Shield
A partir de 2026-06-18, trate isto como orientação operacional, não aconselhamento jurídico. Confirme a linguagem exata do controle com seu QSA, assessoria jurídica ou responsável por risco.
