Gestão de Vulnerabilidades

Um relatório de varredura é o início de uma decisão. Ele identifica possíveis fraquezas em ativos específicos; um analista verifica esses achados, situa-os em seu contexto e acompanha o trabalho até que o resultado seja verificado. Esse processo contínuo é a gestão de vulnerabilidades.

Identifique o problema com precisão

Uma vulnerabilidade é uma fraqueza em software, hardware, configurações ou um processo. Uma ameaça é uma pessoa, grupo ou evento que poderia causar danos. Um código ou técnica de exploração aproveita uma fraqueza. O risco combina a probabilidade de dano com seu impacto na confidencialidade, integridade ou disponibilidade. Uma atualização ausente é uma vulnerabilidade; atacantes que a usam para roubar registros são a ameaça que age por meio de uma exploração.

Os achados também incluem senhas padrão, armazenamento público, configurações de criptografia obsoletas e produtos em fim de vida útil que não recebem mais atualizações de segurança. Uma vulnerabilidade de dia zero ainda não tem correção porque o fornecedor não teve tempo de responder. Um ataque de dia zero usa essa falha; a divulgação por si só não comprova que ataques ocorreram. Até que existam verificações e correções, medidas de mitigação e detecção ajudam a proteger os sistemas afetados.

Avance da descoberta ao encerramento

1. Identifique ativos: determine o que existe e quem é responsável por cada ativo.
2. Descubra fraquezas: faça varreduras dos ativos e reúna outros relatos.
3. Analise e valide: verifique se cada achado se aplica.
4. Priorize: combine severidade técnica, evidências de ameaça e contexto de negócio.
5. Trate: elimine a fraqueza, reduza o risco ou obtenha aceitação formal de risco.
6. Verifique e informe: confirme o resultado, registre evidências do encerramento e avalie o trabalho.

Suponha que um scanner sinalize um serviço desatualizado em um portal de funcionários. O analista verifica a compilação instalada e o aviso do fornecedor. O responsável pelo portal explica a função dele no negócio. Um desenvolvedor atualiza o serviço por meio da gestão de mudanças. Uma nova verificação confirma a compilação corrigida e o funcionamento do portal. Se novos servidores continuarem restaurando a compilação antiga, essa evidência leva o programa de volta ao inventário de implantações e aos modelos.

Leia os identificadores

Autoridades de numeração CVE atribuem IDs como CVE-2014-0160, da falha Heartbleed no OpenSSL. O ano faz parte do identificador e não é uma data confiável de descoberta ou correção. Falhas internas e configurações incorretas podem exigir ação mesmo sem um CVE.

Dê uma função clara a cada papel

A equipe de segurança descobre, valida, prioriza e acompanha os achados. Administradores e desenvolvedores aplicam mudanças; responsáveis pelos ativos respondem pelo risco dos sistemas. As autoridades de mudança aprovam alterações em produção, enquanto os responsáveis pelo risco autorizados aprovam exceções. Uma avaliação abrangente de vulnerabilidades, um teste de invasão autorizado que demonstra o impacto e relatos válidos de programas de recompensa por descoberta de falhas alimentam esse mesmo processo de tratamento. Uma varredura sem achados descreve apenas as verificações executadas com sucesso; ativos não identificados e falhas desconhecidas ainda precisam de atenção.

Um inventário informa ao programa o que avaliar e dá significado às medidas de cobertura. Inclua servidores, laptops, equipamentos de rede, aplicações, recursos de nuvem e domínios e certificados voltados à internet. Softwares e bibliotecas são tão importantes quanto máquinas.

Registre a identidade e a importância para o negócio

Cada registro precisa de identificador estável, nome do host, endereços, responsável, equipe de suporte, localização ou conta de nuvem, versões do sistema operacional e dos softwares, função de negócio, classificação dos dados, criticidade, exposição e estado no ciclo de vida. Use um ID de instância na nuvem ou de agente para acompanhar uma máquina quando o endereço mudar. Um endereço IP isolado pode apontar para outro dispositivo após uma mudança na concessão DHCP.

Atribua um nível de criticidade com o responsável. Em um esquema de exemplo, o Nível 1 abrange serviços de pagamento e sistemas de identidade, o Nível 2 abrange serviços internos importantes e o Nível 3 abrange laboratórios de baixo impacto. O nível descreve o dano causado pela perda de confidencialidade, integridade ou disponibilidade. Um sistema difícil de corrigir não se torna menos crítico porque corrigi-lo é inconveniente.

Concilie várias fontes

Um banco de dados de gerenciamento de configuração (CMDB) registra ativos gerenciados, mas a descoberta frequentemente revela recursos que ele não contém. Compare-o com agentes de endpoint, serviços de diretório, DNS e DHCP, registros de compras, observações passivas de rede e APIs de nuvem. Compare registros individuais antes de interpretar diferenças entre totais. Investigue um ativo visto em apenas uma fonte: ele pode ser novo, ter sido retirado de uso, estar duplicado ou ser desconhecido pela área de TI.

A descoberta ativa envia sondagens para encontrar hosts que respondem. Em uma rede autorizada, nmap -sn 10.20.0.0/24 realiza a descoberta de hosts em uma faixa que contém 256 endereços. A identificação por características infere detalhes do dispositivo ou do sistema operacional a partir das respostas; -O do Nmap solicita a detecção do sistema operacional. Trate uma identidade inferida como evidência a ser confirmada. A descoberta passiva observa o tráfego existente e ajuda a encontrar dispositivos frágeis sem sondá-los, embora dispositivos silenciosos possam passar despercebidos.

Calcule a lacuna real

Uma execução de descoberta encontra 212 hosts ativos. O CMDB contém 195 registros, e a comparação host por host confirma que todos os 195 estão no conjunto descoberto. Portanto, há 17 hosts ativos não registrados. Atribua a cada um um responsável e um registro ou remova-o pelo processo adequado.

A varredura de vulnerabilidades verifica 180 desses 212 hosts ativos na mesma semana:

Os 32 hosts não verificados continuam sendo uma lacuna de cobertura. Se alguns hosts do CMDB estivessem ausentes da descoberta, simplesmente subtrair os totais teria ocultado parte da diferença. Mantenha o período e a população consistentes ao comparar a cobertura.

Identifique recursos que surgem e desaparecem

A TI não autorizada ou desconhecida pela área de TI é a tecnologia estabelecida sem o conhecimento da área de TI. Ela pode ficar fora da aplicação normal de correções e das varreduras. Instâncias de nuvem e contêineres podem existir por minutos, portanto uma varredura mensal de rede pode não identificá-los durante toda a sua existência. Alimente o inventário com APIs dos provedores e exija etiquetas úteis para os recursos, incluindo responsável, ambiente e classificação dos dados. Avalie as imagens e os modelos usados para criá-los.

Para uma aplicação, uma lista de materiais de software (SBOM) relaciona os componentes e as bibliotecas dessa aplicação. Quando uma falha em uma biblioteca for divulgada, associe as versões afetadas do componente às aplicações que as contêm. Mantenha o inventário atualizado conforme os recursos são criados, movidos e retirados de uso; uma planilha preenchida uma única vez não consegue descrever um ambiente em mudança por muito tempo.

Uma política útil informa às equipes o que deve acontecer, quem decide e quando o trabalho deve ser concluído. Ela vincula os achados de segurança às prioridades de negócio da organização. A gestão aprova a política, e o programa mede se as pessoas a seguem.

Distinga os termos de risco

