Codificação segura na ISO 27001 (A.8.28) quando são agentes de IA a escrever o código: o que o auditor vai pedir

O que pede o controlo A.8.28 da ISO 27001?

O controlo 8.28 da ISO/IEC 27001:2022, Secure coding (codificação segura), pede que se apliquem princípios de codificação segura ao desenvolvimento de software. Surgiu na edição de 2022. A orientação da ISO/IEC 27002:2022 divide-o em três fases, planeamento antes de programar, programação, e verificação e manutenção, e estende-o aos componentes de terceiros e open source.

O organismo de certificação DQS apresentou o novo controlo em janeiro de 2023, num artigo do seu auditor Markus Jegelka: o enquadramento «is to be applied holistically both to the company's own program code and to software from third parties and open source sources», ou seja, aplica-se de forma integral tanto ao código da própria empresa como ao software de terceiros e open source. A edição de 2022 é a única que um auditor usa hoje. A transição a partir da edição anterior terminou a 31 de outubro de 2025, e os certificados emitidos segundo essa edição caducaram nesse dia, como lembra o organismo de certificação irlandês NSAI, que cita o documento obrigatório MD 26 do IAF.

Um auditor lê o 8.28 em conjunto com os controlos de desenvolvimento que o rodeiam, e cada um deles passa a ser uma pergunta simples quando são agentes a escrever o código:

Os títulos são os do Anexo A de 2022, que deixamos em inglês. O que está entre parênteses é uma explicação nossa, não uma tradução oficial. A ISO vende os textos das suas normas, por isso as passagens citadas neste guia vêm de organismos de certificação e de consultoras que as reproduzem.

A ISO 27001 diz alguma coisa sobre agentes de IA que programam?

A ISO 27001 não diz nada sobre agentes de IA. A edição em vigor, de outubro de 2022, recebeu desde então uma emenda, segundo o catálogo da ISO, e nenhum controlo do Anexo A trata de IA. O código que um agente escreve no teu repositório, com uma conta que lhe deste, é teu, e aplicam-se-lhe os mesmos controlos.

Esta resposta desilude quem espera uma cláusula especial, e é a mais útil das duas. A orientação do 8.28 já pede que as práticas inseguras fiquem fora do código, entre elas as palavras-passe escritas diretamente no código e os excertos de código não aprovados, como resume a ISMS.online a partir da ISO 27002. Um agente que copia um padrão de código de outra parte do repositório, ou do treino, está a produzir exatamente isso, um excerto de código não aprovado, e mais depressa do que um revisor o consegue ler linha a linha. O controlo foi escrito para código de qualquer origem, e os agentes são só mais uma origem.

Há mais duas perguntas que surgem quando uma equipa usa agentes, e ambas ficam fora do 8.28. O que é que o agente envia ao fornecedor do modelo, e esse fornecedor foi avaliado como os teus outros fornecedores? Os nossos guias sobre o que o Claude Code envia à Anthropic e o que o Cursor guarda respondem à primeira, ferramenta a ferramenta. E se alguém te perguntar se precisas da ISO/IEC 42001, a norma de sistemas de gestão de IA que a ISO publicou em dezembro de 2023 para organizações «providing or utilizing AI-based products or services», isto é, que fornecem ou usam produtos ou serviços baseados em IA, é uma certificação à parte, e a ISO 27001 não a exige.

Que provas pede o auditor quando são agentes a escrever o código?

O auditor pede três tipos de provas: documentos que dizem como desenvolves de forma segura, configuração que mostra que as verificações são impostas, e registos de que correram nas alterações do período auditado. Com agentes, os documentos têm de os nomear e os registos têm de cobrir cada alteração que fez merge, mesmo as que nenhuma pessoa escreveu.

