> ## Documentation Index
> Fetch the complete documentation index at: https://zeropath.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Escaneamento de IaC

> Identifique configurações incorretas na sua infraestrutura como código antes do deployment

<h2 id="how-it-works">
  Como Funciona
</h2>

O scanner de Infraestrutura como Código (IaC) do ZeroPath detecta configurações incorretas de segurança nas suas definições de infraestrutura antes que elas sejam implantadas. Ele roda junto com o SAST, o SCA e o escaneamento de segredos, tanto nos escaneamentos completos de repositório quanto nos escaneamentos de PR.

* **Detecção automatizada** analisa seus arquivos de infraestrutura em busca de configurações incorretas que possam expor seus sistemas a ataques — security groups abertos, criptografia ausente, políticas de IAM excessivamente permissivas e mais.
* **Validação aprimorada por IA** revisa cada descoberta em contexto para determinar se o recurso sinalizado está realmente implantado em produção — filtrando configurações incorretas em arquivos de exemplo, fixtures de teste, diretórios de snapshot, templates não renderizados e overrides exclusivos de desenvolvimento. Descobertas confirmadas recebem descrições legíveis por humanos, avaliações de severidade e **precondições** de explorabilidade vinculadas à sua configuração de infraestrutura específica.
* **Descobertas unificadas** — configurações incorretas de IaC aparecem no mesmo fluxo de descobertas do ZeroPath que os seus outros dados de escaneamento, mantendo a remediação em um único fluxo de trabalho.

<h2 id="supported-formats">
  Formatos Suportados
</h2>

O ZeroPath escaneia os seguintes formatos de infraestrutura como código:

| Formato                          | Tipos de Arquivo                                 |
| -------------------------------- | ------------------------------------------------ |
| **Terraform**                    | `.tf`, `.tfvars`                                 |
| **Kubernetes**                   | Manifestos YAML, charts do Helm                  |
| **Docker**                       | `Dockerfile`, `docker-compose.yml`               |
| **CloudFormation**               | Templates JSON e YAML                            |
| **Azure Resource Manager (ARM)** | Templates JSON                                   |
| **Helm**                         | Templates de chart e `values.yaml`               |
| **GitHub Actions**               | Arquivos YAML de workflow (`.github/workflows/`) |

<h2 id="misconfiguration-categories">
  Categorias de Configuração Incorreta
</h2>

<h3 id="network-access-control">
  Rede e Controle de Acesso
</h3>

* Security groups excessivamente permissivos (ex.: ingress `0.0.0.0/0`)
* Network policies ausentes no Kubernetes
* Exposição irrestrita de portas
* Recursos voltados ao público sem controles de acesso

<h3 id="encryption-data-protection">
  Criptografia e Proteção de Dados
</h3>

* Volumes de armazenamento não criptografados (EBS, S3, Azure Blob)
* Configuração TLS/SSL ausente
* Conexões de banco de dados não criptografadas
* Criptografia em repouso ausente em serviços gerenciados

<h3 id="identity-permissions">
  Identidade e Permissões
</h3>

* Políticas de IAM excessivamente amplas (ex.: acesso a recursos com `*`)
* Restrições de privilégio mínimo ausentes
* Acesso root/admin sem exigência de MFA
* Contas de serviço com permissões excessivas

<h3 id="container-security">
  Segurança de Contêineres
</h3>

* Contêineres rodando como root
* Limites de recursos ausentes (CPU, memória)
* Modo de contêiner privilegiado habilitado
* Security contexts ausentes em pods do Kubernetes
* Imagens obtidas sem pinagem por digest

<h3 id="logging-monitoring">
  Logging e Monitoramento
</h3>

* Audit logging desabilitado
* CloudTrail ou equivalente ausente
* Contêineres sem health checks
* Configuração de agregação de logs ausente

<h3 id="ci-cd-pipeline-security">
  Segurança de Pipelines de CI/CD
</h3>

As descobertas de pipeline de CI/CD agora aparecem na sua própria categoria dedicada **CI/CD** no dashboard, separada das descobertas de IaC. Isso facilita filtrar e triar problemas de segurança específicos de pipeline. Cada descoberta de CI/CD é validada contra a configuração real de trigger do workflow para determinar se a fraqueza sinalizada é alcançável — por exemplo, uma descoberta de injeção de script só é confirmada quando o trigger do workflow (como `pull_request_target` ou `issue_comment`) realmente expõe input controlado pelo atacante à expressão vulnerável.

* Configurações inseguras de workflows do GitHub Actions
* Versões de actions não pinadas, vulneráveis a ataques de cadeia de suprimentos
* Permissões de workflow excessivas
* Injeção de script via inputs não confiáveis em expressões de workflow

<h3 id="compliance">
  Conformidade
</h3>

* Recursos sem as tags obrigatórias
* Configurações de armazenamento fora de conformidade
* Configurações de backup e recuperação ausentes

<h2 id="scan-modes">
  Modos de Escaneamento
</h2>

<h3 id="full-repository-scan">
  Escaneamento Completo do Repositório
</h3>

O escaneamento de IaC roda em todos os arquivos de infraestrutura do seu repositório, reportando cada configuração incorreta detectada.

<h3 id="pr-scan">
  Escaneamento de PR
</h3>

Durante o escaneamento de PR, apenas os arquivos de infraestrutura alterados são analisados. Novas configurações incorretas aparecem como comentários inline no PR. As descobertas de IaC identificadas pelo agente de IA durante escaneamentos de PR agora são corretamente categorizadas sob o tipo de descoberta **IaC**, garantindo filtragem e relatórios consistentes tanto em full scans quanto em escaneamentos de PR.

<h2 id="remediation">
  Remediação
</h2>

Cada descoberta de IaC inclui:

* **Descrição** — o que é a configuração incorreta e por que ela importa.
* **Severidade** — classificada usando a mesma pontuação baseada em CVSS das descobertas SAST.
* **Recurso afetado** — o arquivo, o tipo de recurso e o bloco de configuração específicos.
* **Precondições** — fatores do contexto de deployment que afetam se a configuração incorreta é de fato explorável. Exemplos incluem se o recurso está em uma sub-rede privada, se políticas organizacionais sobrescrevem a configuração ou se a configuração é usada apenas em ambientes que não são de produção. Cada precondição cita evidências dos arquivos de configuração quando disponíveis.
* **Orientação de remediação** — recomendações geradas por IA para corrigir a configuração incorreta.

<h2 id="configuration">
  Configuração
</h2>

O escaneamento de IaC é controlado pelas configurações do scanner, com herança em níveis de organização/tag/repositório:

| Configuração                         | Padrão | O Que Controla                                                                   |
| ------------------------------------ | ------ | -------------------------------------------------------------------------------- |
| **IaC scanning enabled (full scan)** | On     | Executar o escaneamento de IaC durante os escaneamentos completos de repositório |
| **IaC scanning enabled (PR scan)**   | On     | Executar o escaneamento de IaC durante os escaneamentos de pull request          |

As descobertas de IaC aparecem junto com as descobertas SAST e as demais no seu dashboard, na API e nas integrações. Todas as configurações incorretas de IaC são categorizadas de forma consistente sob o tipo de descoberta **IaC**, garantindo filtragem e relatórios precisos.