Perfeito. Vamos organizar tudo em um único modelo mental, sem misturar conceitos.
Vou partir do problema real que você descreveu (planilha de vulnerabilidades) e chegar ao mapa completo.
- Situação (contexto real)
Você tem uma planilha com abas e siglas como:
SAST-SDLC
SAST-EXP
OSS-SDLC
OSS-EXP
DAST-SDLC
DAST-EXP
E já conhece ferramentas como:
Fortify → código
WebInspect → aplicação em execução
Wiz → infraestrutura / cloud
O desafio é entender o que cada coisa cobre e como tudo se conecta.
- Ação — separar por O QUE é analisado
Primeiro, ignore ferramentas. Pense no alvo da vulnerabilidade.
2.1 Código-fonte (antes de rodar)
Categoria: SAST Pergunta que responde:
“O código tem falhas antes mesmo de ser executado?”
Exemplos de problemas detectados:
SQL Injection
XSS
Path Traversal
Uso inseguro de criptografia
Falta de validação de entrada
Ferramenta típica:
Fortify
➡️ Não precisa da aplicação rodando ➡️ Analisa Java, JS, .NET, etc.
2.2 Dependências e bibliotecas
Categoria: OSS (SCA – Software Composition Analysis) Pergunta que responde:
“Estou usando bibliotecas conhecidamente vulneráveis?”
Exemplos de problemas detectados:
Log4j vulnerável
Spring com CVE
Biblioteca abandonada
Versão com exploit público
Ferramentas típicas:
SCA do Fortify
OWASP Dependency-Check
Snyk
➡️ Analisa pom.xml, package.json, gradle, etc. ➡️ Não analisa código autoral, só o que você importou
2.3 Aplicação rodando (caixa-preta)
Categoria: DAST Pergunta que responde:
“Minha aplicação, em produção ou homologação, pode ser explorada?”
Exemplos de problemas detectados:
SQL Injection explorável
XSS refletido ou armazenado
Headers inseguros
Autenticação fraca
Sessão insegura
Ferramenta típica:
WebInspect
➡️ Precisa da aplicação no ar ➡️ Teste externo, sem olhar código
2.4 Infraestrutura / Cloud / Host
Categoria: Infra / Cloud Security Pergunta que responde:
“Meu ambiente é seguro?”
Exemplos de problemas detectados:
Porta aberta desnecessária
Container rodando como root
SO desatualizado
IAM permissivo
Vulnerabilidade no runtime
Ferramenta típica:
Wiz
➡️ Não analisa código ➡️ Analisa VM, container, Kubernetes, cloud
- Ação — agora conectar com sua planilha (SDLC vs EXP)
Aqui está o ponto que normalmente confunde.
3.1 SDLC vs EXP
SDLC
Vulnerabilidade detectada durante o ciclo de desenvolvimento
Normalmente:
SAST
OSS
DAST em ambiente controlado
EXP (Exposure)
Vulnerabilidade exposta
Normalmente:
App em produção
Endpoint acessível
Infra vulnerável
- Resultado — mapa final unificado
4.1 Tabela mental definitiva
Sigla O que analisa Quando Exemplo de ferramenta
SAST Código-fonte Antes de rodar Fortify OSS Bibliotecas Build / CI Fortify SCA DAST App rodando Homolog / Prod WebInspect Infra Servidor / Cloud Runtime Wiz
4.2 Ligando com sua planilha
SAST-SDLC Código vulnerável identificado no desenvolvimento
SAST-EXP Código vulnerável já em produção
OSS-SDLC Dependência vulnerável detectada antes do deploy
OSS-EXP Biblioteca vulnerável já exposta em produção
DAST-SDLC Falha detectada em ambiente de teste
DAST-EXP Falha explorável em produção
- Regra de ouro (para nunca mais confundir)
SAST olha código OSS olha dependência DAST olha comportamento Wiz olha ambiente
Cada um cobre uma camada diferente do risco.
Se quiser, no próximo passo posso:
Criar um modelo de classificação automática para a planilha
Definir priorização real (o que corrige primeiro)
Traduzir isso para linguagem de gestão / auditoria
Você decide o próximo passo.
======
Perfeito. Vamos seguir na ordem correta: primeiro prioridade real, depois linguagem de gestão. Sem floreio. Sem jargão desnecessário.
- PRIORIDADE REAL DE CORREÇÃO (TÉCNICA)
1.1 Situação
Você tem múltiplas vulnerabilidades vindas de:
SAST (código)
OSS (dependências)
DAST (app rodando)
Infra (Wiz)
Nem todas têm o mesmo risco real, mesmo com CVSS alto.
1.2 Ação — critério técnico que NÃO falha
A prioridade não começa pela ferramenta. Começa por explorabilidade + impacto.
Regra base (ordem correta)
-
Explorável em produção
-
Acessível externamente
-
Impacta dados, autenticação ou execução
-
Exploit público conhecido
-
Facilidade de exploração
1.3 Matriz de prioridade prática (use como regra fixa)
🔴 PRIORIDADE CRÍTICA (corrigir imediatamente)
Condições (qualquer uma):
DAST-EXP
OSS-EXP com exploit público
Infra EXP com acesso externo
Execução remota, bypass de auth, vazamento de dados
Exemplos:
SQL Injection detectado por WebInspect em produção
Log4j vulnerável em app exposto
Porta admin aberta detectada pelo Wiz
➡️ Risco real de incidente ➡️ SLA: horas / poucos dias
🟠 PRIORIDADE ALTA
Condições:
SAST-EXP
OSS-SDLC com deploy iminente
Infra vulnerável mas sem exposição direta
Exemplos:
Código com falha grave já em produção, mas sem PoC
Dependência crítica vulnerável, porém sem exploit público
➡️ Risco latente ➡️ SLA: curto prazo
🟡 PRIORIDADE MÉDIA
Condições:
SAST-SDLC
OSS-SDLC
Falha não explorável diretamente
Exemplos:
Validação de entrada ausente
Uso de API insegura sem rota pública
➡️ Débito técnico de segurança ➡️ SLA: backlog planejado
🟢 PRIORIDADE BAIXA
Condições:
Boas práticas
Hardening
Avisos sem impacto direto
Exemplos:
Header ausente sem exploração
Versão antiga sem CVE relevante
➡️ Não bloquear release
1.4 Regra de desempate (quando tudo parece crítico)
Priorize nesta ordem:
-
DAST-EXP
-
OSS-EXP
-
Infra-EXP
-
SAST-EXP
-
SDLC (todos)
Motivo:
Vulnerabilidade executável vence vulnerabilidade teórica.
- LINGUAGEM DE GESTÃO (EXECUTIVO / COMITÊ)
Agora mudamos o discurso, não o conteúdo.
Gestão não quer sigla, quer risco e decisão.
2.1 Situação (como apresentar)
Nunca diga:
“Encontramos X vulnerabilidades SAST e Y DAST”
Diga:
“Temos riscos que podem gerar incidente de segurança”
2.2 Ação — tradução direta (sem distorção)
Tradução oficial das categorias
Técnico Linguagem gestão
DAST-EXP Falha explorável em produção OSS-EXP Uso de software vulnerável com exploit conhecido SAST-EXP Erro de desenvolvimento já em produção SDLC Risco preventivo Infra Wiz Risco de exposição do ambiente
2.3 Modelo de resumo executivo (1 slide / 1 página)
Situação
X aplicações com falhas exploráveis em produção
Y riscos potenciais no ciclo de desenvolvimento
Z exposições de infraestrutura
Impacto
Possível indisponibilidade do sistema
Risco de vazamento de dados
Risco regulatório e reputacional
Ação recomendada
Correção imediata dos itens exploráveis
Planejamento das correções preventivas
Monitoramento contínuo
Decisão requerida
Priorizar correções críticas
Aprovar janela técnica / esforço
2.4 Frases prontas (use sem medo)
“Nem todas as vulnerabilidades representam risco imediato”
“Estamos priorizando aquilo que pode ser explorado hoje”
“O foco é reduzir a probabilidade de incidente”
“As demais entram como melhoria contínua”
- RESULTADO FINAL (modelo mental único)
Ferramenta encontra
Classificação organiza
Explorabilidade decide
Gestão aprova
Time executa
Se quiser, no próximo passo posso:
Criar um score único de risco para sua planilha
Montar SLA por severidade
Definir política corporativa de segurança aplicável à auditoria
Você escolhe.
Perfeito. Vamos fundir siglas + ferramentas + tipo de risco em um único modelo, direto para uso prático na planilha e em reunião.
- SITUAÇÃO
Você citou 3 ferramentas reais usadas no dia a dia:
Fortify
WebInspect
Wiz
E sua planilha usa siglas como:
SAST / DAST / OSS
SDLC / EXP
O objetivo agora é não pensar mais em siglas soltas, mas em quem detecta o quê e qual risco isso representa.
- AÇÃO — MAPA ÚNICO (SIGLA × FERRAMENTA × RISCO)
2.1 Fortify
O que o Fortify cobre
Sigla Ferramenta O que analisa Tipo de vulnerabilidade
SAST-SDLC Fortify Código-fonte Falha lógica, validação, injeção, XSS SAST-EXP Fortify Código em produção Código vulnerável já publicado OSS-SDLC Fortify SCA Dependências Lib vulnerável antes do deploy OSS-EXP Fortify SCA Dependências em prod CVE já exposta
Leitura correta
Fortify nunca vê o sistema rodando
Tudo é análise estática
Alto volume, nem tudo é risco real
2.2 WebInspect
O que o WebInspect cobre
Sigla Ferramenta O que analisa Tipo de vulnerabilidade
DAST-SDLC WebInspect App em teste Falhas exploráveis em homolog DAST-EXP WebInspect App em produção Falhas exploráveis reais
Leitura correta
WebInspect só acusa o que consegue explorar
Poucos achados, mas alta prioridade
Aqui normalmente nasce incidente
2.3 Wiz
O que o Wiz cobre
Categoria prática Ferramenta O que analisa Tipo de risco
Infra-EXP Wiz Cloud / VM / Container Porta aberta, IAM, SO vulnerável Runtime-EXP Wiz App + host Exposição indireta da aplicação
Leitura correta
Wiz não é SDLC
Tudo é produção ou pré-produção
Risco de movimento lateral e invasão
- RESULTADO — PRIORIDADE AUTOMÁTICA (COM FERRAMENTA)
Use esta ordem sem exceção:
🔴 Prioridade crítica
DAST-EXP (WebInspect)
OSS-EXP (Fortify)
Infra-EXP (Wiz)
➡️ Explorável agora ➡️ Risco de incidente
🟠 Prioridade alta
SAST-EXP (Fortify)
OSS-SDLC com deploy próximo
➡️ Código frágil em produção ➡️ Risco latente
🟡 Prioridade média
SAST-SDLC
OSS-SDLC
➡️ Débito técnico ➡️ Prevenção
- COMO ISSO FICA NA PLANILHA (PADRÃO FINAL)
Colunas mínimas recomendadas
Ferramenta (Fortify | WebInspect | Wiz)
Categoria (SAST | DAST | OSS | Infra)
Fase (SDLC | EXP)
Explorável (Sim / Não)
Prioridade (Crítica / Alta / Média / Baixa)
- FRASE ÚNICA PARA GESTÃO (RESUMO)
“Fortify aponta riscos no código e dependências, WebInspect confirma falhas exploráveis na aplicação, Wiz mostra se o ambiente permite invasão.”
Se quiser, no próximo passo posso:
Gerar regra de priorização automática (fórmula Excel)
Criar política oficial de segurança baseada nessas 3 ferramentas
Montar template de reporte para auditoria / ISO / SOX
Você decide.
Perfeito. Vou entregar um plano de ação executivo, pronto para comitê, baseado diretamente na sua planilha (SAST / DAST / OSS + Fortify / WebInspect / Wiz).
Sem detalhe técnico excessivo. Com clareza de decisão, prioridade e resultado esperado.
PLANO DE AÇÃO EXECUTIVO — VULNERABILIDADES
- SITUAÇÃO (diagnóstico consolidado)
A planilha consolida vulnerabilidades identificadas por:
Fortify → código e dependências (SAST / OSS)
WebInspect → aplicação em execução (DAST)
Wiz → infraestrutura e cloud
Os achados estão distribuídos entre:
Riscos exploráveis em produção (EXP)
Riscos preventivos no ciclo de desenvolvimento (SDLC)
Nem todos representam risco imediato de incidente.
-
OBJETIVO DO PLANO
-
Reduzir risco imediato de incidente
-
Eliminar exposições exploráveis
-
Organizar correções preventivas sem impactar o negócio
-
Criar governança contínua de segurança
- ESTRATÉGIA DE AÇÃO (VISÃO EXECUTIVA)
O plano é dividido em 3 frentes paralelas, com prioridades claras.
- PLANO DE AÇÃO POR FASE
FASE 1 — CONTENÇÃO IMEDIATA (CRÍTICA)
Escopo
Vulnerabilidades EXP identificadas por:
WebInspect (DAST-EXP)
Fortify (OSS-EXP)
Wiz (Infra-EXP)
Ação
Correção ou mitigação imediata
Aplicar patches, atualização de dependências ou bloqueios
Revisar exposição externa
Responsáveis
Times de aplicação
Infraestrutura / Cloud
Segurança
Resultado esperado
Redução imediata da probabilidade de incidente
Eliminação de falhas exploráveis
Indicador
% de EXP resolvidas
Zero falhas críticas abertas em produção
FASE 2 — ESTABILIZAÇÃO (ALTA PRIORIDADE)
Escopo
Vulnerabilidades já em produção, porém sem exploração ativa:
SAST-EXP (Fortify)
OSS com deploy iminente
Ação
Correção planejada
Ajustes de código
Atualização controlada de bibliotecas
Responsáveis
Times de desenvolvimento
Arquitetura
Resultado esperado
Redução de risco latente
Evitar que falhas evoluam para incidentes
Indicador
Redução mensal de vulnerabilidades EXP
Cumprimento de SLA de correção
FASE 3 — PREVENÇÃO CONTÍNUA (SDLC)
Escopo
SAST-SDLC
OSS-SDLC
DAST em ambiente de teste
Ação
Tratar como débito técnico de segurança
Priorizar por criticidade e impacto
Integrar correções ao backlog
Responsáveis
Desenvolvimento
Segurança de aplicação
Resultado esperado
Menor volume de falhas chegando à produção
Melhoria contínua da qualidade de código
Indicador
Redução de achados por release
Aumento de correções ainda no SDLC
- GOVERNANÇA E CONTROLE
Regras executivas
EXP sempre tem prioridade sobre SDLC
DAST vence SAST em decisão
Explorável vence severidade teórica
Cadência
Revisão quinzenal de EXP
Revisão mensal de SDLC
Relatório executivo consolidado
- COMUNICAÇÃO PARA GESTÃO
Mensagem-chave
“Estamos atuando primeiro nas falhas que podem gerar incidente hoje, enquanto organizamos correções preventivas para reduzir risco futuro.”
- RESULTADO FINAL ESPERADO
Menor exposição a incidentes de segurança
Clareza de prioridade para os times
Uso eficiente de esforço técnico
Base sólida para auditorias e compliance
Se quiser, no próximo passo posso:
Criar SLA formal por categoria (Crítica, Alta, Média)
Gerar modelo de dashboard executivo
Converter isso em política corporativa de AppSec
Você decide o próximo passo.