Risco inerente é o risco antes dos controles. Risco residual permanece após os controles. Apetite a risco é a quantidade e o tipo de risco que a liderança está disposta a aceitar na busca dos objetivos da organização. Decisões sobre uma exceção usam o risco remanescente, não apenas a pontuação de severidade original.

Um modelo qualitativo simples multiplica a probabilidade pelo impacto, cada um avaliado de 1 a 5:

Um serviço voltado à internet com uma falha de execução remota de código recebe probabilidade 4 e impacto 5, resultando em 20 de 25. Uma regra testada de firewall de aplicação web reduz a probabilidade avaliada para 2, enquanto o impacto permanece em 5, resultando em risco residual 10. Em uma política de exemplo que exige remediação em até 30 dias quando o risco residual ultrapassa 8, o serviço ainda precisa de uma correção em até 30 dias. O controle reduziu o risco sem atingir o limiar de aceitação dessa política.

Essas classificações organizam julgamentos; não são probabilidades medidas. Registre os motivos das classificações de probabilidade e impacto para que uma pessoa que revise o caso posteriormente possa entender a decisão.

Escreva regras mensuráveis

A política define o escopo dos ativos, a frequência das varreduras, as responsabilidades, as regras de severidade e prioridade, os prazos de remediação, as exceções, o escalonamento e a comunicação de resultados. Normas especificam requisitos técnicos, e procedimentos descrevem como as equipes os executam. Governança significa aplicar, avaliar e revisar essas regras.

Um cronograma ilustrativo de SLO é: Crítica 15 dias, Alta 30, Média 90 e Baixa 180. Informe quando a contagem começa. Contratos e requisitos aplicáveis podem definir prazos mais rigorosos. Acrescente regras de exploração e exposição para que uma falha em gateway com exploração conhecida possa acionar trabalho emergencial em vez de esperar o prazo normal de severidade Alta.

Planeje o trabalho que pode ficar parado

Uma correção pode interromper um processo de negócio, prejudicar uma dependência ou exigir certificação do fornecedor. Produtos legados podem não ter correção, enquanto um SLA ou memorando de entendimento pode limitar quando mudanças ocorrem. A política precisa prever caminhos para janelas extras de manutenção, controles compensatórios verificados e exceções com prazo definido. Um prazo não cumprido é encaminhado ao responsável pelo ativo, depois ao gestor dessa pessoa e, em seguida, ao comitê de risco, de acordo com o caminho de escalonamento definido.

Relacione a política a referenciais estabelecidos

O controle 8.8 do Anexo A da ISO/IEC 27001:2022 trata da gestão de vulnerabilidades técnicas. O Controle 7 dos Controles Críticos de Segurança do CIS v8.1 abrange a gestão contínua de vulnerabilidades; os Controles 1 e 2 apoiam os inventários de ativos e de software. O requisito 11.3 do PCI DSS v4.0.1 trata de varreduras de vulnerabilidades no ambiente de cartões de pagamento, e a NIST SP 800-40 Rev. 4 orienta o planejamento corporativo da aplicação de correções. Acompanhe o cumprimento de prazos e os riscos em atraso para que a revisão da política se baseie no desempenho real.

Um tipo de varredura descreve uma parte diferente da avaliação. Local, acesso, implantação e atividade são escolhas independentes: uma varredura interna pode ser autenticada e sem agente, enquanto um agente pode avaliar um laptop fora do escritório. Selecione uma combinação adequada ao ativo e às informações necessárias.

Decida onde e como procurar

Use as perspectivas interna e externa. Uma varredura externa mostra a exposição inicial; a avaliação interna ajuda a encontrar caminhos disponíveis após um comprometimento ou para alguém de dentro da organização. Verificações autenticadas geralmente reduzem falsos positivos e falsos negativos porque inspecionam diretamente as compilações de pacotes e as configurações. Use contas de varredura dedicadas com os menores privilégios que ainda permitam uma avaliação completa. Armazene as credenciais no cofre do scanner, monitore-as e faça sua rotação.

Ajuste a implantação ao ativo

Agentes enviam informações coletadas localmente a um console. Eles são adequados para laptops que raramente se conectam à rede corporativa e para hosts de nuvem compatíveis. Implantar, atualizar e monitorar os agentes continua sendo parte do programa.

Varreduras de rede sem agente não precisam de software instalado e são adequadas para dispositivos como impressoras e switches. Elas precisam de acesso pela rede e, para obter evidências locais, de credenciais. Algumas ferramentas de nuvem também avaliam instantâneos de disco por meio das APIs dos provedores, sem agentes nos hosts. Verifique o acesso realmente obtido, não apenas a classificação escolhida para a varredura.

Distinga atividade e finalidade

Varreduras ativas enviam sondagens e analisam as respostas. A avaliação passiva observa o tráfego existente por uma porta de espelhamento ou um dispositivo de cópia passiva de tráfego de rede. A observação passiva evita a carga das sondagens em sistemas frágeis, mas deixa de identificar serviços que permanecem silenciosos durante o período de observação.

Uma varredura de descoberta mapeia hosts, portas, serviços e prováveis sistemas operacionais. Uma varredura de vulnerabilidades verifica fraquezas conhecidas. Uma varredura de conformidade com a linha de base compara configurações com um requisito, como um CIS Benchmark ou um padrão interno de fortalecimento. Por exemplo, ela pode informar que o comprimento mínimo da senha é 8, enquanto a linha de base aprovada exige 14. Encontrar uma porta aberta, por si só, não comprova uma vulnerabilidade.

Para software, a análise estática inspeciona código-fonte ou binários sem executá-los. A análise dinâmica observa um programa em execução. Varreduras web e testes com entradas malformadas ou variadas são dinâmicos; esses testes fornecem entradas malformadas ou aleatórias e procuram problemas como falhas de execução. A engenharia reversa estática pode usar um desmontador para examinar código compilado.

Aplique as escolhas

Um site público precisa de uma visão externa da rede e de testes web autenticados das funções disponíveis aos usuários. Laptops frequentemente fora das instalações são adequados para agentes. Servidores Linux em centros de dados são adequados para verificações internas autenticadas. Para controladores de fábrica, comece com monitoramento passivo e coordene com a engenharia quaisquer verificações ativas testadas. O relatório mais curto pode simplesmente resultar de menor visibilidade: compare o alcance e a autenticação antes de interpretar o tamanho do relatório como uma boa notícia.

Um plano de varredura deve produzir evidências úteis sem interromper os sistemas avaliados. Escopo, horários, acesso e limites de carga de trabalho devem constar no plano antes da execução do scanner. Teste apenas sistemas e contas cobertos por autorização por escrito e siga as regras de teste do provedor de hospedagem.

Defina o escopo e os limites operacionais

Registre faixas de endereços, nomes de hosts, contas de nuvem, aplicações, contatos, janelas aprovadas e verificações perigosas excluídas. Coordene com os operadores dos sistemas e com a equipe de operações de segurança para que os alertas da varredura sejam esperados. Restrinja o acesso ao scanner e aos relatórios: eles contêm credenciais e um mapa detalhado das fraquezas.

Atualize a fonte de atualizações de vulnerabilidades ou os plug-ins antes de cada execução. Limite os alvos e as verificações simultâneos para evitar a sobrecarga de conexões ou CPUs. Credenciais incorretas podem bloquear contas, sondagens enchem registros de eventos e acionam defesas, e verificações intrusivas podem causar falhas em serviços frágeis. Use perfis seguros para produção, desative verificações de negação de serviço e distribua o trabalho intenso fora dos períodos de pico.

