Afogando em Defeitos Enquanto Construíamos uma "Janela Única"

64K+ Alcance em 30 dias Bastion 287,84 Classificação 26 935 Assinantes Inscrever-se puzankov7 1 minuto atrás Afogando em Defeitos Enquanto Construíamos uma "Janela Única" Médio 13 min 23 Blog da Empresa Bastion Segurança da Informação * Gerenciamento de Desenvolvimento * DevOps * Empresas de TI Opinião "Tínhamos dois pacotes de descobertas SAST, setenta e cinco CVEs com criticidade - Crítico, cinquenta duplicatas da mesma CVE em diferentes serviços, um monte de falsos positivos e uma série de vulnerabilidades de todos os tipos e cores: SQLi, XSS, SSRF, RCE, IDOR, segredos vazados, misconfigs no Kubernetes, escritos por uma pessoa que claramente não planejava sobreviver a uma auditoria. Além disso, tínhamos mudanças geradas por assistentes de IA, exceções esquecidas em verificações de acesso, soluções temporárias que há muito se tornaram parte da arquitetura, dois relatórios de pentest, milhares de tarefas e um painel que ficava vermelho como se visse todos os nossos futuros incidentes de uma vez. Não que isso fosse uma reserva necessária para o gerenciamento da segurança de aplicativos, mas se você decidir construir um ASPM agregando tudo, cedo ou tarde você se encontra nessa máquina - em alta velocidade, sem mapa, com desenvolvedores no banco de trás, que só perguntam: 'O que realmente precisa ser corrigido?'". Olá a todos! Meu nome é Artem Puzankov, sou chefe do departamento de consultoria de desenvolvimento seguro na Bastion. Hoje eu gostaria de refletir com vocês sobre o gerenciamento da postura de segurança de aplicativos, ASPM, código gerado por IA e AppSec. Este artigo é sobre por que o futuro do ASPM não é coletar todos os defeitos em uma "janela única", mas sim correlacionar as descobertas, verificar a capacidade de exploração e separar as ameaças reais do ruído (leia-se dívida técnica). O que é ASPM e por que precisamos dele Application Security Posture Management, ou ASPM, é uma camada de gerenciamento de segurança de aplicativos que agrega dados de diferentes ferramentas AppSec e ajuda a entender o que está acontecendo com os riscos ao longo do ciclo de vida do desenvolvimento. Imagine: a equipe tem várias ferramentas de segurança. Uma lê o código e procura construções perigosas, a segunda verifica bibliotecas de terceiros, a terceira procura erros em manifestos do Kubernetes, a quarta - senhas e tokens, acidentalmente deixados no código. Cada ferramenta funciona de forma independente e produz sua própria lista de problemas. Como resultado, a equipe tem três tabelas, dois painéis, quinhentas linhas com descobertas e nenhuma resposta clara para a pergunta "o que está acontecendo e o que consertar primeiro?". ASPM é necessário para transformar os resultados dispersos das ferramentas AppSec em um processo gerenciável. Em uma boa implementação, o ASPM se torna uma ponte entre a equipe de segurança e os desenvolvedores, ajudando a levar o problema à correção: vincular a descoberta ao repositório, componente, proprietário, tarefa no rastreador e status da correção. Vitórias Rápidas Mas o ASPM geralmente não vem imediatamente. No começo, como muitos, eu pensei que a principal raiz dos problemas no AppSec era bastante simples: não verificamos tudo o que devemos. Há uma ferramenta - vemos o problema, não há ferramenta - vivemos em feliz ignorância. Sem SAST - não vemos defeitos no código, sem SCA - não entendemos quais dependências vulneráveis estamos arrastando para o produto, sem DAST - não verificamos o aplicativo por fora, sem secrets scanning - cedo ou tarde alguém vai comitar um token, e assim por diante. A lógica é simples - quanto mais verificações, mais descobertas, mais seguro é o desenvolvimento. Como resultado, as empresas começam a implementar tudo de uma vez: SAST, SCA, DAST, container scanning, IaC scanning, secrets scanning. Eles adicionam tudo isso ao CI/CD de uma equipe piloto, definem SLAs, configuram tickets, escalam para toda a empresa e fazem painéis bonitos para a alta gerência. Nas apresentações, parece bonito e convincente. Você pode ver quais aplicativos estão sendo escaneados, onde há mais critical/high, quais equipes estão corrigindo rapidamente e quais estão acumulando dívidas, onde estão as dependências antigas, onde estão os segredos, onde estão as configurações inseguras. Parece que, finalmente, uma imagem completa está começando a se formar. As primeiras semanas após isso geralmente passam com entusiasmo: "Uau, construímos AppSec/DevSecOps!". Todos estão felizes, o CISO relata para cima: "Agora temos gerenciamento". O desenvolvimento diz: "Ok, há mais tarefas, mas pelo menos está claro de onde elas vêm". Cortina, final feliz... e então o próximo trimestre começa. O painel gradualmente fica mais vermelho, e o backlog fica mais longo... SAST encontra possível SQL injection, criticidade - high. O desenvolvedor abre o código e vê que o sink potencialmente perigoso está em uma tarefa em lote interna e não recebe uma solicitação HTTP, não há parâmetro externo, e os dados passam por uma fonte predefinida controlada. Formalmente, o padrão é perigoso, mas nenhum caminho real da entrada não confiável para a solicitação SQL ainda é visível. SCA encontra uma CVE crítica em uma biblioteca. Então fica claro que a biblioteca está realmente na árvore de dependência, mas a função vulnerável não é chamada, a dependência é usada apenas em devtools e não entra na compilação de produção. A CVE permanece CVE, mas sua prioridade para um aplicativo específico muda. DAST não encontra nada. Container Security encontra dezenas de CVEs na imagem base. Secrets scanner "se preocupa" com a chave de teste da documentação. Formalmente, tudo funciona: as ferramentas encontram problemas, os tickets são criados, o painel fica verde, então fica vermelho novamente. Mas em algum momento, o desenvolvimento faz a pergunta mais desagradável: "O que precisa ser corrigido agora mesmo para lançar?". E é aqui que percebemos que a lista geral de descobertas ajuda a ver a escala do problema, mas não ajuda o desenvolvedor a responder à sua pergunta. Vitórias rápidas acabaram. Começamos a enxergar No nível estratégico, tudo parecia convincente: mais varreduras - mais problemas encontrados, mais problemas encontrados - mais correções, mais correções - menos risco. Mas na realidade, cada finding não é uma tarefa, mas um objeto para triagem. Ele precisa ser desmontado, encontrar o proprietário do serviço, entender se há uma oportunidade real de exploração ou se é apenas uma construção suspeita no código, explicar ao desenvolvedor por que isso é importante, controlar a correção e, em seguida, re-escanear. Porque um ticket fechado ainda não significa um risco fechado. E se houver milhares de findings? A equipe AppSec para muito rapidamente de ajudar o desenvolvimento a tomar as decisões certas e se transforma em um serviço de despacho para processar alertas. É fácil tirar a conclusão errada aqui - o problema está nos scanners. SAST falha, SCA envia spam de CVEs, e os desenvolvedores não querem corrigir as vulnerabilidades. Mas os scanners não tomam decisões para o AppSec. Eles não conhecem seu produto, não entendem todas as suas nuances. Sua tarefa é mais simples - notar um lugar suspeito e alertar. É por isso que eles costumam ser cautelosos. Um falso positivo é uma análise extra, irritação do desenvolvedor e menos confiança na ferramenta, o que é desagradável, mas você pode sobreviver. Mas uma vulnerabilidade perdida que entrou em produção e se transformou em um incidente... Portanto, o scanner quase sempre segue a lógica: é melhor "gritar" mais uma vez do que ficar em silêncio onde pode haver um risco real. Mas isso não significa que o ruído precise ser enviado cegamente para o desenvolvimento. Após a primeira varredura, o trabalho real começa - não enviar o alerta adiante, mas entender onde ele apareceu, por que a ferramenta reagiu, se há falsos positivos semelhantes, quais regras precisam ser ajustadas, se há uma oportunidade real de exploração por trás dele, qual serviço é afetado e o que acontecerá se você usá-lo. E só depois disso decidir se é uma tarefa para desenvolvimento, dívida técnica ou um falso positivo que precisa ser excluído com a configuração "fina" da ferramenta. É aqui que o ASPM deve parar de ser apenas uma "janela única". Sua tarefa não é apenas colocar todos os alertas em uma lista, mas ajudar a descobrir o que está por trás deles - uma vulnerabilidade real ou um falso positivo recorrente. Se não houver essa etapa, o AppSec simplesmente roteará o spam das ferramentas para o desenvolvimento. As ferramentas encontraram algo, o ASPM organizou tudo isso lindamente, a tarefa chegou ao desenvolvimento. Minha opinião: por muito tempo aceitamos a presença de uma descoberta como a presença de uma vulnerabilidade. As ferramentas mostram sinais. Elas se tornam vulnerabilidades no sentido prático somente quando as correlacionamos entre si e com o contexto do aplicativo. Mas o sinal em si raramente responde à pergunta de quão perigoso é para nosso aplicativo. É aqui que a correlação é necessária. Não no sentido de "confirmar a estática com a dinâmica", mas no sentido de "vincular a descoberta aos fatos verificáveis ​​ao seu redor": a função vulnerável é chamada, há um caminho dos dados de entrada para a chamada perigosa, o componente entra na compilação de produção, o serviço está acessível externamente, quais são os direitos do segredo encontrado, quem é o proprietário do serviço e quão crítico é esse serviço. Portanto, reduzir o ASPM a uma "janela única", onde os resultados de todos os scanners são despejados, significa subestimar seriamente seus benefícios. Desta forma, ajuda a ver a escala do problema, mas nem sempre ajuda a tomar uma decisão. O valor real do ASPM aparece na próxima etapa - quando ele se torna uma camada de correlação e interpretação: mostra o que das descobertas se assemelha a um risco real, o que requer análise manual, o que pode ser honestamente levado para a dívida técnica. Neste momento, as descobertas deixam de ser uma série de alertas separados e começam a se transformar em cenários. SAST mostra uma construção perigosa, DAST a confirma por fora, o tempo de execução diz que o código está realmente sendo executado, o catálogo de serviços mostra a criticidade do serviço - e não temos mais um conjunto de sinais separados, mas uma ameaça específica. Estes são níveis fundamentalmente diferentes de maturidade. No primeiro caso, simplesmente colocamos os dados em um sistema, no segundo - começamos a entender o significado desses dados. O ASPM é útil não pelo fato de armazenar descobertas, mas pelo fato de ajudar a explicar sua prioridade. Um defeito bloqueia o lançamento, outro permanece na dívida técnica, e cada decisão tem uma razão clara. No SCA, esse pensamento já se tornou familiar. Se houver uma biblioteca vulnerável no projeto - ruim, mas isso ainda não significa que a vulnerabilidade possa ser explorada. É importante não apenas que a biblioteca esteja na árvore de dependência. É importante se a função vulnerável é usada, se é possível alcançá-la do aplicativo, se o usuário pode influenciar os dados de entrada, se esse código está em produção, se o serviço está acessível externamente e quão crítico ele é. Se a biblioteca estiver presente, mas a seção vulnerável nunca for chamada, o risco é um, se a mesma biblioteca processa uma solicitação de API pública em um serviço de pagamento, o risco é completamente diferente. O mesmo princípio é necessário para SAST. Uma potencial SQL injection no código é uma hipótese, um caminho alcançável do parâmetro externo para a solicitação SQL é um risco, e se esse caminho for confirmado por DAST/tempo de execução - um cenário de ataque específico. O desenvolvedor não precisa de uma tarefa como: "Possível SQL Injection. Severidade Alta" O desenvolvedor precisa de uma tarefa de outro nível: "No endpoint público /api/payment/search parâmetro query entra na solicitação SQL sem parametrização. O caminho é confirmado por análise estática e verificação DAST. O serviço está em produção e processa dados de pagamento. Corrigir antes do lançamento". No primeiro caso, o AppSec traz uma suspeita para o desenvolvedor, e no segundo - uma vulnerabilidade com um caminho de exploração confirmado. SAST encontrou uma potencial command injection. O inventário da API mostra que o endpoint é público. DAST conseguiu chegar a este endpoint. O tempo de execução mostra que a função correspondente está realmente sendo executada. A nuvem mostra que o serviço está acessível pela Internet. O catálogo de serviços diz que o serviço é crítico e funciona com dados do cliente. Este é o risco. E se o SAST encontrar um defeito semelhante no módulo da calculadora interna de dias de férias, que não é chamado, não é implantado na produção e não tem entrada externa, isso não significa que o problema precise ser esquecido - ele precisa ser classificado corretamente: não como um incidente/bloqueador de lançamento, mas como dívida técnica ou uma tarefa de refatoração. Agora vamos falar sobre criticidade. Um dos hábitos mais prejudiciais do AppSec é chamar tudo de vulnerabilidades "high/critical". O scanner definiu High - então, High, a CVE é crítica - então, urgentemente. O problema é que o desenvolvimento rapidamente para de acreditar nisso. Se cada potencial vulnerabilidade chega como urgente, a equipe começa a perceber a segurança como algo em segundo plano. Se metade das descobertas high não forem reproduzidas, a confiança diminui. Se um desenvolvedor gasta um dia analisando um defeito inatingível, ele também encontrará a próxima vulnerabilidade real com ceticismo. Este é um momento perigoso, porque o AppSec pode ter boas ferramentas, painéis bonitos, mas ao mesmo tempo perder o principal - a confiança do desenvolvimento. E sem confiança, nada funciona. "Vamos 'vaibcodar'?" Ah, sim, onde estaríamos sem "vaibcoding" com a ajuda de assistentes de IA, que aceleraram a escrita do código... e aceleraram o acúmulo de dívidas :) Nesse contexto, outro vetor aparece - IA no desenvolvimento. Assistentes e agentes de IA realmente aceleram o desenvolvimento: ajudam a escrever código de modelo, testes, migrações, CRUD, documentação, refatorar legado, explicar partes desconhecidas da base de código - em geral, tudo. Mas há também um efeito colateral: há mais código, há mais solicitações de mesclagem, a superfície de ataque está crescendo, e junto com ela a dívida de segurança está crescendo. A verdade é que os assistentes de IA não conhecem o contexto do produto, pelo menos por enquanto. Eles podem adicionar um novo endpoint e, assim, expandir imperceptivelmente a superfície de ataque. Eles podem registrar o corpo da solicitação "para facilitar a depuração", sem entender que há dados pessoais lá. E eles podem oferecer uma dependência que não existe - isso é chamado de package hallucination. Isso não é o mesmo que dependency confusion, mas há uma conexão: o nome do pacote inventado pelo modelo pode se tornar um alvo conveniente para um invasor que registra tal pacote em um repositório público e transforma um erro de preenchimento automático em um risco da cadeia de suprimentos. Se antes a equipe lançava 20 MRs por semana, e agora com IA lança 40, então para a equipe de desenvolvimento isso parece uma aceleração, mas para o AppSec - um aumento acentuado no fluxo (x2) de verificações e descobertas, entre as quais é necessário distinguir uma vulnerabilidade real de outra construção suspeita, verificá-la, explicá-la e priorizá-la. E então tudo isso "bem" entra nos scanners, depois - no ASPM, e se ele só sabe agregar - o backlog simplesmente se expande. É por isso que o desenvolvimento de IA torna o ASPM uma ferramenta ainda mais importante, porque a antiga abordagem "cada finding - uma tarefa para o desenvolvedor" no mundo do desenvolvimento ainda mais acelerado é finalmente quebrada. O código é criado mais rápido do que o AppSec consegue analisá-lo manualmente e, portanto, a segurança precisa se adaptar novamente. Fantasias Agora vamos fantasiar sobre como a IA no APSM pode simplificar a interpretação de vulnerabilidades no código gerado. Já temos muitas falhas encontradas, então seria um erro fatal esperar outra lista de vulnerabilidades da IA. Na minha opinião, o valor real da IA no ASPM não é aumentar ainda mais o número de descobertas, mas ajudar a entender quais delas estão interconectadas, quais são alcançáveis ​​e o que fazer com elas. Eu não quero me deter em cenários típicos que alguém já implementou: a IA explica a seção vulnerável do código, a IA oferece uma correção. Vamos sonhar com mais.

