Gestão de risco de scripts de terceiros é o modelo operacional para rodar JavaScript externo como um programa governado em vez de uma porta aberta. O framework tem seis partes móveis: inventário, responsabilidade, classificação de acesso a dados, monitoramento de mudanças, cadência de revisão e evidência. Faça essas seis trabalharem juntas e você consegue responder às únicas perguntas que importam num incidente ou auditoria: o que roda, quem é o responsável, o que pode tocar, e o que mudou.
A maioria das equipes tem táticas sem um programa. Elas rodam uma Content Security Policy, talvez fixem alguns hashes Subresource Integrity, e mantêm uma planilha de vendors que ficou desatualizada no dia em que um tag manager adicionou um script de quarta parte que ninguém aprovou. Este post cobre o modelo de governança no qual essas táticas se encaixam, os papéis que o executam e a evidência do lado do navegador que cside produz para tornar cada parte real.
O modelo operacional de seis partes
Cada parte do framework responde a uma pergunta que um atacante ou um avaliador fará. Se qualquer coluna estiver em branco, essa é a sua exposição.
| Pilar | A pergunta que responde | Evidência a manter |
|---|---|---|
| Inventário | O que de fato executa no navegador? | URL do script, fonte/quarta parte, data de first-seen, versão |
| Responsabilidade | Quem é accountable por este script? | Responsável nomeado, justificativa de negócio, registro de aprovação |
| Nível de acesso a dados | O que este script pode ler ou enviar? | Acesso a campos, cookies, tokens; rótulo de nível |
| Monitoramento de mudanças | O que mudou, e estava autorizado? | Diffs, novos destinos, alerta + desfecho |
| Cadência de revisão | Quando foi reateestado pela última vez? | Data da última revisão, revisor, próxima data devida |
| Evidência | Conseguimos provar tudo acima? | Linha do tempo imutável por PCI 6.4.3 / 11.6.1 |
Construa o inventário a partir do navegador, não de uma planilha
Uma lista de vendors não é um inventário. Um vendor aprovado pode carregar scripts encadeados que você nunca revisou, e tag managers injetam código em runtime que nenhum scan do lado do servidor vê. Seu inventário precisa vir do que de fato executa nos navegadores de usuários reais, incluindo as quartas partes que seus terceiros puxam.
cside constrói esse inventário a partir de observação ao vivo do navegador: cada script, sua fonte real, quando apareceu pela primeira vez, e o que faz assim que roda. Esse é o eixo do qual os outros cinco pilares pendem, porque você não consegue atribuir um responsável ou um nível de dados a um script que não consegue ver.
Atribua um responsável por script, e então torne os papéis explícitos com RACI
Um inventário sem responsabilidade é uma lista de órfãos. Cada script precisa de um humano nomeado que consiga declarar sua justificativa de negócio e aprovar suas mudanças. Mas "responsável" sozinho se desfoca rápido num incidente, então distribua o trabalho entre papéis com um RACI simples: quem é Responsible, Accountable, Consulted e Informed para cada parte do programa.
| Atividade | Responsável pelo script | Engenharia | Segurança | Privacidade | Conformidade |
|---|---|---|---|---|---|
| Manter o inventário vivo | C | R/A | I | I | I |
| Aprovar um script novo / justificativa | A | R | C | C | I |
| Classificar nível de acesso a dados | C | I | C | A/R | I |
| Investigar um alerta de mudança | C | C | A/R | C | I |
| Autorizar um bloqueio | A | R | C | I | I |
| Produzir evidência de auditoria | C | I | C | C | A/R |
Uma regra mantém isso honesto: cada linha tem exatamente um Accountable. Quando o PCI DSS 6.4.3 pede que você justifique e autorize cada script de página de pagamento, "quem aprovou isto" deve resolver para um nome, não para um encolher de ombros. O RACI é o que transforma o inventário de uma lista em um programa que as pessoas executam.
Classifique o acesso a dados em níveis
Nem todo script merece a mesma confiança. Classifique pelo que ele consegue alcançar no navegador, e então governe cada nível de forma diferente. Um pixel de marketing que lê um formulário de checkout é exatamente o padrão por trás de Magecart e roubo por e-skimming, então a classificação precisa ser comportamental, não apenas por reputação de vendor.
| Nível | Dados que o script pode tocar | Governança |
|---|---|---|
| Nível 1, sensível | Campos de pagamento, credenciais, tokens de sessão | Revisar a cada mudança; default-deny para ações arriscadas |
| Nível 2, pessoal | Inputs de formulário, cookies identificáveis | Aprovar acesso, monitorar destinos |
| Nível 3, baixo | Sem PII, apenas assets estáticos | Revisão periódica leve |
cside permite definir política comportamental por script: um widget de chat pode renderizar sem ler o campo de pagamento ao lado, e uma tag de analytics pode rodar enquanto é bloqueada de acessar cookies ou inputs de formulário. Isso transforma o rótulo de nível numa regra aplicada em vez de uma nota numa planilha.
Monitore mudanças, porque aprovação é um momento e scripts são contínuos
A lacuna perigosa na maioria dos programas é o tempo. Um script é aprovado uma vez, e então muda silenciosamente por meses. Checagens estáticas perdem isso: uma CSP só governa a origem de carregamento, e um hash SRI protege um arquivo estático mas quebra nos scripts dinâmicos dos quais a maioria dos sites modernos depende, então as equipes o removem. Aprovação é um snapshot; risco é um filme.
Monitoramento de mudanças fecha a lacuna observando comportamento de runtime, não apenas o domínio de origem. Quando um script de Nível 1 começa a ler um campo que nunca tocava, faz beacon para um novo destino, ou seu payload muda, esse é o sinal. cside captura o comportamento de runtime, mudanças de payload, e novos destinos de rede, e então alerta sobre mudança não autorizada. Essa mesma captura é o que o PCI DSS 11.6.1 espera: detectar e alertar sobre modificação não autorizada de scripts de página de pagamento e cabeçalhos HTTP, ao menos semanalmente ou conforme sua análise de risco sob o requisito 12.3.1.
Defina uma cadência de revisão vinculada ao nível de dados
A cadência impede o programa de apodrecer entre incidentes. Direcione-a pelo nível, não apenas pelo calendário:
- Scripts de Nível 1: reateestar a cada mudança e ao menos trimestralmente.
- Scripts de Nível 2: revisar trimestralmente e diante de qualquer novo destino.
- Scripts de Nível 3: revisar anualmente, ou sempre que subirem de nível.
- Qualquer script novo ou não aprovado: revisar na detecção, sem esperar.
Uma revisão que não produz registro é uma conversa, não um controle. Cada passagem deve deixar uma nota datada: quem revisou, o que checou, e o que vence a seguir.
Pontue seu programa contra um modelo de maturidade
Um framework só ajuda se você souber onde está nele. Use esses cinco níveis para pontuar o programa honestamente, por superfície. Suas páginas de pagamento podem estar num nível diferente do seu site de marketing, e a lacuna entre elas é geralmente onde o risco mora.
| Nível | Estado | Como se parece | Postura de auditoria |
|---|---|---|---|
| 1, Ad hoc | Sem inventário | Scripts adicionados por qualquer um, sem lista, sem responsáveis | Falha no 6.4.3 no primeiro dia |
| 2, Documentado | Planilha estática | Lista de vendors existe mas fica desatualizada; sem quartas partes | Inventário existe, integridade não provada |
| 3, Com responsável | RACI atribuído | Responsáveis nomeados, justificativas, revisão periódica manual | Consegue mostrar autorização, fraco em detecção de mudanças |
| 4, Monitorado | Alertas de mudança em runtime | Monitoramento comportamental, política por nível, alertas com desfecho | Atende à intenção do 11.6.1 |
| 5, Contínuo | Evidência sob demanda | Inventário vivo, níveis aplicados, linha do tempo imutável exportável | Pronto para auditoria sem simulação de incêndio |
A maioria descobre que está no Nível 2 na superfície que mais importa. O salto que conta é do Nível 3 ao Nível 4: passar de "temos lista e responsáveis" para "somos alertados no momento em que um script de Nível 1 muda de comportamento". Essa é a linha entre uma pasta e um controle, e é onde o monitoramento da camada do navegador ganha seu lugar.
Mantenha evidência que um auditor aceite
O framework só conta se você conseguir provar que ele rodou. Para o PCI DSS 4.0.1, isso significa um inventário com justificativa documentada para cada script de página de pagamento (6.4.3) e um rastro de alertas de adulteração para mudanças não autorizadas em scripts e cabeçalhos HTTP (11.6.1), ambos obrigatórios desde 2025-03-31. Um processador de pagamentos como Stripe ou Adyen não torna sua própria página compatível. Os scripts no seu checkout continuam sendo sua responsabilidade, e um iframe de terceiros não move essa linha.
cside mantém isso como uma linha do tempo imutável e consultável: o que cada script é, quem o aprovou, os dados que acessou, cada mudança, cada alerta, e como cada um foi resolvido. Quando o avaliador perguntar "me mostre", você exporta um registro em vez de reconstruí-lo de memória. A camada do navegador também importa aqui: cside captura sinais de dispositivo e IP real, comportamento de agentes IA e bots, e padrões de VPN/proxy, então a evidência reflete o que de fato rodou para usuários reais em vez do que um crawler periódico por acaso viu. Sinais estão disponíveis via API, para que o inventário e os alertas alimentem suas próprias ferramentas de GRC ou SIEM.
Por que um programa supera uma checklist em 2026
A pressão de automação está subindo do lado do atacante. A própria pesquisa da cside constatou que instalações de playwright-stealth subiram cerca de dez vezes ao longo de 2025, o que significa mais atividade automatizada e evasiva sondando superfícies client-side (relatório de pesquisa da cside). Crawlers que escaneiam periodicamente são exatamente o que a automação evasiva é projetada para desviar: servir código limpo ao scanner e payload malicioso à sessão real. Uma planilha estática anual não acompanha isso; um modelo operacional contínuo com responsáveis, níveis, e alertas de mudança em usuários reais acompanha. O framework é o que transforma um monte de scripts em algo que você governa.
Leitura adicional na cside
- Melhores práticas para proteger scripts de terceiros
- Principais plataformas para monitoramento de scripts de terceiros
- Como cumprir PCI 6.4.3 e 11.6.1
- O que é client-side security?
- cside PCI Shield
- Conformidade da diretiva NIS2 e obrigações de scripts de terceiros em sites
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.