A profundidade da varredura é uma escolha. Um perfil de descoberta tem menor impacto operacional do que um perfil profundo e intrusivo, mas também responde a menos perguntas. Teste um novo perfil em sistemas representativos antes de ampliar seu alcance. A frequência deve refletir as mudanças e a exposição: a varredura interna mensal é uma escolha mínima comum para programas, enquanto avaliações semanais ou contínuas fornecem evidências mais recentes. Mudanças significativas e avisos urgentes podem exigir execuções extras.

Alcance cada segmento de rede

Um scanner central atrás de um firewall pode alcançar quase nada de uma sub-rede isolada. Posicione scanners distribuídos ou agentes nos segmentos relevantes, ou use acesso de varredura com escopo restrito e prazo limitado. Preserve a segmentação fora do necessário para o acesso aprovado. Verifique o alcance dos hosts e o sucesso da autenticação após a execução para que sondagens bloqueadas não produzam resultados aparentemente sem achados.

Aplique os requisitos de varredura para cartões de pagamento

Para o ambiente de dados de titulares de cartão, o PCI DSS v4.0.1 exige varreduras internas pelo menos uma vez a cada três meses. Achados críticos e de alto risco, conforme classificados pela entidade, devem ser resolvidos e verificados por novas varreduras; a ferramenta de varredura deve usar informações atuais sobre vulnerabilidades. Varreduras internas também são realizadas após mudanças significativas.

A varredura interna autenticada prevista no requisito 11.3.1.2 é obrigatória desde 31 de março de 2025. Use privilégios de varredura suficientes; documente os sistemas que não podem aceitar credenciais. O requisito de varredura autenticada não se aplica às varreduras separadas após mudanças significativas previstas em 11.3.1.3. Varreduras externas ocorrem pelo menos uma vez a cada três meses por meio de um fornecedor de varredura aprovado pelo PCI SSC (ASV), com novas varreduras conforme necessário para alcançar resultados aprovados. Mudanças significativas também exigem avaliação externa segundo a disposição separada da norma sobre varreduras após mudanças.

Proteja processos físicos

A tecnologia operacional (OT) inclui sistemas que controlam equipamentos físicos. Sistemas de controle industrial (ICS) e sistemas SCADA, de controle supervisório e aquisição de dados, frequentemente priorizam a segurança física e a disponibilidade em vez da profundidade da varredura. Controladores antigos podem reagir mal a pacotes desconhecidos. Prefira monitoramento passivo e ferramentas aprovadas pelo fornecedor; teste em uma réplica e obtenha aprovação da engenharia para trabalho ativo durante paradas planejadas.

Um plano de exemplo varre 10.20.0.0/24 com credenciais aos sábados das 01:00 às 05:00, limita a execução simultânea a 10 hosts, atualiza as fontes na sexta-feira e exporta achados para chamados. Ele acrescenta varredura externa semanal e monitoramento passivo da fábrica. Os contatos dos operadores e as condições de parada tornam o plano utilizável quando o desempenho muda durante uma execução.

Comece pela pergunta e depois selecione a ferramenta. Mapear uma faixa de endereços, avaliar uma dependência e verificar se uma defesa detecta um ataque são tarefas diferentes. O resultado de uma ferramenta precisa de validação mesmo quando o nome do produto é familiar.

Encontre hosts, serviços e fraquezas conhecidas

O Nmap mapeia portas e serviços; -sV solicita a detecção de versão de serviço, -O solicita a detecção do sistema operacional, e o mecanismo de scripts do Nmap permite verificações adicionais. O Angry IP Scanner oferece descoberta simples de hosts e portas. O Masscan varre rapidamente grandes faixas de endereços em busca de portas abertas, com poucos detalhes sobre os serviços.

O Nessus usa verificações de plug-ins para avaliar vulnerabilidades conhecidas. O OpenVAS da Greenbone relata fraquezas com uma classificação de qualidade da detecção. O Nuclei executa modelos YAML para verificações direcionadas, incluindo verificações de serviços web e CVEs. A seleção de modelos importa porque as verificações diferem em finalidade e impacto operacional.

Avalie o comportamento web

Um scanner de rede pode encontrar um servidor web e problemas conhecidos em componentes, enquanto testes web autenticados examinam o comportamento da aplicação. Problemas de lógica de negócio ainda precisam de validação cuidadosa do fluxo de trabalho real.

Inspecione recursos de nuvem e artefatos de software

Prowler e ScoutSuite consultam configurações de nuvem por APIs e relatam problemas de postura. O Checkov analisa infraestrutura como código, como definições do Terraform ou Kubernetes. O Trivy avalia artefatos, incluindo imagens de contêiner e repositórios, em busca de componentes vulneráveis, configurações incorretas e segredos expostos, e pode gerar SBOMs.

Por exemplo, uma porta de gerenciamento aberta em uma regra do Terraform pede o uso de Checkov ou Trivy antes da implantação. Um bucket público de armazenamento já implantado pede uma avaliação da postura de segurança na nuvem. Uma biblioteca incluída em um contêiner pede uma varredura da imagem ou análise de composição. Esses achados podem ter o mesmo responsável, mas precisam de evidências diferentes.

Reconheça funções de teste especializadas

O Maltego cria grafos de relações a partir de dados de fontes abertas usando transforms; o Recon-ng organiza o reconhecimento modular. Ambos apoiam a descoberta da superfície de ataque externa. O Metasploit Framework inclui módulos de exploração e de avaliação auxiliar; o Pacu se concentra em testes de ataque na AWS. Testes especializados autorizados podem confirmar a explorabilidade, enquanto os analistas que atuam na rotina ainda precisam de evidências e de um registro de tratamento.

O GDB e o Immunity Debugger inspecionam programas em execução, memória e registradores. Eles ajudam a explicar falhas de execução encontradas por testes com entradas malformadas ou variadas. O Atomic Red Team fornece pequenos testes mapeados para o MITRE ATT&CK, e o Caldera do MITRE automatiza a emulação de adversários. Essas ferramentas de simulação de violações e ataques testam se os controles detectam ou bloqueiam técnicas. Um teste de detecção bem-sucedido informa algo sobre aquele controle; ele não comprova que os pacotes instalados estão atualizados.

A severidade ajuda a ordenar um relatório, mas a evidência explica por que o scanner gerou um achado. Leia o ativo afetado e a versão, configuração ou resposta detectada antes de atribuir o trabalho. Um chamado útil deve dar ao responsável detalhes suficientes para reproduzir e corrigir o problema.

Leia o achado como um registro

Procure o título, o ID do plug-in ou da verificação, as referências CVE, a severidade, a versão e o vetor CVSS, o ativo, a porta, o protocolo, o serviço, a evidência de detecção, a solução recomendada e as datas da primeira e da última observação. Um ID de plug-in identifica a verificação do scanner; ele não é intercambiável com um ID CVE.

Para um problema web, inspecione a URL, o parâmetro, a requisição, a resposta e a confiança. Um relatório como “Execução refletida de scripts entre sites no parâmetro q de /search” identifica uma entrada da aplicação a investigar. Um resultado de nuvem precisa da conta, da região, do ID do recurso, do ID da verificação e de APROVADO ou REPROVADO, para que o responsável pelo recurso correto possa agir.

Interprete os estados de porta com precisão

Considere estes resultados de detecção de serviço:

22/tcp   open     ssh    OpenSSH 7.4
80/tcp   open     http   Apache httpd 2.4.6 ((CentOS))
443/tcp  closed   https
3306/tcp filtered mysql

