O SOC 2 exige testes de intrusão e análise de vulnerabilidades?

O SOC 2 exige testes de intrusão?

O SOC 2 não exige testes de intrusão. Os Trust Services Criteria referem-nos num ponto de foco do CC4.1, como um exemplo das avaliações separadas que uma organização pode usar para confirmar que os seus controlos funcionam. Se precisas de um teste, e com que frequência, decorre da tua avaliação de riscos e dos controlos que descreves no relatório.

Quem publica os critérios é o AICPA, o instituto norte-americano dos contabilistas certificados (CPA). A versão em vigor são os Trust Services Criteria de 2017, com os pontos de foco revistos em 2022, um documento gratuito que fica atrás de uma conta no site do AICPA. A redação que citamos vem de empresas de auditoria que a reproduzem. A Linford & Co, uma firma de CPA que faz auditorias SOC 2, é taxativa: «the simple answer is no», a resposta simples é não. O CC4.1 pede à organização que faça avaliações contínuas ou separadas para garantir que os componentes do controlo interno existem e funcionam. O seu ponto de foco põe os testes de intrusão ao lado das certificações independentes, como a ISO, e da auditoria interna, como tipos de avaliação a que a gestão pode recorrer. O artigo da Linford é de junho de 2021, anterior à revisão de 2022.

A revisão de 2022 não transformou isto numa regra. A BARR Advisory, outra empresa de auditoria SOC 2, cita o AICPA sobre os pontos de foco revistos: «do not, in any way, alter the criteria in the 2017 TSC», ou seja, não alteram de forma nenhuma os critérios de 2017.

No papel, o teste é portanto opcional, e cabe-te a ti justificar a decisão. O conselho da Linford é que qualquer empresa que ofereça os seus serviços através de um site público e interativo deve ponderar seriamente fazer um, com a frequência e o âmbito definidos por uma avaliação de riscos rigorosa.

Há um caso em que a escolha já está feita. A empresa de auditoria TrustNet apresenta a descrição do sistema (system description) como o retrato, escrito por ti, dos teus sistemas, serviços e controlos, revisto pelo auditor. O parecer do auditor incide depois sobre se esses controlos estão bem desenhados (Type I) e se funcionaram ao longo do tempo (Type II). Se a tua descrição ou a tua política diz que fazes um teste de intrusão por ano, ele passou a ser um dos teus controlos, e o auditor vai pedir o relatório.

O SOC 2 exige análise de vulnerabilidades?

O SOC 2 não nomeia a análise de vulnerabilidades como requisito. O CC7.1 pede procedimentos de deteção e monitorização que apanhem as alterações de configuração que introduzem vulnerabilidades novas e a exposição a vulnerabilidades recém-descobertas. O ponto de foco «Conducts Vulnerability Scans» descreve scans periódicos e depois de cada alteração significativa, com as deficiências encontradas corrigidas em tempo útil.

A Linford & Co reproduz o ponto de foco: os scans devem correr «on a periodic basis and after any significant change in the environment», periodicamente e depois de qualquer alteração significativa no ambiente, e a organização corrige em tempo útil o que eles encontram. O veredicto é o mesmo que para os testes de intrusão, não há requisito, mas vem com um aviso: pode ser difícil para uma organização cliente aceitar um relatório SOC 2 limpo que não faça qualquer referência a scans.

O resumo da BARR Advisory sobre a revisão de 2022 não inclui o CC7.1 entre as alterações: nas operações do sistema, refere o tratamento de informação confidencial no CC7.3. Já o critério de gestão de alterações, o CC8.1, ganhou pontos de foco sobre a «identification, testing, and implementation of software patches», a identificação, o teste e a aplicação de patches de software. Atualizar uma dependência vulnerável é aplicar um patch, por isso a parte da correção também cai na gestão de alterações.

O ponto de foco não nomeia ferramenta, frequência nem âmbito. És tu que decides o que cobre «o ambiente» (o teu código, as suas dependências, os contentores, a configuração cloud, os hosts), escreves isso na tua política, e o auditor exige-te aquilo que escreveste.