A consultora Advisera resume o teste do 8.28 numa linha da sua página sobre o controlo: o auditor verifica «if principles for secure coding are integrated into the software lifecycle process», ou seja, se os princípios de codificação segura estão integrados no ciclo de vida do software, e se não os encontrar, «this is considered a nonconformity», conta como uma não conformidade. Os documentos propriamente ditos «are not mandatory, but are recommended», não são obrigatórios mas são recomendados: uma política de desenvolvimento seguro (Secure Development Policy) numa PME, uma política de codificação segura (Secure Coding Policy) numa empresa maior. Na prática, o auditor faz meia dúzia de perguntas e escolhe alterações por amostragem para confirmar as respostas:

Os testes merecem um aviso à parte. Quando o agente escreve a funcionalidade e os respetivos testes na mesma sessão, uma execução verde prova que o código faz aquilo que o agente percebeu. No estudo controlado da CybeDefend, pelo menos um terço dos desvios às regras que o agente deixou no código estava coberto pelos seus próprios testes, que passavam, e por isso a CI nunca os teria assinalado. Um teste de segurança que o agente não escreveu, um scan ou uma verificação da tua CI, é o que dá sentido ao 8.29.

Um CLAUDE.md ou um AGENTS.md serve de prova de codificação segura?

Um ficheiro de regras não é uma prova: é uma política que o agente lê no início de cada sessão, e nada nele regista se o código a seguiu. No estudo controlado da CybeDefend de 24 de agosto de 2026, uma secção de regras realista deixou tantas regras violadas por ticket como não ter ficheiro nenhum, 2,27 contra 2,28.

As equipas que preparam uma auditoria com agentes põem muitas vezes o padrão de codificação segura no CLAUDE.md ou no AGENTS.md, e é um sítio sensato para o agente o encontrar. A própria documentação da Anthropic sobre memória marca o limite: o Claude trata estes ficheiros «as context, not enforced configuration», como contexto e não como configuração imposta, e «there's no guarantee of strict compliance», não há garantia de cumprimento estrito. O nosso estudo mediu o que isso quer dizer em tickets reais. Um agente, o Claude Opus 5, trabalhou trinta tickets de programador em três configurações, num total de noventa execuções avaliadas às cegas contra grelhas seladas. Com uma secção de regras mantida à mão, o agente implementou exatamente 7 de 55 valores concretos das regras, a mesma nota que sem ficheiro nenhum. Com o corpus completo de regras colado palavra por palavra no ficheiro, chegou a 7 de 11. Os pormenores estão no nosso artigo sobre se o Claude Code segue o CLAUDE.md.

Para um auditor, é a diferença entre a conceção de um controlo e o seu funcionamento. O ficheiro mostra que puseste o padrão por escrito e o entregaste ao agente, o que ajuda no 8.25 e no 8.28. Não mostra nada sobre o código que daí saiu. No mesmo estudo, servir cada regra no momento em que o agente escreve a linha deu melhor resultado, 0,28 regras violadas por ticket, e é isso que faz o VibeDefend. Mesmo assim, o que o auditor aceita como prova é a verificação que correu na alteração e o registo que ela deixou.

Como provas que código foi escrito por um agente de IA?

Prova-o o teu histórico git, se os agentes lá deixarem rasto. Por predefinição, o Claude Code acrescenta a cada commit um trailer Co-Authored-By que nomeia o modelo, e basta uma definição para o retirar. A 27 de outubro de 2026, 467 dos 494 commits do ramo principal do repositório do nosso site nos 90 dias anteriores traziam esse trailer.

Corremos dois comandos nesse repositório para os contar:

git log origin/main --since=2026-07-29 --no-merges --format=%H | wc -l
git log origin/main --since=2026-07-29 --no-merges -i --grep="Co-Authored-By: Claude" --format=%H | wc -l

Ao longo do período, os trailers nomeiam cinco modelos Claude diferentes, por isso o histórico diz que modelo escreveu cada alteração, e os outros 27 commits não trazem trailer nenhum. A referência das definições explica de onde ele vem: por predefinição, o Claude Code acrescenta Co-Authored-By: <name> <noreply@anthropic.com>, em que o nome é o do modelo em uso, e pôr attribution a false esconde-o. Um rasto que cada programador pode desligar é uma convenção. Se o queres nas tuas provas, fixa-o nas definições geridas (managed settings) que a tua organização distribui, e verifica o que os teus outros agentes deixam nos commits e nos pull requests, porque cada ferramenta faz isto à sua maneira.