SSH e HTTP estão expostos a esse scanner. Nessa observação, nada aguarda conexões na porta 443. A situação da porta 3306 continua incerta porque um filtro bloqueia a evidência necessária. Os banners sugerem um ambiente CentOS mais antigo; confirme o sistema operacional e a situação do suporte com dados autenticados antes de registrar um achado de fim de vida útil. O CentOS Linux 7 chegou ao fim da vida útil em 30 de junho de 2024; eventuais acordos de suporte estendido também precisam ser verificados.

Use a confiança para planejar a validação

A Qualidade da detecção (QoD) da Greenbone classifica a evidência por trás de um resultado. Exemplos incluem 97% para verificações autenticadas de pacotes, 80% para banners que informam o nível de correção e 30% para banners que não o informam. Por padrão, os relatórios geralmente ocultam resultados abaixo de 70%. O Burp classifica a confiança como certa, confiável ou provisória. Um achado grave com evidência fraca precisa de validação rápida; confiança e severidade respondem a perguntas diferentes.

Transforme linhas repetidas em trabalho útil

Uma atualização de fornecedor pode corrigir muitos CVEs. Se 900 de 1.240 linhas de achados forem resolvidas por cinco atualizações, agrupe os chamados por atualização, responsável e lista de hosts afetados. Mantenha os vínculos com os achados individuais para que a validação possa confirmar cada ocorrência afetada.

Compare varreduras usando estados como novo, corrigido, reaberto e persistente. Antes de aceitar uma grande queda nos achados, compare hosts alcançáveis, autenticações bem-sucedidas e duração da varredura. Uma rotação de senha que impeça a autenticação do scanner pode remover achados locais do relatório sem eliminar nenhuma fraqueza. Resultados informativos também podem revelar serviços desconhecidos ou certificados prestes a vencer, portanto mantenha-os na revisão.

Um resultado positivo e uma vulnerabilidade real são coisas diferentes. A validação verifica se o achado se aplica ao ativo. A revisão do estado da varredura também ajuda a encontrar fraquezas que o scanner não relatou.

Classifique os quatro resultados

Falsos negativos deixam fraquezas reais fora da fila de trabalho. Causas comuns incluem falha de autenticação, sondagens bloqueadas, hosts desligados, lacunas no escopo, fontes de atualização antigas, software personalizado não reconhecido e falhas sem uma verificação disponível. Confira o inventário, a cobertura da varredura, os registros de autenticação e fontes independentes quando um relatório apresentar inesperadamente poucos achados.

Valide da evidência à conclusão

1. Leia a evidência da verificação e a condição apontada como vulnerável.
2. Obtenha a compilação real do pacote ou a configuração por acesso autenticado.
3. Compare-a com o aviso pertinente do fornecedor e a compilação corrigida.
4. Verifique se o recurso afetado e as condições estão presentes.
5. Correlacione evidências de agentes ou endpoints e registre a conclusão.

Um banner pode estar desatualizado ou incompleto, e um proxy pode responder por outra máquina. Uma identificação incorreta do sistema operacional pode levar a verificações do produto errado. A confirmação manual, quando necessária, deve ocorrer em testes autorizados com um plano operacional adequado.

Reconheça uma correção aplicada a uma versão anterior

Uma distribuição pode corrigir uma linha antiga de software preservando o número de versão do projeto original. Isso é uma aplicação de correção a uma versão anterior. Suponha que um banner mostre OpenSSH_7.4, enquanto a correção no projeto original apareceu na versão 7.7. Essa comparação, por si só, não identifica correções específicas da distribuição.

Em uma distribuição ilustrativa, uma verificação autenticada retorna a compilação do pacote openssh-7.4p1-23, e o aviso do fornecedor lista openssh-7.4p1-21 como a compilação corrigida para a mesma versão com suporte. A compilação 23 contém a correção aplicada à versão anterior, portanto o achado específico do CVE é falso. Se evidências autenticadas também confirmarem um sistema operacional sem suporte, o achado de fim de vida útil continua sendo real. Encerrar uma afirmação não encerra todos os riscos no host.

Restrinja a supressão e revise

Para um falso positivo confirmado, registre a verificação, o ativo, o motivo, as evidências de apoio e a data de revisão. Limite a supressão àquela verificação específica naquele ativo específico. Uma desativação global poderia ocultar achados reais em outros lugares, e uma mudança posterior de configuração poderia invalidar a conclusão anterior.

Uma afirmação como “já aplicamos a correção” precisa ser verificada: uma reinicialização pode estar pendente ou uma segunda cópia instalada pode permanecer. Verifique a versão ou configuração efetiva em vez de aceitar uma ação de manutenção lembrada.

Use o denominador correto

Se 6 de 50 achados relatados forem falsos, 12% da amostra relatada são falsos. A taxa estatística de falsos positivos, por sua vez, divide os falsos positivos por todos os casos realmente negativos:

A amostra de relatos positivos não fornece uma contagem de verdadeiros negativos, portanto não permite determinar essa taxa. Informe exatamente o que uma métrica mede; melhorar credenciais, escopo, fontes de atualização e posicionamento dos scanners melhora as evidências por trás dos resultados positivos e negativos.

O Sistema comum de pontuação de vulnerabilidades (CVSS) descreve a severidade técnica em uma escala de 0,0 a 10,0. Registre a fonte, a versão e o vetor da pontuação para que seu significado fique claro. O FIRST mantém o CVSS; a prioridade para o negócio ainda precisa considerar exposição, evidências de exploração e contexto do ativo.

Decifre a explorabilidade e o impacto

Uma fuga de máquina virtual pode atravessar a autoridade de segurança do sistema convidado e alcançar o hipervisor. A execução de scripts entre sites pode afetar a autoridade do navegador da vítima. Escopo não significa o número de máquinas na varredura.

O vetor da Heartbleed é CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. Ele descreve alcance pela rede, baixa complexidade, nenhum privilégio ou interação necessários, escopo inalterado e alto impacto na confidencialidade. A pontuação base é 7,5. AV:N descreve o método de acesso à falha; ele não informa se um servidor específico seu está voltado à internet.

Use os pesos para escopo inalterado

Os pesos de AV são N 0,85, A 0,62, L 0,55, P 0,20. AC é L 0,77 ou H 0,44; UI é N 0,85 ou R 0,62. PR é N 0,85, L 0,62 ou H 0,27 para escopo inalterado; o escopo alterado usa 0,68 para L e 0,50 para H. Cada peso de impacto é Alto 0,56, Baixo 0,22 ou Nenhum 0.

Quando o impacto é positivo, limite a soma a 10 e arredonde para cima até uma casa decimal. Impacto zero resulta em pontuação base zero. Para AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, ISS é 0,914816, o impacto é aproximadamente 5,8731 e a explorabilidade é aproximadamente 3,8870. A soma é aproximadamente 9,7602, portanto a pontuação base é 9,8.

O escopo alterado usa uma expressão de impacto diferente e um multiplicador de pontuação base de 1,08:

Use a calculadora específica da versão para aplicar essas regras sem misturar fórmulas.

Interprete o resultado

As faixas de severidade são Nenhuma 0,0, Baixa 0,1–3,9, Média 4,0–6,9, Alta 7,0–8,9 e Crítica 9,0–10,0. Exigir privilégios baixos muda o exemplo de escopo inalterado de 9,8 para 8,8; acrescentar acesso local resulta em 7,8; mudar apenas a complexidade do ataque para Alta resulta em 8,1. Esses valores descrevem diferenças técnicas, não probabilidades de exploração. Se duas fontes divergirem, compare os vetores e os julgamentos das fontes antes de escolher uma pontuação para registrar.