Qual é a diferença entre um scan de vulnerabilidades e um teste de intrusão?

Um scan de vulnerabilidades é automático: uma ferramenta compara o teu código, as dependências ou os hosts com fraquezas conhecidas. Um teste de intrusão é feito por pessoas, que exploram fraquezas com ferramentas e critério próprio para mostrar até onde chegaria um atacante. No SOC 2, os scans sustentam o CC7.1 e o teste de intrusão, o CC4.1.

A Linford & Co traça a fronteira da mesma forma. Uma avaliação de vulnerabilidades «is an automated activity», uma atividade automática feita com uma ferramenta, enquanto um teste de intrusão é feito por uma ou mais pessoas que exploram vulnerabilidades e erros de configuração com ferramentas automáticas e técnicas próprias. Para uma equipa que desenvolve software, «scan» abrange vários tipos de ferramenta: a análise estática do código (SAST), a análise de dependências (SCA), a deteção de segredos e as verificações dos ficheiros de infraestrutura e das imagens de contentores.

Com que frequência deves fazer scans para o SOC 2?

Faz scans com a frequência que a tua política indica, e depois de cada alteração significativa. O SOC 2 não fixa intervalo: o ponto de foco «Conducts Vulnerability Scans» do CC7.1 pede scans periódicos e depois de qualquer alteração significativa no ambiente. Um scan em cada pull request cobre as alterações, e um scan agendado cobre o resto.

O CC7.1 tem duas metades, e cada uma pede o seu próprio gatilho. A primeira são as alterações de configuração que introduzem vulnerabilidades, que apanhas com um scan da própria alteração, na CI, antes do merge. A segunda é a exposição a vulnerabilidades recém-descobertas, que apanhas voltando a analisar, de forma agendada, código em que não voltaste a mexer, porque continuam a sair avisos de segurança novos sobre dependências antigas. No nosso scan de 3 de novembro, quatro dos nove achados críticos de dependências vinham de avisos publicados entre julho e setembro de 2026. Um scan feito em junho, sobre exatamente o mesmo código, não os podia ter reportado.

Escreve os dois gatilhos na tua política, com um prazo por severidade para corrigir o que os scans encontram. O auditor pode escolher qualquer achado do período e compará-lo com os teus prazos, por isso escolhe prazos que consigas cumprir.

Que provas pede um auditor SOC 2?

Um auditor SOC 2 pede registos: que os scans correram quando a tua política dizia, o que cobriram, o que encontraram e o que aconteceu a cada achado, corrigido dentro do prazo ou aceite como exceção com um motivo e um aprovador. Num relatório Type II o parecer cobre um período, por isso os registos também têm de o cobrir.

Um relatório SOC 2 é um exame feito por um CPA licenciado e independente segundo as normas de atestação do AICPA, nas palavras do próprio comunicado do AICPA. Num Type II, o parecer do CPA cobre a forma como os teus controlos funcionaram ao longo de um período. Na gestão de vulnerabilidades, isso traduz-se numa lista curta de perguntas:

Os scanners open source servem de prova para o SOC 2?

Os scanners open source dão a metade de deteção da prova SOC 2. A 3 de novembro de 2026, o Trivy, o Gitleaks e o Opengrep deram 383 achados brutos no OWASP Juice Shop, em quatro ficheiros JSON e 56 segundos. Nenhum ficheiro indica o commit analisado, um responsável, um prazo ou um estado, o registo que o auditor verifica.

Usámos o OWASP Juice Shop na versão 20.3.0, publicada a 11 de outubro de 2026. O README chama-lhe «probably the most modern and sophisticated insecure web application», provavelmente a aplicação web insegura mais moderna e sofisticada, por isso os números abaixo não dizem nada sobre uma base de código normal: mostram a forma daquilo que as ferramentas te entregam. O Juice Shop não traz lockfile, por isso, para o scan de dependências, gerámos um no próprio dia a partir de uma cópia do seu package.json, com os scripts de instalação do npm desligados. Depois corremos quatro comandos:

trivy fs --scanners vuln --format json --output trivy-sca.json sca/
trivy fs --scanners misconfig,secret --format json --output trivy-repo.json juice-shop/
gitleaks dir juice-shop --report-format json --report-path gitleaks.json
opengrep scan --config opengrep-rules/javascript --config opengrep-rules/typescript \
  --config opengrep-rules/terraform --json --output opengrep.json juice-shop/

Resultados de quatro scans open source do OWASP Juice Shop 20.3.0, feitos a 3 de novembro de 2026. Analisámos a tag v20.3.0 no commit f189f52, com as regras da comunidade Opengrep no commit f1d2b56, as definições predefinidas do Trivy e sem qualquer afinação. As quatro execuções levaram 56 segundos de tempo real, incluindo a atualização da base de dados do Trivy:

Cada ferramenta encontrou aquilo para que foi feita. Mesmo assim, há quatro coisas entre estes ficheiros e uma prova SOC 2:

1. Duplicados. Os cinco segredos que o Trivy encontrou estão entre os 69 do Gitleaks, no mesmo ficheiro e na mesma linha. Dos 54 achados Terraform do Opengrep, 17 estão na mesma linha que um achado do Trivy e 34 a três linhas ou menos de um deles. Sem junção, um problema passa a ser dois tickets e dois prazos.
2. Três escalas de severidade. O Trivy classifica de crítico a baixo, o Opengrep de error a info, e o Gitleaks não classifica de todo. Uma política que diz «achados críticos corrigidos em N dias» precisa de uma única escala, por isso alguém tem de fazer corresponder as outras duas.
3. Cobertura. O Opengrep analisou 1.306 ficheiros e registou 32 erros de parsing e análises parciais, numa secção de erros que só vês se leres o ficheiro. Um auditor que pergunte se o scan cobriu o código precisa dessa linha.
4. O próprio registo. Os ficheiros do Trivy trazem um timestamp de criação e o caminho analisado. Os do Opengrep não trazem timestamp nenhum. Em modo de diretório, o Gitleaks deixa vazios os campos de commit e de data. Nenhum ficheiro tem responsável, prazo ou estado.

Os scanners open source, em si, aguentam-se bem. Os nossos testes de ferramentas SAST open source que verificámos no GitHub e de seis scanners de segredos open source testados num mesmo repositório com segredos plantados mostram que consegues cobrir o código e os segredos sem pagar por um scanner. O volume é a outra metade do trabalho, e o nosso artigo sobre o que transforma os achados SAST em ruído explica por que razão uma contagem bruta de 149 achados de código é uma fila de triagem, e não 149 vulnerabilidades.

Para transformar os ficheiros em prova, precisas de uma fila por repositório, onde os achados de todas as ferramentas são juntos, cada um recebe um responsável e um prazo tirado da tua política, e o histórico fica guardado: aberto, corrigido, aceite como exceção. Há quem a construa com uma ferramenta open source de gestão de vulnerabilidades como o DefectDojo, com tickets ou com uma plataforma. O CybeDefend Open Source faz esta parte: corre os scanners que escolheres, qualquer ferramenta que escreva SARIF, e põe o que encontram numa única fila sem duplicados, gratuita e nos teus servidores. É lançado em breve, e a lista de espera está aberta.

O que muda quando são agentes de IA a escrever o código?

Com agentes de IA a escrever o código, os critérios SOC 2 continuam iguais, mas as alterações significativas multiplicam-se, pelo que o scan do CC7.1 tem de correr em cada alteração, não só periodicamente. Os critérios de 2027 propostos pelo AICPA acrescentam pontos de foco sobre IA, só exigíveis em trabalhos iniciados a partir de 31 de dezembro de 2027.

