Produto
Tudo o que precisa para proteger o código, a nuvem e o tempo de execução - num único sistema central
Código
Dependências
Prevenir riscos de código aberto (SCA)
Secrets
Apanhar secrets expostos
SAST
Código seguro tal como está escrito
Imagens Container
Proteger imagens facilmente
Malware
Prevenir ataques à cadeia de abastecimento
Infraestrutura como código
Verificar se há erros de configuração no IaC
Risco de licença e SBOMs
Evite riscos, cumpra as normas
Software desatualizado
Conheça os seus tempos de execução EOL
Cloud
Cloud / CSPM
Configurações incorrectas Cloud
DAST
Testes de segurança de caixa negra
Verificação da API
Teste as suas APIs para detetar vulnerabilidades
Máquinas virtuais
Sem agentes, sem despesas gerais
Defender
Proteção em tempo de execução
Firewall na aplicação / WAF
Caraterísticas
AI AutoFix
Correcções com um clique com a IA do Aikido
Segurança CI/CD
Análise antes da fusão e da implantação
Integrações IDE
Obtenha feedback instantâneo enquanto codifica
Scanner no local
Digitalização local com prioridade à conformidade
Soluções
Casos de utilização
Conformidade
Automatize SOC 2, ISO e muito mais
Gestão de vulnerabilidades
Gestão de vulnerabilidades tudo-em-um
Proteja o seu código
Segurança de código avançada
Gerar SBOMs
1 clique Relatórios SCA
ASPM
AppSec de ponta a ponta
CSPM
Segurança de ponta a ponta na nuvem
IA no Aikido
Deixe a IA do Aikido fazer o trabalho
Bloco 0-Dias
Bloquear ameaças antes do impacto
Indústrias
FinTech
Tecnologia da saúde
HRTech
Tecnologia jurídica
Empresas do Grupo
Agências
Startups
Empresa
Aplicações móveis
Fabrico
Preços
Recursos
Programador
Documentos
Como utilizar o Aikido
Documentos públicos da API
Centro de desenvolvimento de Aikido
Registo de alterações
Ver o que foi enviado
Segurança
Investigação interna
Informações sobre malware e CVE
Aprender
Academia de Segurança de Software
Centro de Confiança
Seguro, privado, conforme
Blogue
As últimas mensagens
Código aberto
Aikido Intel
Feed de ameaças de malware e OSS
Zen
Proteção da firewall na aplicação
OpenGrep
Motor de análise de código
Integrações
IDEs
Sistemas de CI/CD
Clouds
Sistemas Git
Conformidade
Mensageiros
Gestores de tarefas
Mais integrações
Sobre
Sobre
Sobre
Conheça a equipa
Carreiras
Estamos a contratar
Kit de imprensa
Descarregar activos da marca
Calendário
Vemo-nos por aí?
Código aberto
Os nossos projectos OSS
Histórias de clientes
A confiança das melhores equipas
Programa de parceiros
Seja nosso parceiro
Contacto
Iniciar sessão
Comece de graça
Não é necessário CC
Aikido
Menu
Aikido
EN
EN
FR
JP
DE
PT
Iniciar sessão
Comece de graça
Não é necessário CC
Aprender
/
Centro de Quadros de Conformidade
/
Capítulo 1Capítulo 2Capítulo 3

OWASP ASVS

4minutos de leitura90

Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior

TL;DR

O OWASP ASVS é uma lista de verificação detalhada e orientada para a comunidade para verificar a segurança das aplicações Web - utilizada por programadores, testadores e arquitectos.

Abrange áreas como AuthN, AuthZ, criptografia, segurança de API - dividida em L1 (básica) a L3 (aplicações críticas).

Não é um certificado, mas é ideal para definir linhas de base de segurança, orientar testes de intrusão ou criar aplicações seguras a partir do zero.