Uma pontuação base descreve as características técnicas da falha. As informações sobre ameaças mudam com o tempo, e a mesma falha pode ter importância diferente em duas implantações. O CVSS oferece grupos de métricas separados para esses ajustes, com regras diferentes nas versões 3.1 e 4.0.

Ajuste o v3.1 ao momento atual

O grupo Temporal do v3.1 contém Maturidade do código de exploração, Nível de remediação e Confiança no relato. Seus multiplicadores são:

Não definido conta como 1. Multiplique a pontuação base pelos três valores e arredonde para cima até uma casa decimal. Para uma pontuação base de 9,8 com E:U, RL:O, RC:C:

Se a maturidade da exploração passar a Alta enquanto a correção oficial continuar disponível, o produto será 9,31, arredondado para cima para 9,4. Ajustes temporais podem reduzir a pontuação base ou mantê-la inalterada; seus multiplicadores não podem elevá-la acima da base.

Descreva o ambiente local

As métricas Ambientais do v3.1 incluem requisitos de confidencialidade, integridade e disponibilidade (CR, IR, AR), além de métricas base modificadas como MAV e MPR. Os pesos dos requisitos são Alto 1,5, Médio 1,0, Baixo 0,5 e Não definido 1,0. Documente as evidências da implantação para cada ajuste.

No exemplo da Heartbleed, o requisito de confidencialidade Alto resulta em uma pontuação ambiental de 9,3, enquanto Baixo resulta em 5,7. Uma falha com pontuação base 9,8 e Vetor de ataque modificado para Adjacente resulta em 8,8. Use a calculadora ambiental completa; o cálculo não consiste em multiplicar a pontuação base pelo peso de um requisito.

Interprete as mudanças no CVSS 4.0

A versão 4.0 acrescenta Requisitos do ataque (AT) para condições de implantação ou execução, como uma condição de corrida. A Interação do usuário passa a ser Nenhuma, Passiva ou Ativa. O Escopo é substituído por impactos separados de confidencialidade, integridade e disponibilidade no sistema vulnerável (VC, VI, VA) e em sistemas subsequentes (SC, SI, SA).

Os grupos são Base, Ameaça, Ambiental e Suplementar. A Maturidade da exploração no grupo de Ameaça pode ser Atacada, Prova de conceito, Não relatada ou Não definida; Não definida é pontuada como Atacada. Os requisitos Ambientais assumem Alto quando Não definidos, e as métricas modificadas de integridade e disponibilidade do sistema subsequente podem indicar impactos na segurança física. Os campos Suplementares, incluindo Segurança física, Automatizável, Recuperação, Densidade de valor, Esforço de resposta e Urgência do provedor, acrescentam contexto sem alterar a pontuação.

Mantenha as identificações junto às pontuações

Use CVSS-B, CVSS-BT, CVSS-BE ou CVSS-BTE para mostrar os grupos de pontuação usados. A versão 4.0 usa pontuação baseada em tabelas de consulta, portanto use a calculadora do FIRST. No exemplo do FIRST, a Heartbleed recebe 8,7 como CVSS-BT, em comparação com 7,5 no v3.1; o exemplo de XSS refletida no Zimbra recebe 5,1 no v4.0 e 6,1 no v3.1. Uma mudança de versão pode alterar o número sem alterar o software ou sua implantação.

A severidade descreve o dano potencial em determinadas condições técnicas. Evidências de exploração informam se atacantes estão usando uma falha ou se provavelmente a usarão em breve. Esses sinais complementam o CVSS e o contexto de negócio; nenhuma lista isolada descreve todas as vulnerabilidades.

Separe evidência de previsão

A Agência de Segurança Cibernética e de Infraestrutura dos Estados Unidos (CISA) mantém o Catálogo de vulnerabilidades comprovadamente exploradas (KEV). A inclusão exige um CVE atribuído, evidências confiáveis de exploração em ambientes reais e orientação clara de remediação. Os registros também identificam o uso conhecido em ransomware. A ausência do KEV deixa em aberto a situação da exploração; novos ataques ou fraquezas sem CVE podem não aparecer nele.

O Sistema de pontuação de previsão de exploração (EPSS) do FIRST estima a probabilidade de atividade de exploração observada para um CVE publicado nos próximos 30 dias. As pontuações vão de 0 a 1 e são atualizadas diariamente. O percentil indica a posição relativa entre os CVEs pontuados.

Em um registro diário ilustrativo, EPSS 0,10 e percentil 0,88 significam uma chance estimada de 10% de atividade de exploração e uma pontuação igual ou superior à de 88% dos CVEs pontuados. O percentil não é uma probabilidade de exploração de 88%, e a pontuação não é a chance de seu próprio servidor ser comprometido.

Avalie a força do sinal

Uma prova de conceito publicada mostra que existe uma abordagem de exploração. A preparação de recursos de ataque transforma uma abordagem em ferramentas confiáveis e utilizáveis. A exploração confirmada em ambientes reais, incluindo o uso em ransomware, é uma evidência mais forte de que é preciso agir agora. Acompanhe avisos de fornecedores, inteligência de ameaças, centros de compartilhamento e análise de informações e atualizações de catálogos. Uma pontuação EPSS baixa pode mudar quando surgem novas informações.

Suponha que o achado A tenha CVSS 9,8, EPSS 0,004 e esteja ausente do KEV em um servidor interno de teste. O achado B tem CVSS 7,5, EPSS 0,94 e consta no KEV em um gateway de VPN voltado à internet. Priorize B: ataques confirmados, acesso direto e uma função crítica de acesso se combinam. Programe A de acordo com a política em vez de retirá-lo da fila.

Use árvores de decisão para agir

A Categorização de vulnerabilidades específica para as partes interessadas (SSVC) vem do Instituto de Engenharia de Software da Universidade Carnegie Mellon. A árvore da CISA considera exploração, impacto técnico, possibilidade de automatização, prevalência na missão e impacto no bem-estar público. Suas decisões são Acompanhar, Acompanhar, Dar atenção e Agir*, avançando do acompanhamento normal para uma ação coordenada e urgente. Aplique a árvore real; conhecer uma entrada não basta para inventar o resultado.

A Diretiva Operacional Obrigatória 26-04 da CISA, emitida em 10 de junho de 2026, substituiu a BOD 22-01. Ela obriga as agências civis do Poder Executivo federal quanto aos sistemas no escopo e baseia os prazos na exposição pública, na presença no KEV, na automatização da exploração e no controle técnico parcial ou total. Outras organizações podem usar o KEV voluntariamente. A transição da diretiva exige que as agências comecem a aplicar os novos prazos de avaliação e remediação até 7 de dezembro de 2026.

Responda quando não houver correção

Para uma vulnerabilidade de dia zero, aplique as medidas de mitigação do fornecedor, restrinja o serviço afetado e intensifique a detecção e o monitoramento. Quando uma correção estiver disponível, priorize-a usando severidade, exposição e evidências de exploração. Se ataques forem relatados, faça o escalonamento rapidamente e investigue um possível comprometimento pelo processo de resposta a incidentes. O EPSS abrange CVEs; avalie falhas em código desenvolvido internamente e configurações incorretas com base nas evidências próprias desses casos.

Uma prioridade informa ao responsável com que rapidez agir e por quê. Comece com um achado validado e combine severidade técnica, evidências de exploração, alcance, valor do ativo, controles existentes e disponibilidade de tratamento. Uma pontuação isolada não consegue descrever as consequências de uma falha para o negócio.