A autoria diz ao auditor para que alterações deve olhar, mas o controlo propriamente dito é o conjunto de gates pelos quais passa cada alteração. O nosso artigo sobre a revisão dos pull requests de um agente de IA explica por que razão uma conta de máquina dedicada, com commits assinados, vale mais do que uma etiqueta que quem contribui pode simplesmente omitir.

O SOC 2 pede a mesma coisa?

O SOC 2 pede quase o mesmo, em dois critérios. O CC8.1 pede que as alterações ao software sejam autorizadas, concebidas, desenvolvidas, documentadas, testadas, aprovadas e implementadas. O CC7.1 pede deteção e monitorização que apanhem vulnerabilidades novas, com os scans de vulnerabilidades entre os pontos de foco. Um relatório Type II testa depois se estes controlos funcionaram durante um período.

Os Trust Services Criteria do AICPA estão atrás de um login no site do AICPA, por isso o texto abaixo é o que reproduz a documentação da Wazuh. CC8.1: «The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.» CC7.1: «To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.» Entre os pontos de foco listados por baixo de cada um, o CC8.1 inclui «Tests System Changes» e «Approves System Changes», testar e aprovar as alterações ao sistema, e o CC7.1 inclui «Conducts Vulnerability Scans», fazer scans de vulnerabilidades.

A diferença em relação à ISO 27001 está na forma do resultado. A ISO certifica um sistema de gestão, com os controlos do Anexo A que selecionaste na tua Declaração de Aplicabilidade (Statement of Applicability). O SOC 2 é um relatório de atestação. Nas palavras da empresa de auditoria TrustNet, «A licensed CPA gives an opinion on whether your controls are properly designed (Type I) and, if applicable, effectively operating over time (Type II)»: um CPA licenciado dá parecer sobre se os controlos estão bem desenhados (Type I) e, quando se aplica, se funcionam de forma eficaz ao longo do tempo (Type II). Com agentes, um período Type II significa registos de cada alteração ao longo de meses, e o auditor escolhe-os por amostragem tal como faz um auditor ISO. Uma equipa pronta para um está perto de estar pronta para o outro.

O que tens de ter pronto antes da auditoria?

Tem pronta uma política de desenvolvimento seguro que nomeie os teus agentes, um padrão de codificação segura, um scan em cada alteração atrás de um gate que recusa achados críticos, um registo de exceções com aprovadores e datas de expiração, pull requests testados e aprovados e um relatório do período auditado, tudo em dia quando o auditor escolhe a amostra.

1. A política nomeia os agentes. Que agentes, que contas, que repositórios, e o que o agente não pode fazer sozinho, como fazer merge ou deploy.
2. O padrão é curto e aplicável. Lista o que proíbes e aponta para a verificação que encontra cada ponto. Uma regra que nenhuma verificação consegue encontrar é uma regra que só um revisor consegue impor.
3. Cada alteração passa pelo mesmo scan. Código, dependências, segredos e ficheiros de infraestrutura, em cada pull request, quer o tenha aberto uma pessoa, quer um agente.
4. O gate decide, e fica registado. Um achado crítico bloqueia o merge; um risco mais baixo dá um aviso e segue. Cada exceção tem âmbito, data, justificação e aprovação com nome.
5. A aprovação e os testes ficam junto da alteração. O pull request traz a aprovação, a execução da CI e o resultado do scan, por isso uma alteração escolhida para amostra explica-se sozinha.
6. O relatório cobre o período. Um documento que o auditor consegue ler, construído a partir dos scans e não colado de uma folha de cálculo.

Ticket com requisitosO agente escreve a alteraçãoScan na alteraçãoO gate bloqueia ou avisaAprovada e testadaNo relatório