Resumo do quadro de pontuação do OWASP ASVS:

  • Esforço do desenvolvedor: Moderado a elevado (requer a compreensão dos controlos de segurança detalhados em muitos domínios e a sua correta implementação durante o desenvolvimento; utilizado como referência durante os testes).
  • Custo das ferramentas: Baixo a moderado (a norma em si é gratuita; os custos estão relacionados com as ferramentas utilizadas para efetuar testes em relação aos requisitos ASVS - SAST, DAST, IAST, ferramentas de teste de penetração).
  • Impacto no mercado: elevado (norma do sector amplamente respeitada para a verificação da segurança das aplicações Web; frequentemente utilizada como base para definir os requisitos de segurança e os âmbitos dos ensaios).
  • Flexibilidade: elevada (os níveis permitem uma adaptação em função do risco; os requisitos específicos podem ser considerados não aplicáveis).
  • Intensidade da auditoria: N/A (Não é uma norma de auditoria formal para certificação, mas é utilizada durante avaliações/testes de segurança que podem ser intensos).

O que é o OWASP ASVS?

O OWASP Application Security Verification Standard (ASVS) é um projeto de código aberto que fornece uma estrutura de requisitos e controlos de segurança especificamente para verificar a segurança das aplicações Web. Tem dois objectivos principais:

  1. Para programadores: Fornece uma lista pormenorizada de requisitos de segurança para orientar práticas de desenvolvimento seguras.
  2. Para testadores: Fornece uma base para testar os controlos de segurança técnica de aplicações Web durante avaliações de segurança, testes de penetração ou revisões de código seguro.

O OWASP ASVS está estruturado em capítulos que abrangem os principais domínios de segurança:

  • V1: Arquitetura, conceção e modelação de ameaças
  • V2: Autenticação
  • V3: Gestão de sessões
  • V4: Controlo de acesso
  • V5: Validação, Sanitização e Codificação
  • V6: Criptografia armazenada
  • V7: Tratamento de erros e registo
  • V8: Proteção de dados
  • V9: Segurança das comunicações
  • V10: Código malicioso
  • V11: Lógica comercial
  • V12: Ficheiro e recursos
  • V13: API e serviço Web
  • V14: Configuração

Em cada capítulo, são listados os requisitos de verificação específicos (controlos). Crucialmente, o OWASP ASVS define três Níveis de Verificação de Segurança (Níveis ASVS), indicando níveis crescentes de profundidade e rigor:

  • Nível 1 (Baixa garantia): Destinado a aplicações de baixo risco ou como um primeiro passo. Centra-se em vulnerabilidades e controlos facilmente detectáveis que podem frequentemente ser verificados automaticamente (por exemplo, testes de penetração básicos). Todas as aplicações devem ter como objetivo, pelo menos, o nível 1.
  • Nível 2 (garantia padrão): Recomendado para a maioria das aplicações, especialmente as que lidam com dados sensíveis ou realizam transacções importantes. Requer verificações mais aprofundadas que abrangem a proteção contra riscos comuns de segurança das aplicações (como o OWASP Top 10). Requer testes automatizados e manuais, incluindo elementos de revisão de design/código.
  • Nível 3 (Alta garantia): Para aplicações críticas que lidam com dados altamente sensíveis (por exemplo, finanças, saúde, governo). Requer uma verificação de segurança abrangente, incluindo uma análise aprofundada da conceção, uma análise do código e testes rigorosos para resistir a atacantes qualificados.

O nível exigido determina quais os requisitos de verificação específicos de cada capítulo que devem ser cumpridos.

Porque é que é importante?

O OWASP ASVS é uma pedra angular da segurança moderna das aplicações Web porque:

  • Fornece padronização: Oferece um padrão consistente e repetível para o que constitui uma aplicação Web segura, indo além dos testes ad-hoc.
  • Orientação acionável: Dá aos programadores requisitos concretos e aos testadores itens específicos para verificar, colmatando a lacuna entre os princípios de alto nível e a implementação.
  • Abordagem baseada em risco: O sistema de níveis permite que as organizações adaptem os esforços de verificação com base no perfil de risco da aplicação.
  • Complementa o OWASP Top 10: Enquanto o Top 10 lista os riscos comuns, o ASVS fornece os controlos detalhados necessários para mitigar esses riscos (e muitos outros).
  • Reconhecimento do sector: Amplamente respeitado e utilizado globalmente por programadores, profissionais de segurança e organizações que adquirem software.
  • Suporta o SDLC seguro: Pode ser integrado em todo o SDLC - definindo requisitos, orientando a conceção/codificação e formando a base para os testes de verificação.
  • Código aberto e orientado para a comunidade: Disponível gratuitamente e constantemente atualizado por uma comunidade global de especialistas em segurança.