A parte do código escrita por agentes pode ser grande. A 3 de novembro de 2026, 482 dos 509 commits integrados no ramo principal do repositório do nosso próprio site nos 90 dias anteriores traziam um trailer de coautoria do Claude Code. A esse ritmo, há três coisas que mudam para o SOC 2:

• O scan faz a leitura linha a linha. Um gate de merge que analisa cada pull request é a verificação que corre em cada alteração, que é o que pedem o CC7.1 e o CC8.1. O nosso artigo sobre as verificações de segurança no pull request de um agente de IA descreve esse gate.
• As dependências chegam com as funcionalidades. Um agente que acrescenta um pacote acrescenta uma entrada que o scan agendado tem de vigiar, e cada atualização que faz é um patch no âmbito do CC8.1.
• Testes verdes provam menos. Um agente escreve muitas vezes uma funcionalidade e os respetivos testes na mesma sessão. Os testes verificam o que ele queria construir, por isso uma regra que lhe escapou no código pode faltar também nos testes, e a CI continua verde. Um scanner que corre na CI é uma verificação que o agente não escreveu.

Os próprios critérios estão a mudar. A 28 de outubro de 2026, o AICPA pôs em consulta pública um projeto (exposure draft) de novos Trust Services Criteria do SOC 2. O comunicado lista novos pontos de foco sobre «AI governance, model monitoring, prompt manipulation, data poisoning», isto é, a governação da IA, a monitorização de modelos, a manipulação de prompts e o envenenamento de dados, e ainda a transparência dos resultados gerados por IA, a gestão dos dados de treino e a tomada de decisões automatizada. Os comentários estão abertos até 15 de janeiro de 2027. Se forem aprovados, os novos critérios aplicam-se aos trabalhos (engagements) iniciados a partir de 31 de dezembro de 2027, com adoção antecipada permitida. O comunicado não diz se estes pontos de foco abrangem os agentes de programação, e o projeto em si exige uma conta no AICPA, por isso não o lemos. Até os novos critérios serem finais e entrarem em vigor, a tua auditoria usa os critérios de 2017 com os pontos de foco de 2022.

O que tens de ter pronto antes da auditoria SOC 2?

Para a auditoria SOC 2, tem pronta uma política de gestão de vulnerabilidades escrita, scans que correm de forma agendada e em cada alteração, um registo por achado com responsável, prazo e desfecho, exceções aprovadas e um relatório de teste de intrusão se a tua avaliação de riscos o pedir, tudo isto a cobrir o período de auditoria inteiro.

1. A política diz o quê, quando e com que rapidez. O âmbito dos scans, o calendário, os gatilhos, um prazo por severidade e quem pode aprovar uma exceção.
2. Cada alteração passa por um scan. Código, dependências, segredos e ficheiros de infraestrutura em cada pull request, quer o tenha aberto uma pessoa, quer um agente, atrás de um gate que recusa um achado crítico.
3. O calendário apanha os avisos novos. Um scan noturno ou semanal do ramo principal e das imagens que tens a correr, para as vulnerabilidades publicadas depois de o código ter sido escrito.
4. Um achado, um registo. Junto a partir de todas as ferramentas, numa única escala de severidade, com responsável, prazo, estado e histórico.
5. As exceções ficam por escrito. O âmbito, o motivo, o aprovador e a data de expiração.
6. O teste de intrusão está planeado. Um âmbito tirado da tua avaliação de riscos, o relatório guardado, os achados graves corrigidos e verificados de novo.
7. O relatório cobre o período. Um documento construído a partir dos registos, e não uma folha de cálculo montada na semana antes de o auditor chegar.

Scan em cada alteraçãoUm registo por achadoResponsável e prazoCorrigido, ou exceção aprovadaNo relatório do período

