Cada pull request Adicionar ou alterar um endpoint modifica a superfície de ataque da sua API. A maioria das ferramentas de segurança de API só percebe isso quando o endpoint já está ativo e recebendo tráfego. Nesse ponto, a correção deixa de ser uma simples alteração de uma linha em uma revisão de código e passa a ser uma conversa de resposta a incidentes.
A segurança de APIs é a prática de encontrar e eliminar os riscos na forma como uma aplicação expõe seus endpoints: quem pode chamá-los, quais dados eles retornam e se eles fazem o que a documentação diz que fazem.
A maioria das ferramentas criadas para resolver esse problema testa a API em tempo de execução, externamente, da mesma forma que um atacante faria. Essa abordagem funciona, mas somente depois que a API é implantada. Xygeni Adota o caminho anterior: lê o seu código-fonte e a especificação da sua API antes mesmo de uma única solicitação chegar ao endpoint.
As quatro maneiras de testar uma API e o que cada uma delas responde.
A maioria dos programas consolidados utiliza mais de um destes:
- Teste estático Analisa o código-fonte e as especificações da API antes da implantação. Responde à pergunta "o que acabamos de expor?". É nessa abordagem que este artigo se concentra.
- Teste dinâmico (DAST) Envia tráfego real para uma API em execução e observa como ela responde. Responde à pergunta: "O que está realmente acessível e explorável neste momento?"
- Confuso Lança entradas malformadas ou inesperadas nos pontos de extremidade para revelar falhas e casos extremos. Responde à pergunta: "O que falha sob entrada que não previmos?"
- Teste de penetração manual Adiciona julgamento humano para encontrar falhas lógicas que as ferramentas automatizadas não percebem. Responde à pergunta: "Que tipo de conexão um atacante inteligente faria?"
Nenhuma delas substitui as outras. Elas respondem a perguntas diferentes em pontos diferentes do ciclo de vida, e a lacuna que a maioria dos programas apresenta é a primeira.
Por que a maioria das ferramentas de segurança de API detecta o risco tarde demais?
O teste de segurança de API em tempo de execução envia tráfego para um aplicativo em produção e observa como ele responde. É uma camada legítima e necessária. Também é, por definição, um indicador tardio: um endpoint precisa existir, estar implantado e acessível antes que um scanner em tempo de execução possa dizer algo sobre ele. Tudo o que ele encontrar já estará exposto durante o tempo que o scanner levou para ser executado.
Existe uma segunda lacuna subjacente a esse problema de sincronização. As ferramentas de tempo de execução só podem testar o que sabem que existe. Se um endpoint nunca foi documentado, ou se a especificação OpenAPI ficou desatualizada no momento em que alguém implementou uma nova rota, um scanner de tempo de execução não tem como saber que ele existe. Ele testa o mapa, não o território.
Os testes estáticos de segurança de API resolvem ambas as lacunas, movendo a verificação para onde o endpoint é definido: seu código e sua especificação de API, antes da implantação. pull request que introduz um ponto final é o pull request que expõe o seu risco.
O que significa, de fato, segurança de API estática
A Xygeni cria seu inventário de APIs a partir de duas fontes: o código-fonte do seu aplicativo e suas especificações de API, incluindo OpenAPI e Swagger.
Um inventário apenas de especificações mostra os endpoints que alguém se lembrou de documentar. Um inventário apenas de código mostra o que existe, mas não necessariamente como deveria ser usado. Ler ambos fornece uma visão completa: os endpoints que suas equipes documentaram e aqueles que ninguém documentou.
Esse inventário é a base sobre a qual tudo o mais se constrói:
- Total de APIs descobertas e ativos em risco comparados a uma linha de base.
- Pontos de extremidade classificados por método HTTP
- Problemas agrupados por serviço
- Cada endpoint com seu método, caminho, serviço, módulo, estado de autenticação e pontuação de risco.
Seus líderes de engenharia visualizam o formato da sua API sem precisar abrir um único chamado.
Cada endpoint encontrado pelo Xygeni, com seu método, estado de autenticação e pontuação de risco, foi construído a partir de código e especificação em conjunto.
Production note Recorte o painel de triagem de IA de qualquer captura de tela do API Security.
Mapeado para o Top 10 de segurança de API da OWASP.
Os resultados estão alinhados com a estrutura que suas equipes de segurança e seus auditores já utilizam. A Xygeni detecta riscos em toda a estrutura de segurança de API da OWASP. 10 principais (2023):
Uma categoria está deliberadamente ausente. A API 6, Acesso Irrestrito a Fluxos de Negócios Sensíveis, exige a compreensão do que um processo de negócios deve permitir, e nenhum analisador estático detecta isso de forma confiável. Qualquer fornecedor que afirme o contrário está vendendo apenas uma caixa de seleção. Essa categoria fica a cargo da sua modelagem de ameaças e dos seus testes de penetração.
Nem todas as descobertas são iguais: Sensibilidade dos dados e combinações tóxicas
Uma lista simples de resultados trata um endpoint de verificação de integridade não autenticado da mesma forma que um endpoint não autenticado que retorna registros de clientes. Esses não são o mesmo problema, e um modelo de priorização que os pontua da mesma maneira treina suas equipes a ignorar a lista.
A Xygeni classifica os dados que cada endpoint processa, sinalizando PII, PCI e PHI nos parâmetros de solicitação e nas respostas, e associa isso ao estado de autenticação do endpoint.
A plataforma também correlaciona descobertas que ocorrem no mesmo endpoint e aumenta a gravidade quando elas se acumulam. Um vazamento de informações pessoais identificáveis (PII) em uma resposta é uma descoberta grave por si só. O mesmo vazamento em um endpoint que não exige autenticação é crítico, e a plataforma o classifica dessa forma, em vez de deixar a conexão para que alguém a perceba manualmente.
Endpoints zumbis e órfãos: a divergência entre código e especificação
Como o Xygeni lê seu código e sua especificação de API lado a lado, ele identifica as divergências. Essa discrepância se manifesta em três padrões reconhecíveis:
- Pontos finais não documentados. Eles existem no código e nunca foram adicionados à especificação.
- Pontos finais zumbis. Estão marcados como obsoletos ou desativados, mas ainda podem ser acessados.
- Pontos finais órfãos. Ninguém da equipe atual os possui.
Nenhum desses itens aparece em um inventário somente de especificações, porque a especificação é exatamente o que está faltando.
Evidências que permitem agir, não uma multa para investigação.
Cada descoberta aponta para o manipulador exato responsável: o arquivo, a classe, o método e a linha específica que introduziu a falha, com o código problemático exibido ao lado. Cada uma também apresenta sua gravidade, sua categoria no OWASP API Security Top 10, seu CWE (Classificação de Experiência do Cliente), o estado de autenticação do endpoint e a classificação de sensibilidade dos dados envolvidos.
Uma descoberta que apenas nomeia um endpoint obriga o desenvolvedor a vasculhar o código-fonte antes mesmo de poder começar a corrigir qualquer coisa. Uma descoberta que nomeia a linha de código o coloca imediatamente no ponto de correção.
Os resultados são exportados em JSON, CSV, Markdown e SARIF 2.1.0, para que sejam armazenados no arquivo t.Ferramentas que suas equipes já utilizam.
O manipulador, a linha e o código que introduziram a vulnerabilidade. Não é um caso para investigação.
Por que isso existe em uma única plataforma, e não em outro console?
Xygeni executa segurança de API em conjunto com SAST, SCA, Segurança de Segredos, IaC e DAST dentro de uma única plataforma, correlacionados através de ASPM, em vez de enviá-lo como uma ferramenta separada com seu próprio Conecte-se e sua própria lista de pendências.
Isso é importante porque as descobertas estáticas e as descobertas em tempo de execução respondem a perguntas diferentes sobre o mesmo endpoint, e são mais úteis juntas do que separadamente. As descobertas estáticas indicam que um endpoint é arriscado antes de ser implementado. Já o DAST confirma o que é realmente acessível e explorável depois de estar em execução.
Divida isso em dois consoles e o risco correlacionado se transforma em duas listas de pendências não relacionadas. Ninguém as concilia, e o endpoint que não está documentado nem autenticado não fica em nenhuma das filas.
Veja a sua superfície de ataque real da API. A segurança da API está disponível como um Enterprise É um complemento para a plataforma Xygeni, e uma varredura é executada em seus próprios repositórios dentro de sua própria infraestrutura.
Perguntas frequentes
É possível identificar quais endpoints lidam com dados sensíveis?
Sim. O Xygeni sinaliza PII, PCI e PHI nos parâmetros e respostas dos endpoints e usa essa classificação para ordenar os resultados de acordo com a exposição real.
Ele pode funcionar em qualquer dispositivo? pull request?
Sim. A análise incremental examina apenas os endpoints que foram alterados, e o manifesto gerado permite que uma análise DAST subsequente seja direcionada para esses mesmos endpoints, garantindo que os testes estáticos e em tempo de execução permaneçam alinhados com o que realmente foi alterado.
Meu código sai do meu ambiente?
Não. As análises são executadas na sua própria infraestrutura. Somente os resultados são carregados, protegidos durante a transmissão e em repouso.
Como faço para obter segurança de API?
A segurança da API está disponível como um Enterprise Complemento. Solicite uma prova de conceito (PoC) e definiremos o escopo com você.