A utilização do OWASP ASVS ajuda a garantir que os testes de segurança são completos, consistentes e centrados nos controlos que realmente importam para proteger as aplicações Web.

O que e como implementar (técnica e política)

Implementar o OWASP ASVS não é obter a certificação; é usar o padrão para criar e verificar aplicativos seguros:

  1. Determinar o nível necessário: Com base na sensibilidade dos dados da aplicação, na criticidade do negócio e nos requisitos regulamentares, escolha o nível ASVS pretendido (1, 2 ou 3).
  2. Integrar nos requisitos (fase de conceção): Utilizar os requisitos ASVS para o nível escolhido (e capítulos relevantes) como contributo para os requisitos de segurança durante as fases de conceção e planeamento.
    • Exemplo (Controlo de Acesso V4): Se criar uma aplicação que exija diferentes funções de utilizador, reveja os requisitos do Capítulo V4 da ASVS, como o V4.1.1 ("Verifique se a aplicação aplica regras de controlo de acesso numa camada de serviço fiável...") e conceba o sistema em conformidade.
  3. Desenvolvimento do guia (fase de codificação): Os programadores utilizam os requisitos ASVS como uma lista de verificação para garantir que são seguidas práticas de codificação seguras.
    • Exemplo (validação de entrada V5): Ao criar formulários de entrada, consulte os requisitos da V5, como V5.1.1 ("Verificar se a aplicação tem defesas contra poluição de parâmetros HTTP...") e V5.2.1 ("Verificar se os dados estruturados são fortemente tipados..."). Implemente bibliotecas e rotinas de validação de entrada que cumpram estes requisitos.
  4. Informar os testes de segurança (fase de verificação): Os testadores de segurança (pen testers, revisores de código) utilizam a lista de verificação ASVS para o nível-alvo para estruturar a sua avaliação. Verificam se cada requisito aplicável foi cumprido.
    • Exemplo (Autenticação V2): Um testador que verifica o Nível 2 verificaria requisitos como V2.2.1 ("Verificar se o comprimento mínimo da palavra-passe é de 12 caracteres..."), V2.1.1 ("Verificar se as credenciais nunca são armazenadas de forma recuperável...") e V2.4.1 ("Verificar se existe um mecanismo de bloqueio de conta...").
  5. Integração de ferramentas:
    • Ferramentas SAST/DAST: Configurar scanners para verificar violações relacionadas com os requisitos ASVS (por exemplo, encontrar potenciais falhas de injeção relacionadas com a V5).
    • Gestão de listas de verificação: Utilize folhas de cálculo ou ferramentas como o SecurityRAT para gerir os requisitos ASVS, acompanhar a aplicabilidade e registar os resultados da verificação.
  6. Documentação: Documentar como os requisitos ASVS foram cumpridos (ou porque foram considerados não aplicáveis) como parte dos documentos de projeto, comentários de código e relatórios de teste.

A implementação consiste em utilizar ativamente a lista ASVS ao longo do SDLC - como um guia para construir com segurança e uma lista de verificação para verificar a segurança.

Erros comuns a evitar

Ao utilizar o OWASP ASVS, tenha em atenção estes erros comuns:

  1. Escolher o nível errado: Selecionar o Nível 1 para uma aplicação de alto risco, ou apontar para o Nível 3 quando os recursos apenas permitem a verificação do Nível 2, conduzindo a avaliações inadequadas ou incompletas.
  2. Tratando-o apenas como uma lista de verificação de pentest: O ASVS é mais amplo do que apenas pentesting; os níveis 2 e 3 exigem aspectos de design e revisão de código. Confiar apenas no controlo dinâmico não permite detetar vulnerabilidades cruciais.
  3. Ignorar a aplicabilidade: Tentar aplicar cegamente todos os requisitos sem considerar se são relevantes para a arquitetura, pilha de tecnologia ou funcionalidades da aplicação específica.
  4. Falta de formação dos programadores: Esperar que os programadores cumpram os requisitos ASVS sem os formar nos conceitos de segurança subjacentes e nas práticas de codificação seguras necessárias.
  5. Aplicação inconsistente: Aplicar o ASVS rigorosamente durante um teste, mas superficialmente durante o teste seguinte, levando a uma postura de segurança inconsistente.
  6. Não integração precoce: Utilizar o ASVS apenas no final para testar, em vez de o utilizar para informar a conceção e o desenvolvimento seguros desde o início (o que é muito mais eficaz).
  7. Interpretação incorrecta dos requisitos: Não compreender a nuance ou intenção por detrás de requisitos específicos de verificação ASVS.