Os pontos 2, 5 e 7 são o que faz a plataforma AppSec da CybeDefend. Analisa cada repositório à procura de fraquezas no código (SAST), dependências (SCA), segredos, infraestrutura como código, contentores e pipelines de CI/CD. Uma política de segurança escrita como código bloqueia o merge perante um achado crítico e deixa seguir o risco mais baixo com um aviso, e cada exceção fica limitada a um caminho, datada, justificada e aprovada por nome, deixando uma linha de auditoria. Os relatórios de segurança fazem corresponder os achados ao OWASP Top 10 e ao CWE Top 25, por organização, equipa ou projeto, e exportam-se em PDF para o auditor ou em JSON para uma ferramenta de GRC. Também estamos a passar por este exercício: a auditoria SOC 2 Type II da CybeDefend está em curso. Se estás a preparar a tua com uma equipa que programa com agentes, podemos percorrê-la contigo.

Perguntas frequentes

O SOC 2 Type 2 obriga a fazer testes de intrusão?

Não. Os relatórios Type I e Type II usam os mesmos critérios, e nenhum deles exige um teste de intrusão. Um Type II testa se os teus controlos funcionaram ao longo de um período, por isso, se a tua política prevê um teste de intrusão anual, o auditor confirma que ele foi feito dentro do período e que os achados foram tratados.

De quanto em quanto tempo é preciso fazer um pentest para o SOC 2?

Os critérios não fixam nenhum intervalo. É a tua avaliação de riscos e a tua política que o fixam, e o auditor confirma que cumpriste o que escreveste. Uma grande mudança naquilo que o teu sistema expõe, como uma nova API pública ou um novo produto, é um bom motivo para voltar a testar antes da data prevista.

Basta um scan de vulnerabilidades para cumprir o SOC 2?

Para o CC7.1, um programa de scans é o que os auditores esperam ver, com registos da forma como cada achado foi tratado. Um scan não substitui a avaliação dos teus controlos prevista no CC4.1, que pode ser um teste de intrusão, uma auditoria interna ou uma certificação independente.

O SOC 2 obriga a ter SAST ou análise de código?

Nenhum critério nomeia o SAST. O ponto de foco do CC7.1 abrange vulnerabilidades e erros de configuração no teu ambiente, e o CC8.1 pede que as alterações ao software sejam testadas e aprovadas antes de serem implementadas. Se desenvolves software, analisar o código e as suas dependências em cada alteração é a forma mais simples de mostrar as duas coisas.

Posso usar ferramentas open source para o SOC 2?

Sim. Os critérios não nomeiam nenhuma ferramenta, e o auditor verifica que os scans correram como a tua política diz e que os achados foram tratados. Os scanners open source servem, desde que guardes o registo à volta deles: as datas, o commit analisado, os achados juntos a partir de todas as ferramentas, os responsáveis, os prazos e os desfechos.

O que é o CC7.1 do SOC 2?

O CC7.1 é o critério comum (common criterion) de deteção e monitorização. Pede a uma organização que use procedimentos que identifiquem as alterações de configuração que introduzem vulnerabilidades novas e a sua exposição a vulnerabilidades recém-descobertas. Um dos seus pontos de foco é fazer scans de vulnerabilidades periodicamente e depois de alterações significativas.

O que é o CC4.1 do SOC 2?

O CC4.1 é o critério comum das atividades de monitorização. Pede a uma organização que faça avaliações contínuas ou separadas para confirmar que os componentes do controlo interno existem e funcionam. O seu ponto de foco dá como exemplos dessas avaliações os testes de intrusão, as certificações independentes como a ISO e a auditoria interna.

O que muda com os critérios SOC 2 propostos para 2027?

O AICPA publicou a 28 de outubro de 2026 um projeto para consulta pública que reestrutura partes dos critérios e acrescenta pontos de foco sobre IA, entre eles a governação da IA, a manipulação de prompts, o envenenamento de dados e a transparência dos resultados gerados por IA. Os comentários fecham a 15 de janeiro de 2027. Se forem aprovados, os critérios passam a ser exigidos nos trabalhos iniciados a partir de 31 de dezembro de 2027, com adoção antecipada permitida.