1. A IA pode se tornar uma camada analítica sobre o ASPM Por exemplo, SAST encontra um potencial SSRF: um parâmetro do usuário afeta a URL para a qual o serviço faz uma solicitação de saída. Por si só, esta ainda não é uma vulnerabilidade confirmada. Mas o ASPM adiciona contexto: o inventário da API mostra que o endpoint é publicado externamente, DAST confirma o acesso externo. A simples agregação mostrará várias descobertas separadas. A camada de IA pode conectá-las em uma hipótese de exploração: um usuário externo controla o parâmetro, o parâmetro potencialmente chega ao cliente HTTP, o que significa que o SSRF pode ser alcançado. A palavra-chave é "pode". Isso não deve se transformar em "IA aprovada - então, comprovado". A hipótese deve ser confirmada pela reprodução: fluxo de dados, gráfico de chamadas, DAST ou outra lógica verificável. Caso contrário, simplesmente substituiremos o ruído dos scanners por uma conclusão confiante, mas não verificada, do modelo. Neste ponto, a IA ajuda a não gerar outro alerta, mas a transformar um conjunto de descobertas separadas em um cenário de ataque claro. Mas sem essa comparação, o ASPM permanece um SIEM inútil para defeitos AppSec, e não um sistema que ajuda a entender o perigo real.
2. IA como tradutor entre AppSec e desenvolvimento Eu entendo que funcionalidade semelhante já existe em alguns produtos. Outro papel importante da IA é traduzir as descobertas da linguagem do scanner para a linguagem humana. O scanner pode escrever: "CWE-89: Neutralização inadequada de elementos especiais usados ​​em um comando SQL" E formalmente estará certo. Mas o desenvolvedor lê isso e não vê a tarefa. Ele ainda precisa abrir o código, encontrar a fonte de dados, percorrer o caminho para a solicitação SQL, entender se o endpoint está acessível externamente, se o cenário é reproduzido e o que precisa ser alterado. Uma tarefa normal deve ser assim: "No método searchPayments() parâmetro query entra na solicitação SQL via concatenação de strings. Endpoint /api/payment/search está acessível externamente e funciona em produção. DAST confirmou que o parâmetro pode alterar a estrutura da solicitação SQL. Correção: substituir a concatenação por uma consulta parametrizada". Outra questão? Como resultado, o desenvolvedor recebe não High do SAST, mas um caminho claro de correção.
3. IA para deduplicação inteligente A deduplicação normal geralmente funciona de forma primitiva: o mesmo CWE, o mesmo arquivo, a mesma linha, hashes. A IA pode agrupar isso não pelo mesmo ID, mas pelo significado. Por exemplo: "Esta é provavelmente a mesma vulnerabilidade: tratamento inseguro do parâmetro redirect_uri no fluxo de autenticação". Assim, o ASPM para de mostrar cinco "descobertas críticas" diferentes e mostra um risco com várias fontes de confirmação.
4. IA para automação de triagem Funcionalidade semelhante já existe em alguns produtos, na minha opinião, um dos cenários de aplicação mais práticos da IA - os analistas de AppSec vão te amar. Ninguém está falando sobre confiança total, mas a IA pode ajudar no primeiro nível de triagem - não tomar a decisão final, mas colocar as descobertas em cestas: Needs human review - finding parece importante, mas não há dados suficientes. Dívida técnica - o problema é real, mas não há sinais de capacidade de exploração agora. Candidato a falso positivo - finding parece um falso positivo.
5. IA para construir uma cadeia de exploração Um dos cenários mais fortes é construir uma cadeia de exploração clara. Não apenas: "Command injection. Severity High" Mas assim: "Um usuário externo chama /api/export . Parâmetro format entra em ReportService.generate() . O método chama um comando do sistema sem verificar a lista de valores permitidos. O serviço funciona em um ambiente de produção e tem acesso ao armazenamento de relatórios do cliente. Possíveis consequências - leitura ou alteração de relatórios". Este não é um alerta normal de um scanner, mas uma descrição de como a vulnerabilidade pode ser usada e o que isso levará.
6. IA para construir métricas/estatísticas eficazes Deixarei isso para você como alimento para reflexão 🙂 Se você reunir todos os cenários, fica claro que a IA no ASPM é necessária para ajudar a não se afogar no fluxo de defeitos e entender quais deles realmente exigem atenção. E isso significa que os requisitos para o ASPM também estão mudando. Simplesmente coletar os resultados dos scanners em um só lugar não é mais suficiente, a plataforma deve ajudar a responder à pergunta mais importante do desenvolvedor: "O que precisa ser corrigido agora mesmo para lançar?". E o que o ASPM da próxima geração deve ser capaz de fazer? O ASPM da próxima geração não deve apenas coletar descobertas e executar ferramentas, ele deve ajudar a tomar decisões. ASPM 1.0 ASPM 2.0 Defeito = tarefa para o desenvolvedor Defeito = sinal para análise Criticidade - como o scanner definiu Avaliação de risco levando em consideração o contexto do aplicativo Agregação / deduplicação Agregação / deduplicação / correlação CVE na árvore de dependência Função vulnerável alcançável Qualquer high/critical - corrigir imediatamente Corrigir urgentemente apenas high/critical alcançável e confirmado O desenvolvedor entende por conta própria AppSec traz um cenário de exploração confirmado ASPM 2.0 - não é apenas agregação, é um modelo de risco condicionalmente comprovado, cuja fórmula pode ser assim: Risco = defeito × capacidade de exploração × criticidade do serviço × capacidade de exploração × consequências Se houver um defeito inatingível que esteja fora do ambiente de produção e não esteja associado a um serviço crítico, esta não é uma razão para derrubar o lançamento, é quase certamente um candidato para dívida técnica ou refatoração planejada. Se o defeito for alcançável, estiver em um serviço público, afetar dados confidenciais e tiver um cenário de exploração claro - isso é o que precisa ser eliminado agora mesmo. O que fazer com as outras descobertas? A importância da correlação e da capacidade de exploração não significa que todos os defeitos inatingíveis possam ser descartados e esquecidos. A identificação do tipo "inatingível = não importante" é inaceitável. Um defeito inatingível hoje pode se tornar alcançável após um novo recurso, refatoração ou abertura de uma API interna para fora. Uma dependência vulnerável que não está sendo usada agora pode começar a ser usada em um mês, e uma dependência que hoje parece não explorável pode ter um exploit funcional amanhã. Portanto, esses problemas não desaparecem. Eles se movem para outra categoria - dívida técnica. Esta não é uma tentativa de varrer o problema para debaixo do tapete, mas uma forma de separar honestamente as ameaças urgentes e a rotina de engenharia planejada. Conclusão O futuro do ASPM não é coletar todos os resultados da varredura em uma "janela única", que já se tornou uma base. O futuro é correlacionar esses resultados entre si e mostrar quais deles realmente criam um risco. Os desenvolvedores devem eliminar ameaças reais, não potenciais, mas os outros defeitos não devem ser ignorados, eles precisam ser honestamente transferidos para dívida técnica ou refatoração. A IA neste modelo é necessária não para detectar ainda mais defeitos, já os temos em quantidade suficiente, como descobrimos. Sua tarefa é ajudar o ASPM a fazer o que a simples agregação não pode fazer: conectar os resultados das ferramentas integradas entre si. E se tudo for chamado de vulnerabilidade crítica, o desenvolvimento para de acreditar no AppSec, e quando o AppSec chega não com outro "high/crit", mas com uma explicação de por que exatamente esse problema é alcançável, onde ele se manifesta e como pode terminar, a conversa se torna completamente diferente. Obrigado a todos que leram o artigo até o fim. E agora, honestamente: os desenvolvedores já perguntaram a você do banco de trás "o que realmente precisa ser consertado?", ou a máquina só está ganhando velocidade? PURP - Canal do Telegram, onde a segurança cibernética é revelada de ambos os lados das barricadas t.me/purp_sec — insights e insights do mundo do hacking ético e proteção orientada a negócios de especialistas da Bastion Tags: aspm devsecops application security ssdlc desenvolvimento seguro segurança da informação IA em segurança cibernética gerenciamento de vulnerabilidades segurança de aplicativos Hubs: Blog da Empresa Bastion Segurança da Informação Gerenciamento de Desenvolvimento DevOps Empresas de TI 0 0 0 64K+ Alcance em 30 dias Bastion Site 14 Karma Artem Puzankov @puzankov7 Head of Secure Development Consulting Inscrever-se Telegram O fluxo Segurança da Informação está disponível 24 horas por dia, 7 dias por semana, graças ao apoio de amigos do Habr Habr Cursos para todos PUBLICIDADE Prática, Hexlet, SkyPro, cursos do autor - reunimos todos e pedimos descontos. Resta escolher! Ir Ir para o fluxo Segurança da Informação Comentar Melhor do dia Semelhante