O que os auditores/testadores perguntarão (foco no desenvolvedor)

Os testadores de segurança que utilizam o OWASP ASVS pedem essencialmente aos programadores (diretamente ou através da revisão do código/design) que demonstrem como os requisitos específicos são cumpridos:

  • (V1) "Pode mostrar-me o modelo de ameaça para esta aplicação?" (1.1.1 - L2+)
  • (V2) "Como são armazenadas as palavras-passe dos utilizadores? Pode mostrar a implementação do hashing?" (2.2.2 - L1+)
  • (V3) "Como é que os tokens de sessão são gerados e protegidos contra a pirataria?" (3.1.1, 3.3.1 - L1+)
  • (V4) "Demonstrar como a aplicação impede um utilizador normal de aceder à funcionalidade de administração." (4.1.1, 4.1.2 - L1+)
  • (V5) "Mostre-me as rotinas de validação de entrada utilizadas para este ponto final crítico da API". (5.1.3, 5.2.1 - L1+)
  • (V6) "Onde e como são geridas as chaves criptográficas na aplicação?" (6.2.1 - L2+)
  • (V7) "Como é que a aplicação trata os erros sem deixar escapar informações sensíveis?" (7.1.1 - L1+)
  • (V8) "Como são protegidos os dados sensíveis quando armazenados na base de dados (encriptação, mascaramento)?" (8.1.1 - L2+)
  • (V13) "Como é que a autenticação e a autorização são tratadas para os pedidos de API?" (13.1.1, 13.2.1 - L1+)

Procurarão provas concretas no código, na configuração, nos documentos de conceção ou na aplicação em execução para verificar a conformidade com cada requisito ASVS relevante para o nível-alvo.

Ganhos rápidos para as equipas de desenvolvimento

Os programadores podem começar a incorporar facilmente os princípios do OWASP ASVS:

  1. Concentre-se nos princípios básicos do Nível 1: Comece por rever e implementar os requisitos de nível 1 em áreas-chave como a autenticação (V2), o controlo de acesso (V4) e a validação de entrada (V5). Estes cobrem muitas falhas comuns.
  2. Usar padrões de estrutura segura: Aproveite os recursos de segurança integrados da sua estrutura da Web (por exemplo, para gerenciamento de sessão, proteção CSRF, codificação de saída) que geralmente se alinham com o ASVS.
  3. Validar e codificar: Validar consistentemente todas as entradas e codificar todos os resultados destinados a navegadores, APIs ou bases de dados. (Núcleo da V5)
  4. Implementar o registo básico: Assegurar que os principais eventos de segurança (logins, falhas, transacções significativas) são registados. (Essencial da V7)
  5. Revisar o OWASP Top 10: Compreender os 10 principais riscos e como os controlos ASVS ajudam a mitigá-los.
  6. Utilizar ferramentas SAST: Configurar as ferramentas SAST para assinalar violações relacionadas com requisitos ASVS comuns (por exemplo, manuseamento inseguro de palavras-passe, potenciais pontos de injeção).

Ignorar isto e... (Consequências do incumprimento)

