O modelo do queijo suíço é uma forma clássica de raciocinar sobre risco. Em indústrias de segurança crítica, ele postula que incidentes ocorrem quando “falhas” em múltiplas defesas imperfeitas se alinham. Para mitigar esses riscos, você adiciona camadas de defesa para reduzir ou remover as falhas e evitar que resultados indesejados passem despercebidos.
Em segurança de aplicações, incidentes são causados não apenas por explorações de código e configuração, mas também por uma erosão do foco de engenharia causada por falsos positivos e remediação lenta. O gerenciamento de vulnerabilidades é igualmente um problema de engenharia e processo, e Aikido adota uma abordagem estratégica para reduzir o ruído e acelerar as correções que importam.
A importância da defesa em camadas
Podemos visualizar um fluxo de trabalho AppSec moderno como incluindo um conjunto de “fatias” empilhadas, cada uma projetada para detectar diferentes tipos de problemas e reduzir a superfície de risco geral. Estes incluem:
- Scanning de código e reachability
- análise de explorabilidade que verifica se um atacante consegue cumprir as condições necessárias para que a falha cause danos
- Triagem de issues para avaliar explorabilidade, prioridade e impacto
- Probabilidade de exploração e seu contexto de ambiente
- Controles human-in-the-loop (IDEs locais, sistemas de CI, fluxos de aprovação de PR)
- A correção real do código usando humanos e LLMs
Cada um dos itens acima pode representar tanto um ponto fraco explorável quanto um gargalo para a remediação. Os fluxos de trabalho de Aikido são, portanto, direcionados a reduzir implacavelmente o atrito para que vulnerabilidades reais sejam remediadas onde são mais exploráveis.
Reduza as falhas com reachability
Um ponto fraco do scanning de código tradicional é que o “sucesso” pode ser mal interpretado como encontrar o maior número possível de issues. Isso inclui descobertas relatadas como vulnerabilidades mesmo quando o caminho de código vulnerável ou pacote não pode ser alcançado a partir de entradas controladas pelo usuário. O motor de reachability de Aikido adiciona análise de fluxo de programa para ignorar automaticamente tais casos logo de início. Isso por si só elimina uma parte significativa do ruído.
Por exemplo, um scanner SCA tradicional pode detectar uma versão desatualizada de pyyaml contendo uma vulnerabilidade crítica. No entanto, Reachability analysis mostra que não há nenhum código que realmente utilize o pacote. Portanto, a issue pode ser seguramente auto-ignorada apesar de sua severidade documentada.
A acessibilidade funciona a dois níveis.
- A verificabilidade ao nível da dependência verifica se o seu código importa ou utiliza, de alguma forma, o pacote vulnerável. Isto filtra os pacotes que apenas constam no seu ficheiro de bloqueio como dependências transitivas não utilizadas.
- A acessibilidade ao nível da função vai mais além e verifica se o seu código chama a função específica que contém o erro; assim, uma aplicação que utilize apenas uma biblioteca XML para gerar documentos é isenta de responsabilidade relativamente a um CVE no analisador dessa biblioteca.
Como o « Aikido » verifica se um CVE é explorável
No entanto, o código acessível não é necessariamente explorável. O código acessível pode continuar a ser seguro quando um atacante não consegue cumprir as condições necessárias para que a falha se ative. A maioria das vulnerabilidades requer mais do que a execução da função. É necessária uma entrada controlada pelo atacante para que esta assuma uma forma específica, que uma determinada configuração ou funcionalidade esteja ativada, ou que um nível de privilégio específico possa realmente causar danos.
AikidoO CVE análise de explorabilidade analisa o código do repositório juntamente com o contexto associado container , incluindo o Dockerfile, a imagem base, a distribuição e a forma como o container está a ser executado. Utiliza o AgenteAikido , que analisa a forma como o pacote vulnerável é utilizado no seu código ou na imagem container e determina se a vulnerabilidade é explorável no seu ambiente. O agente executa então as ações de triagem que autorizar, que podem ser «ignorar», «adiar», «reverter para uma versão anterior» ou «atualizar». Cada decisão é acompanhada de uma justificação por escrito do agente, que o revisor pode ler antes de aprovar.
Além da acessibilidade, o CVE análise de explorabilidade reduz os falsos positivos nas dependências de código aberto em até 100%. Pode ver como as camadas funcionam em conjunto na páginaAikido SCA .
A acessibilidade indica que esta falha de segurança está presente no código. No entanto, a análise de IA determina que, neste contexto, esta vulnerabilidade de falsificação de pedidos não tem qualquer efeito, uma vez que o domínio do anfitrião está codificado de forma fixa e não pode ser alterado pelo atacante.
Pode ativar o CVE análise de explorabilidade para os seus repositórios e contentores associados a partir das definições de triagem em Aikido. O guia de configuração explica passo a passo como escolher um âmbito e as ações que o agente pode realizar.
Probabilidade de exploração e contexto do ambiente
Aikido recorre ao Sistema de Pontuação de Previsão de Exploração (EPSS), que estima a probabilidade de um CVE ser explorado em ambiente real nos próximos 30 dias, e utiliza-o para ignorar ou rebaixar a classificação daqueles que os atacantes não estão a explorar. Como o EPSS é atualizado diariamente, esta camada mantém a pilha alinhada com a realidade atual das ameaças, em vez de se basear em pontuações CVSS históricas.
análise de explorabilidade analisa o seu código e a configuração do container para determinar se um bug pode, de todo, ser acionado. O contexto do ambiente determina a importância que isso tem, quando tal for possível. O mesmo CVE é reclassificado para um nível superior num serviço de produção exposto à Internet e reclassificado para um nível inferior num ambiente de desenvolvimento interno protegido por outras medidas de controlo. É aqui que a recolha de contexto se torna fundamental. Se o contexto estiver errado, a decisão sobre a gravidade estará errada. É por isso que investimos no ajuste imediato dos nossos LLMs e na integração dos detalhes corretos do código e do ambiente nos modelos que executam o AutoTriage.
AutoTriage para o « SAST » como porta de raciocínio
Enquanto o análise de explorabilidade reduz o ruído nos pacotes de código aberto em até 100%, o AutoTriage solicita o seguinte relativamente às conclusões do SAST e ao nível do código:
- Podemos descartar a explorabilidade? Ou seja, existe validação, sanitização ou casting eficaz que mitigue a exploração.
- Se não pudermos descartá-la, como devemos priorizá-la? Estimamos a probabilidade e a severidade e, em seguida, classificamos de acordo.
Nós publicamos anteriormente como modelos de raciocínio ajudam aqui. Em muitos casos, “regras de bolso” são suficientes (e mais baratas). Para casos mais complexos (por exemplo, path traversals), modelos de raciocínio reduzem ainda mais os falsos positivos ao decompor o problema.
A base de tudo isso é uma consciência aguçada do efeito 'Cry Wolf', onde muitos alertas de baixo valor degradam a confiança e a resposta. Reduzi-lo é um objetivo principal do AutoTriage.
Humano no ciclo onde importa
A IA generativa tem um problema de loop de feedback bem documentado. Os humanos ainda são necessários para verificar os resultados e, em última instância, decidir se devem ser lançados. Aikido intencionalmente apresenta suas recomendações nos locais onde sua equipe já trabalha:
- No seu IDE para que você possa fazer correções rápidas antes de enviar para um repositório compartilhado e executar pipelines de CI
- Em PRs para que os revisores vejam o contexto de triagem e as sugestões de AutoFix assim que o código for alterado,
- Em CI, para que você possa colocar a segurança no contexto de seus pipelines automatizados existentes de build, teste e deploy
O objetivo é reservar tempo, esforço e julgamento humanos para os locais onde são realmente necessários.
AutoFix para lançar correções imediatamente
Se uma descoberta for provavelmente explorável e de alto impacto, o melhor alerta é aquele que inclui uma correção documentada com o contexto já montado pelo Aikido. Aikido AI AutoFix fornece uma prévia da mudança necessária para corrigir, gera o pull request para o seu repositório e oferece comentários detalhados sobre a alteração do código e quais vulnerabilidades são resolvidas.
AutoFix está atualmente disponível para SAST, varredura IaC, SCA e imagens Container. Seu código nunca é armazenado persistentemente por uma tecnologia de IA nem permitido para ser usado para treinar modelos de IA (consulte o trust center do Aikido para saber mais).
Colocando o Aikido para funcionar
O modelo original do queijo suíço ensina que os incidentes surgem de fraquezas alinhadas. Na segurança de aplicações, ruído e atraso são duas dessas fraquezas. Se você é novo no Aikido, inicialmente pode se perguntar por que vê menos problemas de segurança sendo apresentados do que esperaria. Isso é intencional! Aikido trabalha intencionalmente e proativamente para minimizar o trabalho administrativo que você deve realizar para triar centenas de problemas onde apenas alguns podem ter um impacto significativo.
Ao sobrepor alcançabilidade, triagem orientada por raciocínio, validação humana quando justificada e correções com um clique, tornamos muito mais difícil para esses "buracos" se alinharem e muito mais fácil para sua equipe avançar para o trabalho que realmente importa.