Os pontos 3, 4 e 6 são o que produz a plataforma AppSec da CybeDefend. Faz o scan de cada repositório à procura de fraquezas no código (SAST), dependências (SCA), segredos, infraestrutura como código (IaC), 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 dá um aviso nos riscos mais baixos, em toda a organização, nas suas equipas e nos respetivos projetos, 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 HTML ou JSON para uma ferramenta de GRC. Se estás a preparar a ISO 27001 ou o SOC 2 com uma equipa que programa com agentes, podemos ver isso contigo. Para o quadro geral do que muda quando os agentes escrevem código, começa pelo nosso guia de segurança dos agentes de IA para programação.

Perguntas frequentes

A ISO 27001 permite usar agentes de IA para programar?

Sim. Nada na ISO/IEC 27001:2022 os proíbe, e nenhum controlo do Anexo A trata de IA. O código que um agente escreve no teu repositório é código teu, por isso os controlos 8.25 a 8.29 e 8.32 aplicam-se-lhe como se aplicam ao código que um programador escreveu à mão. A tua política tem de dizer que agentes estão autorizados e como se verificam as alterações que fazem.

O A.8.28 é obrigatório na ISO 27001?

Para uma empresa que desenvolve software, na prática é. A ISO 27001 deixa-te excluir um controlo do Anexo A, mas a cláusula 6.1.3 d) exige uma justificação na tua Declaração de Aplicabilidade, e excluir a codificação segura quando escreves código é difícil de defender. Um auditor que não encontre princípios de codificação segura no teu processo de desenvolvimento regista uma não conformidade.

O que deve ter uma política de codificação segura para a ISO 27001?

É o documento que fixa os princípios de codificação que os teus programadores e agentes seguem, e a forma como os verificas. A ISO 27001 não o torna obrigatório, mas os auditores esperam encontrar esses princípios em algum lado: numa política de desenvolvimento seguro numa PME, numa política de codificação segura separada numa empresa maior.

Um CLAUDE.md ou um AGENTS.md chega para passar numa auditoria ISO 27001?

Não. Mostra que deste o teu padrão ao agente, não que o código o segue. A Anthropic diz que o Claude trata estes ficheiros como contexto, não como configuração imposta, e no estudo da CybeDefend de 24 de agosto de 2026 um ficheiro de regras realista deixou 2,27 regras violadas por ticket, contra 2,28 sem ficheiro nenhum. O auditor quer registos das verificações que correram em cada alteração.

Tudo o que um agente de IA escreve tem de ser revisto por uma pessoa?

O auditor espera que cada alteração seja aprovada antes de ir para produção: aprovar as alterações ao sistema é um ponto de foco do CC8.1 do SOC 2, e o 8.32 da ISO 27001 trata da gestão de alterações. É a tua política que decide como se aprovam as alterações dos agentes, e o auditor confirma que os pull requests escolhidos para amostra correspondem ao que a política diz.

Preciso da ISO 42001 para usar agentes de IA a programar?

Não. A ISO/IEC 42001:2023 é uma norma à parte, para um sistema de gestão de IA, pensada pela ISO para organizações que fornecem ou usam produtos ou serviços baseados em IA. A ISO 27001 não a exige, e o teu auditor da 27001 avalia a forma como usas os agentes através dos controlos da 27001.

O SOC 2 obriga a fazer scans de vulnerabilidades?

O critério CC7.1 pede deteção e monitorização que identifiquem vulnerabilidades novas, e «Conducts Vulnerability Scans» é um dos seus pontos de foco. Os critérios não nomeiam nenhuma ferramenta. O auditor testa os controlos que descreveste e, num relatório Type II, testa-os ao longo de todo o período.

Como mostro ao auditor que código foi escrito por um agente de IA?

Usa o que os teus agentes escrevem no git. Por predefinição, o Claude Code acrescenta a cada commit um trailer Co-Authored-By que nomeia o modelo, e a definição attribution pode retirá-lo, por isso fixa-a nas managed settings. Uma conta de máquina dedicada, com commits assinados, é mais sólida. A autoria dá ao auditor o âmbito; as provas são os controlos aplicados a cada alteração.