Ignorar os princípios e requisitos descritos no OWASP ASVS significa negligenciar os controlos fundamentais de segurança das aplicações Web. As consequências são diretas:

  • Maior probabilidade de violações: As aplicações serão mais vulneráveis a ataques comuns, como XSS, injeção de SQL, autenticação deficiente, controlo de acesso deficiente, etc. (diretamente relacionados com os capítulos ASVS).
  • Perda/roubo de dados: As vulnerabilidades permitem que os atacantes roubem dados sensíveis dos utilizadores, conduzindo a violações da privacidade e a multas regulamentares (por exemplo, RGPD).
  • Perturbação do serviço: Os ataques podem colocar as aplicações offline, causando perturbações no negócio e perda de receitas.
  • Danos à reputação: Os incidentes de segurança afectam a confiança dos clientes e prejudicam a marca da empresa.
  • Auditorias/Pentestes de segurança falhados: Se os clientes ou parceiros exigirem testes de segurança, uma aplicação que não tenha sido criada com os princípios ASVS em mente irá provavelmente falhar, bloqueando potencialmente negócios ou implementações.
  • Aumento dos custos de correção: Encontrar e corrigir vulnerabilidades numa fase tardia do ciclo ou após uma violação é muito mais dispendioso do que criar segurança utilizando o ASVS como guia.

Essencialmente, não aderir ao OWASP ASVS significa criar aplicações Web inerentemente inseguras.

FAQ

O OWASP ASVS é uma norma de conformidade como o SOC 2 ou a ISO 27001?

Não. A OWASP ASVS é uma norma de verificação, essencialmente uma lista de verificação pormenorizada para testar a segurança das aplicações Web. Não envolve auditorias formais ou certificações como SOC 2 ou ISO 27001, que abrangem sistemas de gestão mais amplos. No entanto, o cumprimento dos níveis ASVS pode ajudar a satisfazer os requisitos de controlo técnico dentro dessas estruturas mais amplas.

Qual é a diferença entre o OWASP ASVS e o OWASP Top 10?

O OWASP Top 10 lista os dez riscos mais críticos para a segurança das aplicações Web com base em dados e consensos da comunidade. O OWASP ASVS fornece os controlos de segurança detalhados e os requisitos de verificação necessários para prevenir e testar esses riscos (e muitos outros). O Top 10 diz-lhe quais são os principais problemas; o ASVS diz-lhe como verificar as suas defesas contra eles.

Qual o nível ASVS a que devemos aspirar?

Depende do risco. O nível 1 é a base de referência mínima para todas as aplicações. O nível 2 é recomendado para a maioria das aplicações que lidam com dados ou transacções sensíveis. O nível 3 destina-se a aplicações altamente críticas em que uma falha tem consequências graves (por exemplo, dados financeiros e de saúde).

É necessário cumprir 100% dos requisitos para um determinado nível?

Em geral, sim, para todos os requisitos aplicáveis. A norma permite que os requisitos sejam assinalados como "Não Aplicável" se não se aplicarem efetivamente à tecnologia ou funcionalidade da aplicação, mas tal exige uma justificação. Por vezes, podem ser aceites controlos de compensação se um requisito específico não puder ser cumprido diretamente.

O ASVS destina-se apenas a testes de penetração?

Não. Embora sejam muito utilizados em testes de penetração (especialmente no Nível 1), os Níveis 2 e 3 do ASVS exigem explicitamente uma verificação para além dos testes dinâmicos, incluindo revisões da arquitetura, da conceção e do código-fonte. Destina-se à verificação holística da segurança da aplicação.

Com que frequência devemos efetuar a verificação em relação ao ASVS?

A verificação deve ser integrada no SDLC. Isto pode significar a verificação dos requisitos relevantes durante as revisões de código, a execução de testes automatizados alinhados com o ASVS em CI/CD e a realização de avaliações ASVS completas (ao nível do objetivo) antes dos principais lançamentos ou periodicamente (por exemplo, anualmente) para aplicações críticas.

O ASVS pode ser utilizado para APIs e aplicações móveis?

O capítulo V13 do OWASP ASVS aborda especificamente a verificação de APIs e serviços Web. Embora se concentre principalmente em aplicações Web, muitos princípios aplicam-se de forma geral. Para aplicações móveis específicas, a OWASP também tem a Norma de Verificação de Segurança de Aplicações Móveis (MASVS).

Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Capítulo seguinte
Capítulo anterior
Saltar para:
Ligação de texto