Avalie o ativo e o caminho de ataque

Ativos externos podem ser alcançados pela internet. Ativos internos podem ser alcançados depois que um atacante entra na rede ou por alguém de dentro da organização. Ativos isolados têm menos caminhos de acesso, mas dispositivos de manutenção e conexões de suporte ainda podem atravessar essa separação.

O valor do ativo inclui o nível de criticidade, a classificação dos dados, o escopo regulatório e as dependências. Um provedor de identidade pode armazenar poucos dados de clientes diretamente, mas controlar o acesso a muitos outros sistemas. Analise os efeitos sobre os serviços que dependem do ativo vulnerável, não apenas sobre o próprio host.

Considere o efeito de um controle compensatório somente quando ele bloquear o caminho relevante e tiver sido testado. Um firewall de aplicação web em modo somente de detecção registra ataques, mas não os impede. Uma regra de segmentação que ainda permite o acesso ao serviço vulnerável a partir das redes de usuários deixa esse caminho aberto.

Aplique uma política em ordem

Considere esta política de exemplo, aplicada a partir de P1:

F1 é uma falha de pontuação 9,8 em uma máquina virtual isolada de laboratório, sem exploração conhecida, com EPSS 0,02. Ela não atende a P1 nem a P2, portanto é P3. F2 é uma falha de pontuação 7,5 em um servidor web externo e consta no KEV: P1. F3 é uma falha de injeção de pontuação 6,5 em um portal externo de Nível 1, com prova de conceito pública e EPSS 0,20: P2 pelo limiar do EPSS. F4 tem pontuação 8,8 em um servidor interno de arquivos, com EPSS 0,15 e correção disponível: também é P2 pelo EPSS.

Trate F2 primeiro. Dentro de P2, a exposição externa de F3 a clientes coloca F3 à frente de F4 neste exemplo. F1 continua programado. Uma ordenação numérica pelo CVSS teria selecionado primeiro a falha de baixa exposição no laboratório e atrasado o tratamento de um serviço público com exploração conhecida.

Escolha uma ação disponível

Uma correção permite programar a remediação. Se não houver correção, reduza a exposição e monitore enquanto acompanha a correção pendente. Produtos em fim de vida útil precisam de planejamento de substituição e proteção temporária. A falta de uma correção muda o tratamento; ela não elimina a prioridade.

Considere combinações no mesmo ativo. Um vazamento de informações que expõe nomes de usuário, controles fracos de entrada e um plug-in antigo podem formar um caminho mais grave do que qualquer linha analisada isoladamente. Analise os achados relacionados em conjunto antes de definir a ordem de trabalho.

Explique a decisão no chamado

Inclua a identidade do ativo, o responsável, a evidência do achado, o tratamento recomendado, a prioridade, o prazo e o motivo. Por exemplo: “P1: a falha confirmada tem exploração conhecida e o portal está voltado à internet; conclua a remediação dentro da janela de 3 dias da política de exemplo”. Mantenha a justificativa junto ao trabalho quando ele for agrupado entre hosts. Um provável falso positivo passa por validação rápida antes de servir de base para uma decisão definitiva de tratamento.

Um tratamento altera a fraqueza, a exposição ou a decisão de negócio sobre o risco. Escolha o tratamento que atenda ao achado real e planeje quem o implementará e como seu efeito será verificado. A remediação é a opção padrão quando viável.

Distinga as opções de tratamento

Um controle compensatório atende ao propósito de um controle exigido quando esse controle não pode ser aplicado. Ele deve tratar o mesmo risco, ser documentado e verificado. Uma lista de conexões permitidas na segmentação pode proteger um serviço legado que não pode ser corrigido; uma regra de firewall de aplicação web pode oferecer aplicação de correção virtual contra um padrão de exploração conhecido. A detecção por si só ainda deixa o caminho de ataque aberto.

Classifique controles de duas formas

O tipo de controle descreve a implementação: controles administrativos ou gerenciais incluem políticas e decisões de risco; controles operacionais são processos humanos diários, como gestão de mudanças; controles técnicos incluem MFA e firewalls; controles físicos incluem fechaduras e leitores de crachá.

A função do controle descreve a tarefa: controles preventivos impedem eventos, controles detectivos os identificam, controles corretivos eliminam fraquezas ou reparam danos e controles de resposta contêm um incidente enquanto ele ocorre. Uma varredura de vulnerabilidades é detectiva. Uma correção é corretiva. O isolamento automatizado de endpoint pode ser uma resposta. Uma medida pode cumprir mais de uma função; tipo e função são classificações separadas.

Planeje a mudança como uma sequência

1. Teste a atualização ou configuração em um ambiente semelhante ao de produção.
2. Implemente por meio de uma mudança e uma janela de manutenção aprovadas.
3. Prepare evidências e etapas de reversão, como uma cópia de segurança ou instantâneo, antes de alterar a produção.
4. Valide se o serviço funciona e se a fraqueza original foi eliminada.

Uma falha explorada ativamente pode precisar de aprovação de mudança emergencial. Uma janela trimestral de manutenção não pode substituir silenciosamente um prazo de 15 dias da política. Negocie uma janela extra, use atualizações graduais quando a redundância permitir ou obtenha uma exceção com prazo definido e controles verificados.

Trate uma atualização impedida

Um módulo web tem uma falha crítica de execução remota de código. A correção está disponível, mas a certificação da aplicação levará três semanas e o prazo é de 15 dias. Desative o módulo se ele não for usado. Caso contrário, teste uma correção virtual, restrinja o acesso às redes necessárias dos parceiros e intensifique o monitoramento. Registre o risco remanescente e obtenha a exceção necessária; depois, instale a atualização certificada e faça uma nova varredura.

Reduza também a superfície de ataque: descubra ativos externos por varredura de borda, DNS e registros de certificados; remova serviços não usados e sistemas retirados de uso. Testes de controles de segurança, testes de invasão, emulação de adversários e relatos de programas de recompensa por descoberta de falhas podem revelar caminhos que precisam de atenção. Remover um componente desnecessário impede o acúmulo de achados futuros nesse componente.

Alguns achados reais não podem ser corrigidos dentro do prazo da política. Uma exceção torna visível o risco resultante e atribui a decisão a um responsável autorizado. É uma decisão controlada com data de término, não uma forma de remover trabalho difícil do painel de indicadores.

Escolha a estratégia de risco

A aceitação mantém o risco conscientemente quando o negócio precisa da atividade ou quando os custos do tratamento superam o benefício esperado. A mitigação reduz a probabilidade ou o impacto. A evitação encerra a atividade arriscada. A transferência transfere algumas consequências financeiras por contrato ou seguro, enquanto a responsabilidade permanece com a organização.

Um contrato ou uma apólice de seguro não impede que uma exploração alcance um serviço sem correção. Analise o escopo do contrato ou da apólice separadamente dos controles técnicos. Uma exceção negada ainda deixa uma decisão a tomar: fortalecer os controles, remediar ou interromper a atividade.

Escreva o registro da exceção

Registre o ativo e o achado específicos, a justificativa de negócio, a análise de risco, os controles compensatórios, o risco residual, o aprovador autorizado, a data de vencimento e os gatilhos de revisão antecipada. Vincule o registro ao trabalho de remediação para que a correção permanente pretendida continue visível.

Um falso positivo significa que a fraqueza relatada está ausente e é encerrado com evidências. Uma exceção significa que a fraqueza é real e que seu risco residual é mantido temporariamente. Suprimir um achado verdadeiro como falso apagaria justamente o risco que a gestão precisa aprovar.