Segurança bem feita.
Confiado por mais de 25 mil organizações.

Comece de graça
Não é necessário CC
Marcar uma demonstração
Partilhar:

www.aikido.dev/learn/software-security-tools/owasp-asvs

Índice

Capítulo 1: Compreender os quadros de conformidade

O que são quadros de conformidade e qual a sua importância?
Como as estruturas de conformidade afectam os fluxos de trabalho DevSecOps
Elementos comuns a todos os quadros de referência

Capítulo 2: Principais estruturas de conformidade explicadas

Conformidade SOC 2
ISO 27001
ISO 27017 / 27018
NIST SP 800-53
NIST SSDF (SP 800-218)
OWASP ASVS
RGPD
Diretiva NIS2
DORA
Ato da UE sobre a ciber-resiliência (CRA)
CMMC
PCI DSS
FedRAMP
HIPAA / HITECH
Oito essenciais
CCoP de Singapura (para a CII)
Lei sobre a cibersegurança no Japão e afins (APPI)

Capítulo 3: Implementando a Conformidade no Desenvolvimento

Escolher as estruturas corretas para a sua organização
Criar pipelines DevSecOps compatíveis
Formação de Equipas de Desenvolvimento para Conformidade
Preparação de auditorias para promotores
Manter a conformidade a longo prazo
O fim

Publicações do blogue relacionadas

Ver tudo
Ver tudo
4 de junho de 2024
-
Conformidade

Certificação SOC 2: 5 coisas que aprendemos

O que aprendemos sobre o SOC 2 durante a nossa auditoria. ISO 27001 vs. SOC 2, por que razão o Tipo 2 faz sentido e como a certificação SOC 2 é essencial para os clientes dos EUA.

16 de janeiro de 2024
-
Conformidade

NIS2: Quem é afetado?

A quem se aplica a NIS2? Quem é afetado? Quais são os sectores essenciais e importantes e os limites de dimensão das empresas? A aplicação Aikido tem uma funcionalidade de relatório NIS2.

5 de dezembro de 2023
-
Conformidade

Certificação ISO 27001: 8 coisas que aprendemos

O que gostaríamos de ter sabido antes de iniciar o processo de conformidade com a ISO 27001:2022. Aqui estão nossas dicas para qualquer empresa de SaaS que esteja buscando a certificação ISO 27001.

Empresa
ProdutoPreçosSobreCarreirasContactoSeja nosso parceiro
Recursos
DocumentosDocumentos públicos da APIBase de dados de vulnerabilidadesBlogueIntegraçõesGlossárioKit de imprensaComentários de clientes
Segurança
Centro de ConfiançaVisão geral da segurançaAlterar as preferências de cookies
Jurídico
Política de privacidadePolítica de cookiesTermos de utilizaçãoContrato Principal de SubscriçãoAcordo de processamento de dados
Casos de utilização
ConformidadeSAST E DASTASPMGestão de vulnerabilidadesGerar SBOMsSegurança do WordPressProteja o seu códigoAikido para a MicrosoftAikido para AWS
Indústrias
Para a HealthTechPara a MedTechPara a FinTechPara SecurityTechPara a LegalTechPara HRTechPara as agênciasPara empresasPara empresas de capital de risco e de grupo
Comparar
vs Todos os fornecedorescontra Snykcontra Wizvs Mendvs Orca Securityvs Veracodevs GitHub Advanced Securityvs GitLab Ultimatevs Checkmarxvs Semgrepvs SonarQube
Ligar
hello@aikido.dev
LinkedInX
Subscrever
Mantenha-se a par de todas as actualizações
Ainda não é o caso.
👋🏻 Obrigado! Está inscrito.
Equipa de Aikido
Ainda não é o caso.
© 2025 Aikido Security BV | BE0792914919
🇪🇺 Endereço registado: Coupure Rechts 88, 9000, Ghent, Bélgica
🇪🇺 Endereço do escritório: Gebroeders van Eyckstraat 2, 9000, Ghent, Bélgica
🇺🇸 Endereço do escritório: 95 Third St, 2nd Fl, São Francisco, CA 94103, EUA
SOC 2
Conformidade
ISO 27001
Conformidade