Ajuste a aprovação ao risco remanescente

O responsável pelo risco aprova em um nível adequado ao risco residual. Uma exceção de baixo risco pode estar dentro da autoridade de um responsável pelo ativo, enquanto um risco residual alto pode exigir a alta liderança ou o diretor de segurança da informação. O administrador que solicita o adiamento do trabalho não aprova essa solicitação sozinho. A equipe de segurança avalia as evidências e recomenda controles.

Compare o risco remanescente com o apetite a risco da organização. Uma decisão além da autoridade delegada deve ser encaminhada a um nível superior ou recusada. O fato de um sistema ser difícil de substituir explica a solicitação; não comprova que seu risco seja aceitável.

Acompanhe um caso de sistema legado

Um instrumento de laboratório usa um controlador com Windows 7 cujo software do fornecedor não funciona em um sistema mais recente. O suporte padrão terminou em 14 de janeiro de 2020, e a substituição está prevista no orçamento do próximo ano. A equipe registra o controlador sem suporte como um achado real e propõe uma rede isolada, armazenamento USB desativado, lista de aplicações permitidas e monitoramento adicional.

O chefe do departamento e a liderança de segurança revisam o risco residual avaliado. A exceção vence após seis meses ou quando a substituição for instalada, o que ocorrer primeiro. O projeto de substituição continua tendo um responsável e marcos, embora a data de revisão da exceção seja anterior à conclusão prevista do projeto.

Reabra quando as condições mudarem

Um novo código de exploração, uma entrada no KEV, a falha de um controle compensatório ou uma mudança de exposição podem invalidar a avaliação anterior antes do vencimento. Revise o risco nesse momento, não apenas na data prevista. Acompanhe o número e o tempo em aberto das exceções, os vencimentos próximos e as correções permanentes pendentes. Evite exceções abrangentes para ambientes inteiros: ativos diferentes podem ter caminhos de ataque, responsáveis e consequências diferentes.

Uma atualização instalada é uma ação; a remediação verificada é um resultado. Encerre um achado somente quando as evidências mostrarem que a fraqueza original foi eliminada e que o serviço ainda funciona. Acompanhe o tempo e a cobertura por trás dessas evidências para que os gestores vejam onde o risco permanece.

Verifique a condição original

Faça uma nova varredura dos ativos afetados com o mesmo tipo de varredura pertinente e credenciais funcionais, ou inspecione diretamente a compilação efetiva do pacote ou a configuração. Confirme que a verificação foi executada com sucesso. Uma falha de autenticação não comprova que uma vulnerabilidade local foi corrigida. Valide também os controles compensatórios: teste se a nova regra de acesso ou correção virtual realmente bloqueia o caminho relevante.

Uma correção pode falhar porque uma reinicialização está pendente, apenas um nó do cluster foi atualizado, uma aplicação contém sua própria biblioteca antiga ou uma implantação sobrescreve a configuração. Se instâncias de substituição trouxerem repetidamente a falha de volta, atualize a imagem de referência aprovada ou o modelo que as cria. Trate reaberturas repetidas como evidência de uma causa raiz no processo de compilação ou implantação.

Use estados claros no fluxo de trabalho

Mova o trabalho por estados como aberto, em andamento, mitigado, risco aceito, resolvido aguardando verificação e encerrado. “Mitigado” significa que um controle reduziu o risco; “encerrado” exige a evidência de encerramento pertinente. A integração entre scanner e chamados pode reduzir duplicações, mas mudanças automáticas de estado ainda devem seguir as regras de verificação bem-sucedida e de exceção.

Leia as métricas em conjunto

Cinco achados críticos são encerrados após 4, 9, 12, 20 e 30 dias:

Com um SLO de 15 dias, apenas três ficaram no prazo:

A média atende aos 15 dias, enquanto 40% desses achados não cumpriram a meta. Informe também os achados abertos em atraso: uma média do trabalho concluído não diz há quanto tempo um item não resolvido está aberto.

Faça o escalonamento do trabalho que precisa de decisão

Faixas de tempo em aberto como 0–30, 31–60, 61–90 e mais de 90 dias mostram o trabalho parado. Compare o tempo em aberto de cada item com seu próprio prazo e siga a política do responsável ao gestor e depois ao comitê de risco. Uma falha cuja exploração acaba de ser identificada pode precisar de escalonamento imediato, antes de qualquer limiar de tempo.

Equipes técnicas precisam de listas de hosts, evidências e correções. Gestores precisam de tendências, principais riscos, trabalho atrasado e recursos ou decisões necessários. Uma queda no total pode resultar de falhas nas varreduras ou do encerramento rápido de itens de baixo impacto, portanto compare a cobertura e o tempo em aberto dos itens de alta prioridade antes de considerá-la progresso.

Achados de aplicações descrevem falhas na forma como o software trata dados, memória, identidade ou erros. Escolha a correção de acordo com o mecanismo. O OWASP Top 10:2025 é uma lista de conscientização: Falha no controle de acesso, Configuração incorreta de segurança, Falhas na cadeia de suprimentos de software, Falhas criptográficas, Injeção, Projeto inseguro, Falhas de autenticação, Falhas de integridade de software ou dados, Falhas de registro e geração de alertas de segurança e Tratamento inadequado de condições excepcionais.

Impeça que dados se tornem instruções

A injeção ocorre quando uma entrada não confiável se torna parte de uma consulta ou comando. Use consultas parametrizadas, validação por lista de valores permitidos e contas com o menor privilégio; evite chamadas ao shell construídas com entradas de usuários. A execução de scripts entre sites (XSS) executa um script fornecido pelo atacante no navegador de outro usuário. A XSS refletida retorna em uma resposta imediata, a XSS armazenada é salva para pessoas que a verão depois e a XSS baseada em DOM surge no código do lado do cliente. Use codificação de saída adequada ao contexto e modelos seguros, apoiados por uma política de segurança de conteúdo. Cookies HttpOnly limitam o acesso de scripts aos cookies, mas não corrigem saídas inseguras.

Distinga requisições e acesso a arquivos

A SSRF pode alcançar metadados de nuvem em 169.254.169.254. A inclusão de arquivo pode divulgar conteúdo ou executar código, dependendo de como a aplicação trata o arquivo.

Proteja a memória e as permissões

Um estouro de buffer grava além da memória alocada na pilha ou no heap. Um estouro de inteiro ultrapassa o intervalo de um tipo; a aritmética sem sinal de 8 bits pode retornar de 255 mais 1 para 0. Use verificações de limites, funções seguras e linguagens com segurança de memória. ASLR, DEP/NX e valores sentinela de pilha dificultam a exploração enquanto a falha de programação permanece.

Uma falha no controle de acesso permite que usuários ultrapassem permissões, por exemplo, lendo a fatura de outro cliente ao alterar o identificador da fatura. Verifique a autorização no servidor em cada requisição e negue acesso por padrão. A elevação vertical de privilégios obtém direitos superiores; a horizontal alcança direitos de outro usuário. Correções de autenticação e sessão incluem MFA, IDs de sessão aleatórios, renovação na entrada e expiração.

Trate o projeto e os serviços de apoio

Falhas criptográficas incluem dados sem criptografia, chaves inseridas diretamente no código e hashes rápidos de senhas. Use TLS 1.2 ou posterior, chaves gerenciadas e hashes lentos de senhas, como Argon2 ou bcrypt. Remova contas padrão, recursos desnecessários, listagem de diretórios e erros detalhados. Valide falhas específicas de componentes separadamente do risco de suporte por fim de vida útil.

Projeto inseguro precisa de mudanças no projeto e na implementação, com modelagem de ameaças para identificar controles ausentes. A execução remota de código permite que um atacante faça um código escolhido ser executado remotamente; a execução local de código tem um requisito de acesso diferente. O envenenamento de dados corrompe dados confiáveis ou de treinamento: controle as fontes e acompanhe a procedência. Quando ocorrerem erros, negue acesso em caso de falha para que condições excepcionais não concedam acesso. Um firewall de aplicação web pode reduzir a exposição durante a correção do código, mas o código inseguro ainda precisa ser corrigido.

Software seguro precisa de verificações em várias etapas porque nenhum teste isolado enxerga todo o sistema. Acrescente requisitos de segurança, modelagem de ameaças, revisão de código, testes automatizados, verificações de implantação e manutenção ao ciclo de vida de desenvolvimento de software (SDLC). Antecipar verificações adequadas é chamado de deslocamento para a esquerda.

Compare os métodos de teste

O SAST pode sinalizar um valor de requisição concatenado em uma consulta. O DAST pode fornecer evidências de resposta da aplicação de teste em execução. Valide as evidências combinadas antes de escolher a correção de código. Testes com entradas malformadas ou variadas acrescentam testes de entradas malformadas para encontrar falhas de execução e outros problemas. Autenticação e cobertura da varredura importam: uma execução de DAST que nunca alcança uma página administrativa não avaliou suas entradas.

Encontre dependências afetadas

A SCA lê manifestos de pacotes, arquivos de bloqueio de versões ou binários para identificar componentes incluídos. Por exemplo, log4j-core 2.14.1 é afetado pela Log4Shell, CVE-2021-44228, com CVSS v3.1 10,0. A correção exige uma versão corrigida adequada e a reimplantação de todas as aplicações que contêm o componente. A versão 2.17.1, referência histórica de remediação para Java 8, trata as falhas relacionadas àquele incidente; selecione uma versão atualmente suportada e recomendada pelo fornecedor para novos trabalhos.

Uma SBOM registra componentes, versões, fornecedores e relações de dependência em um formato legível por máquina, como SPDX ou CycloneDX. Ela responde onde um componente é usado. Uma declaração VEX, de intercâmbio de informações sobre explorabilidade de vulnerabilidades, de um fornecedor informa se um produto está Não afetado, Afetado, Corrigido ou Em investigação quanto a uma vulnerabilidade. Valide a correspondência de produto e versão e o motivo apresentado na declaração VEX antes de alterar o estado de um achado.

Proteja a cadeia de suprimentos

Canais de atualização comprometidos, pacotes maliciosos com nomes semelhantes e dependências abandonadas podem introduzir riscos por meio de fornecedores confiáveis. O comprometimento do SolarWinds Orion em 2020 ilustra um ataque ao canal de atualização. Avalie as práticas dos fornecedores; acorde expectativas de correção e divulgação; solicite SBOMs; verifique hashes ou assinaturas; fixe versões de dependências; e use registros internos aprovados. Fixar versões torna as mudanças controladas, mas uma dependência fixada e desatualizada ainda precisa de revisão e atualizações.

Incorpore segurança ao programa

A modelagem de ameaças usa o projeto para perguntar o que poderia dar errado. O STRIDE abrange falsificação de identidade, adulteração, repúdio, divulgação de informações, negação de serviço e elevação de privilégio. Transforme as ameaças identificadas em controles e casos de teste.

O Modelo de maturidade de garantia de software (SAMM) da OWASP organiza a melhoria do programa em Governança, Projeto, Implementação, Verificação e Operações: três práticas em cada função, 15 no total, com níveis de maturidade de 1–3. Use-o para planejar capacidades, enquanto a programação segura no dia a dia mantém dados separados de comandos, codifica saídas, protege credenciais e sessões, limita privilégios e trata erros sem expor detalhes internos.

A segurança na nuvem depende do trabalho do provedor e do cliente. Identifique o modelo de serviço antes de atribuir um achado e avalie tanto as configurações implantadas quanto as imagens, o código e os modelos que as criam. Recursos de nuvem podem mudar mais rápido do que uma varredura periódica de rede consegue acompanhar.

Atribua responsabilidades por modelo de serviço

Em todos os modelos, os clientes continuam responsáveis por seus dados e por quem pode acessá-los. Um banco de dados gerenciado pode eliminar o trabalho de aplicar correções ao sistema operacional, mas deixar permissões excessivas ou exposição pública para o cliente corrigir.

Leia achados de postura por recurso

O gerenciamento da postura de segurança na nuvem (CSPM) verifica configurações pelas APIs dos provedores, geralmente com acesso somente de leitura. Prowler e ScoutSuite relatam achados por recurso e benchmark, como os benchmarks de fundamentos de nuvem do CIS. Repita as verificações porque configurações de contas, identidades e regras de rede mudam com frequência.

Achados comuns incluem armazenamento público, permissões de identidade amplas demais como "Action": "*", volumes ou instantâneos sem criptografia, registro de eventos desativado, chaves de acesso enviadas a repositórios, usuários privilegiados sem MFA, interfaces de gerenciamento expostas e acesso SSH ou RDP aberto a toda a internet. 0.0.0.0/0 abrange todos os endereços IPv4; uma regra que o permite na porta 22 ou 3389 expõe o serviço de gerenciamento em todos os locais de onde o recurso é alcançável.

Corrija a fonte da implantação

A infraestrutura como código (IaC) descreve recursos em modelos. Checkov ou Trivy pode sinalizar uma regra do Terraform que contém cidr_blocks = ["0.0.0.0/0"] para SSH antes da implantação. Restrinja o acesso à faixa administrativa necessária ou use um bastião aprovado ou serviço de gerenciamento de sessões.

Corrija a configuração implantada e seu modelo. Caso contrário, a próxima implantação pode restaurar a exposição. Diferenças entre as configurações declaradas e as reais são desvios de configuração. Uma correção feita somente no console pode ser temporária mesmo quando a verificação imediata é aprovada.

Reconstrua imagens e cubra cargas de curta duração

Faça varreduras das imagens de contêiner em busca de pacotes do sistema operacional e bibliotecas no pipeline de compilação e no registro. Reconstrua a partir de uma imagem base atualizada e reimplante; não dependa da aplicação de correções a contêineres individuais em execução. Imagens base mínimas reduzem componentes desnecessários. Inspecione também definições do Kubernetes em busca de configurações arriscadas, como execução privilegiada.

Use APIs dos provedores e etiquetas de recursos para inventariar instâncias de curta duração. Avalie as imagens de referência aprovadas, os modelos e as dependências dessas instâncias; use agentes compatíveis ou avaliação de instantâneos quando adequado. Em ambientes de execução sem servidor gerenciados, as atualizações do provedor seguem as configurações de atualização do serviço. Os clientes mantêm o código e as bibliotecas das funções, reconstroem funções baseadas em contêineres e atualizam ambientes de execução personalizados.

Acompanhe um achado de postura até a verificação

Uma avaliação encontra armazenamento público de dados pessoais, acesso root sem MFA e RDP aberto a toda a internet. Restrinja imediatamente os dados expostos e trate com urgência a identidade privilegiada e o caminho de gerenciamento. Corrija as regras do bucket e da rede nos recursos implantados e na IaC. Configure a MFA do usuário root da AWS pelo Management Console; APIs comuns e IaC não a habilitam. Execute novamente as verificações pertinentes, confirme que o acesso da aplicação ainda funciona e verifique se uma implantação posterior preserva a correção.