Aikido

Como Cumprir o Projeto de Lei de Cibersegurança e Resiliência do Reino Unido: Um Guia Prático para Equipes de Engenharia Modernas

Escrito por
Divine Odazie

Ciberataques evoluíram além de interrupções esporádicas para se tornarem um risco sistêmico.

Hoje, um único comprometimento pode reverberar por todo o ecossistema digital, desde fornecedores e bibliotecas upstream até fornecedores de software e serviços de Cloud, muitas vezes mais rápido do que a maioria das organizações consegue responder.

Devido a essa crescente interdependência, o Reino Unido não está mais tratando a cibersegurança como algo que as organizações podem abordar com boa vontade e melhores práticas informais. 

O aumento nas violações da cadeia de suprimentos, componentes comprometidos e produtos inseguros por padrão deixou claro que os esforços voluntários de segurança não são suficientes para proteger uma economia digital altamente conectada. Muitas interrupções, violações de dados e falhas de resiliência mostraram a rapidez com que um único elo fraco pode interromper indústrias inteiras.

O Projeto de Lei de Cibersegurança e Resiliência responde a essa realidade com requisitos que são simples de declarar, mas exigentes para implementar:

  • Você deve projetar software com segurança integrada desde o início. 
  • Você deve ser transparente sobre os riscos cibernéticos em sua cadeia de suprimentos. 
  • Você deve entregar produtos com configurações seguras por padrão que não dependam da vigilância do usuário.
  • Você deve ter um processo funcional para identificar, priorizar e corrigir vulnerabilidades. 
  • Você deve ser capaz de mostrar aos reguladores evidências reais de que está cumprindo essas expectativas.

Essa mudança deixa uma coisa clara: você não pode mais depender de planilhas, scanners isolados ou listas de verificação reativas. Visibilidade contínua, automação e rigor são agora uma expectativa básica, não uma melhoria opcional.

TL;DR

Aikido Security oferece as ferramentas necessárias para cumprir o Projeto de Lei de Cibersegurança e Resiliência do Reino Unido. O Projeto de Lei é aplicável e exige desenvolvimento seguro por design, configurações seguras por padrão, total transparência de SBOMs, gerenciamento de vulnerabilidades obrigatório, garantia de segurança da cadeia de suprimentos e relatórios baseados em evidências para os reguladores.

Aqui, explicamos por que a Lei foi introduzida, como ela difere da Lei de Ciber-Resiliência da UE, o que ela significa para desenvolvedores e equipes de segurança e por que cumprir esses requisitos é difícil sem visibilidade unificada e automação.

Aikido ajuda você a cumprir essas obrigações por meio de varredura contínua, correlação automatizada de riscos, geração de SBOM, análise da cadeia de suprimentos, relatórios prontos para auditoria e fluxos de trabalho de remediação integrados em GitHub, GitLab, Bitbucket, Azure e muito mais.

Se você precisa de conformidade contínua que acompanha as expectativas de segurança do Reino Unido e da UE, Aikido oferece um caminho claro a seguir.

Por que o Projeto de Lei de Cibersegurança e Resiliência do Reino Unido Foi Introduzido

A Lei de Cibersegurança e Resiliência é uma reforma e expansão das Regulamentações NIS de 2018. Foi introduzida para fortalecer a resiliência cibernética nacional e abordar lacunas que surgiam à medida que sistemas digitais, serviços de Cloud e cadeias de dependência se tornavam mais complexos. A Lei visa promover uma “mudança fundamental na segurança nacional do Reino Unido”, respondendo a ciberataques que estão aumentando em escala, sofisticação e impacto econômico. Muitos ataques exploram fornecedores upstream, dependências de software ou provedores de serviços gerenciados, mostrando como as fraquezas em uma organização podem se espalhar por vários setores.

Serviços públicos essenciais como energia, água, saúde, transporte e finanças agora dependem fortemente de sistemas digitais. Um único incidente cibernético pode afetar milhões de pessoas. A Lei busca explicitamente “proteger os serviços dos quais o público depende”, desde ligar as luzes até acessar o NHS. O aumento da computação em Cloud, ecossistemas SaaS e cadeias de suprimentos interconectadas também revelou pontos cegos regulatórios, particularmente em torno de provedores de serviços gerenciados.

Incidentes de alto perfil em telecomunicações, finanças, saúde e governo local destacaram fraquezas sistêmicas, incluindo configurações padrão inseguras, vulnerabilidades não corrigidas e visibilidade limitada sobre o risco de terceiros. Práticas de segurança voluntárias não eram mais suficientes para abordar essas ameaças em evolução.

Em resposta, a Lei muda de orientação para obrigação aplicável. Ela estabelece expectativas de segurança mais claras, aumenta o relato de incidentes, aprimora a supervisão regulatória, fortalece a garantia da cadeia de suprimentos e atualiza os poderes de fiscalização. Em resumo, ela fornece bases atualizadas e aplicáveis para salvaguardar os serviços essenciais do Reino Unido e manter a estabilidade econômica em um cenário digital mais interconectado.

O Que o Projeto de Lei Significa para Desenvolvedores e Equipes de Segurança

A Lei de Cibersegurança e Resiliência faz mais do que estabelecer amplos objetivos de política. Ela muda como é o trabalho diário para as pessoas que constroem e protegem software. Abaixo estão as expectativas para desenvolvedores e equipes de segurança.

O Que Significa para Desenvolvedores

Desenvolvedores estão mais próximos da cadeia de suprimentos de software do que qualquer outro grupo, o que significa que a Lei afeta diretamente como você escreve, mantém e lança código.

1. Expectativas claras em torno da codificação segura: O Projeto de Lei espera que os princípios de segurança por design apareçam em sua base de código. Isso significa revisões de código regulares, validação de entrada, configurações padrão seguras e padrões previsíveis e seguros em todos os serviços.

2. Prazos obrigatórios para remediação de vulnerabilidades: Os dias de corrigir problemas de segurança “quando o tempo permite” acabaram. Espera-se que você corrija as vulnerabilidades dentro de janelas de tempo definidas e apresente evidências de que esses prazos estão sendo cumpridos.

3. Maior responsabilidade no rastreamento de riscos de dependência: Aplicações modernas dependem fortemente de bibliotecas de código aberto. Agora você é responsável por entender a postura de segurança dessas dependências, e não apenas do código que você mesmo escreve.

4. Necessidade de conscientização sobre SBOM: As Software Bills of Materials estão se tornando um requisito de conformidade. Você precisa saber o que está em sua base de código, incluindo dependências transitivas, e manter esse inventário preciso. 

5. Codificação baseada em evidências e higiene de commits: Seu trabalho deve ser rastreável. Isso inclui históricos de commits limpos, mudanças documentadas e justificativa clara para decisões relacionadas à segurança. Se um auditor revisar seu repositório, ele deve ser capaz de entender como as vulnerabilidades foram gerenciadas e por que certas mudanças foram feitas.

O Que Significa para as Equipes de Segurança

Para as equipes de segurança, a Lei eleva as expectativas de uma supervisão consultiva para uma responsabilização obrigatória. A conformidade se torna um fluxo de trabalho contínuo, em vez de um exercício anual.

1. Expectativas de conformidade contínua: As equipes de segurança devem manter visibilidade atualizada em todos os sistemas, repositórios, dependências e infraestrutura. Os controles devem operar continuamente e não apenas durante os ciclos de auditoria.

2. Mais pressão por fluxos de trabalho automatizados de vulnerabilidades: A varredura manual não é suficiente. Você precisará de pipelines automatizados que detectem problemas, os priorizem, notifiquem as pessoas certas e rastreiem a remediação até a conclusão.

3. Estruturas de relatórios obrigatórias: Espera-se que você mantenha um processo claro de entrada de vulnerabilidades, promova o compartilhamento de informações entre as equipes e produza documentação que possa ser entregue aos reguladores mediante solicitação.

4. O ônus de provar medidas de segurança razoáveis: Não é mais suficiente dizer que você tem um processo. Você deve apresentar métricas, prazos, históricos de tickets, logs, SBOMs e trilhas de auditoria que demonstrem segurança operacional real.

5. Colaboração mais forte com as equipes de engenharia: Os controles de segurança agora influenciam os pipelines de entrega e a velocidade da engenharia. A Lei incentiva um alinhamento mais estreito entre DevOps, engenharia de plataforma e funções de segurança.

6. A postura de segurança se torna uma questão regulatória: A segurança não é mais uma boa prática. Sob a Lei, resiliência e desenvolvimento seguro são expectativas legais. Decisões que antes eram internas agora têm consequências regulatórias.

Lei de Cibersegurança e Resiliência do Reino Unido vs a Lei de Ciber-Resiliência da UE (CRA)

Muitas organizações presumem que a Lei de Cibersegurança e Resiliência do Reino Unido é apenas uma contraparte regional da Lei de Ciber-Resiliência da UE.

Ambos visam fortalecer a segurança de produtos e serviços digitais, mas regulam responsabilidades diferentes. Confundir os dois pode resultar em equipes aplicando controles errados, produzindo relatórios incorretos ou dependendo de evidências que não satisfazem nenhum dos regimes. 

O Que a Lei de Ciber-Resiliência da UE Abrange

A CRA da UE se concentra em produtos com elementos digitais e se aplica em todo o mercado único da UE. Ela foca em fabricantes, importadores e distribuidores, garantindo que os produtos atendam às mesmas expectativas de segurança antes e depois do lançamento.

1. Segurança por design e seguro por padrão: Os fabricantes devem construir produtos que sejam seguros desde o primeiro uso, sem exigir conhecimento especializado do usuário.

2. Obrigações de avaliação de risco: Os produtos devem passar por avaliações de risco estruturadas antes de serem colocados no mercado.

3. Processos obrigatórios de tratamento de vulnerabilidades: A entrada de vulnerabilidades, a pontuação de risco e a remediação devem seguir procedimentos definidos.

4. Deveres de monitoramento pós-mercado: Os fabricantes devem monitorar a segurança do produto após o lançamento e continuar a abordar as vulnerabilidades durante todo o ciclo de vida do produto.

Onde a Lei de Cibersegurança e Resiliência do Reino Unido e a Lei de Ciber-Resiliência da UE se Sobrepõem

Ambos os frameworks compartilham princípios semelhantes, embora os apliquem de maneiras diferentes.

  • Requisitos de desenvolvimento seguro
  • gerenciamento de vulnerabilidades obrigatório
  • Transparência em toda a cadeia de suprimentos de software
  • Monitoramento de segurança pós-mercado ou pós-implantação
  • Documentação e conformidade baseada em evidências

Por exemplo, se uma dependência de terceiros introduzir uma CVE crítica, ambos os frameworks esperam visibilidade rápida, remediação coordenada e documentação verificável.

Principais Diferenças

Categoria Projeto de Lei de Cibersegurança e Resiliência do Reino Unido Lei de Ciber-Resiliência da UE (CRA)
Jurisdição Reino Unido União Europeia
Escopo Regulatório Resiliência e serviços entre organizações Centrado no produto, focado em fabricantes e distribuidores
Estrutura de Relatórios Enfatiza a atestação de resiliência organizacional Enfatiza a avaliação de conformidade do fabricante
Classificação de Risco Foca na maturidade organizacional e no risco operacional Define categorias de produtos específicas e classes críticas
Responsabilidade da Cadeia de Suprimentos As organizações permanecem responsáveis pelos riscos de terceiros Os fabricantes permanecem responsáveis pela segurança do produto durante todo o ciclo de vida

Por Que Atender ao Projeto de Lei de Cibersegurança e Resiliência do Reino Unido é Difícil

As expectativas no Projeto de Lei de Cibersegurança e Resiliência parecem diretas no papel. Na prática, a maioria das organizações enfrenta dificuldades porque seus ambientes de engenharia são complexos, em constante mudança e altamente dependentes de componentes de terceiros. Mesmo equipes maduras acham difícil manter a conformidade contínua quando cada commit, implantação e atualização de dependência introduz um novo risco.

Abaixo estão as principais razões pelas quais esses requisitos são difíceis de serem atendidos em ambientes reais:

  1. Aplicações modernas dependem de vastas redes de bibliotecas de código aberto. A maioria das equipes não consegue rastrear a postura de segurança de cada dependência e dependência transitiva sem automação.
  2. A cobertura de segurança frequentemente para na varredura de código. Imagens de Container, definições de infraestrutura e cargas de trabalho em tempo de execução não são monitoradas com a mesma precisão, o que cria pontos cegos.
  3. As equipes usam scanners diferentes que produzem níveis de gravidade conflitantes e orientações inconsistentes. Isso atrasa a remediação e torna a priorização não confiável.
  4. Planilhas de auditoria e listas de verificação periódicas não conseguem acompanhar as alterações diárias no código, as atualizações de dependências e as novas vulnerabilidades lançadas a cada semana.
  5. As equipes devem provar não apenas que as vulnerabilidades foram corrigidas, mas também quando foram reportadas, quem respondeu, quanto tempo a remediação levou e quais decisões foram tomadas. A maioria das organizações carece dessa documentação.
  6. Escolhas arquitetônicas, padrões de codificação e decisões de configuração precisam ser apoiadas por justificativa rastreável. Sem documentação estruturada, isso se torna difícil de apresentar durante revisões de conformidade.
  7. Os achados frequentemente ficam em uma ferramenta enquanto os tickets residem em outra. Isso torna difícil verificar se os problemas foram triados, priorizados, atribuídos e resolvidos a tempo.

Esses desafios explicam por que as organizações precisam de uma maneira unificada de monitorar riscos, coordenar a remediação e produzir evidências automaticamente. Este é também o ponto natural onde Aikido Security se torna relevante como um motor central de visibilidade e conformidade.

Como o Aikido Permite que Você Cumpra os Requisitos da Lei de Cibersegurança e Resiliência do Reino Unido

Para atender aos requisitos da Lei de Cibersegurança e Resiliência, as organizações precisam de mais do que varreduras periódicas ou ferramentas de segurança isoladas. Elas precisam de uma plataforma que lhes ofereça ferramentas de ponta para visibilidade contínua, pontuação de risco consistente e evidências que possam entregar aos reguladores sem vasculhar planilhas. A Aikido Security se encaixa nesse espaço ao fornecer um ponto de controle central para equipes de engenharia modernas.

Aikido é uma plataforma de segurança nativa da Cloud que reúne todos os seus sinais de segurança em um só lugar. Ela fornece visibilidade em suas bases de código, dependências de código aberto, modelos de infraestrutura como código, imagens de Container, Secrets e pipelines de integração contínua.

Em vez de forçar as equipes a gerenciar scanners separados, o Aikido correlaciona vulnerabilidades nessas camadas, destaca o que é realmente explorável e remove o ruído que atrasa a remediação.

Requisito da Lei do Reino Unido Recurso(s) do Aikido que o satisfazem
Desenvolvimento seguro por design SAST, SCA (Dependências), varredura IaC, varredura de segredos, Qualidade de Código, segurança CI/CD
Configuração de produto segura por padrão varredura IaC, CSPM (detecção de configuração incorreta na Cloud), Imagens de Container, Máquinas Virtuais, Varredura de API
Tratamento obrigatório de vulnerabilidades e prazos de remediação Monitoramento Contínuo, SAST, SCA, Varredura de Container e K8s, Triagem Automática, AutoFix, Integrações Jira/Slack
Transparência dos riscos cibernéticos (SBOM + inventário) Risco de Licença e SBOMs, Exportação de SBOM (CycloneDX/SPDX), Inventário de Dependências, Software Desatualizado
Garantia de segurança da cadeia de suprimentos Dependências (SCA), Detecção de Malware, Risco de Licença e SBOMs, Software Desatualizado, Imagens de Container, Varredura de Superfície de Ataque
Garantia baseada em evidências para reguladores Relatórios de Conformidade, Exportação de SBOM, Logs de Auditoria, Linhas do Tempo de Vulnerabilidades Históricas
Responsabilidade por componentes de terceiros Dependências (SCA), Malware, Risco de Licença e SBOMs, Software Desatualizado, varredura de imagens de contêiner
Demonstrando fluxos de trabalho seguros em todo o CI/CD segurança CI/CD, SAST, varredura IaC, varredura de segredos, AutoFix + Auto Triage, integrações IDE
Prevenindo que vulnerabilidades exploráveis conhecidas sejam lançadas SAST, SCA, IaC, Secrets, Imagens de Container, Varredura de API, varredura de máquinas virtuais, Detecção de Malware
Detectando configurações incorretas exploráveis precocemente CSPM, varredura IaC, Varredura de Container e K8s, Varredura de API
Mantendo a segurança precisa do ciclo de vida do software Software Desatualizado, Risco de Licença e SBOMs, Inventário de Dependências, monitoramento contínuo

Embora o Aikido possa ajudar a satisfazer um grande número de requisitos, há uma série de requisitos que precisariam ser atendidos com outros fornecedores, como relatórios de incidentes e expectativas de resiliência operacional contínua. 

Abaixo está um detalhamento de como o Aikido ajuda você a cumprir as obrigações principais na Lei de Cibersegurança e Resiliência do Reino Unido.

1. Requisito: Práticas de Segurança por Design

O problema: Espera-se que você projete software seguro desde a primeira linha de código. Isso significa identificar configurações inseguras precocemente, reduzir o risco de dependência e garantir que os desenvolvedores não sejam sobrecarregados com descobertas irrelevantes.

Como o Aikido resolve

  • Realiza varredura contínua de suas bases de código, dependências e configurações de infraestrutura.
  • Aplica escopos de varredura seguros por padrão para que você não perca áreas críticas.
  • Correlaciona problemas de múltiplas fontes para reduzir o ruído para desenvolvedores e destacar riscos reais.
  • Impõe fluxos de trabalho seguros em pipelines de CI e CD para que as vulnerabilidades não possam passar silenciosamente para a produção.

2. Requisito: Transparência de SBOM e Inventário de Software Preciso

O problema: Você deve manter uma lista de materiais de software precisa e atualizada. O rastreamento manual falha instantaneamente quando novas dependências são adicionadas ou bibliotecas transitivas mudam.

Como o Aikido resolve

SBOM de segurança do Aikido
  • Gere um SBOM em um clique
  • Constrói um SBOM completo para cada repositório através do Gerador de SBOM do Aikido para uma visibilidade clara das dependências.
  • Oferece visibilidade total sobre bibliotecas diretas e transitivas.
  • Alerta você quando componentes SBOM recebem novas CVEs.
  • Permite exportar SBOMs para auditores ou revisões internas com uma única ação.

3. Requisito: Processo Obrigatório de Tratamento de Vulnerabilidades

O problema: O Projeto de Lei espera que você detecte vulnerabilidades, as priorize, atribua a responsabilidade e prove que cumpriu os prazos de remediação. Ferramentas fragmentadas tornam isso quase impossível sem automação.

Como o Aikido resolve

  • Detecta vulnerabilidades em repositórios, imagens de Container e registros.
  • Prioriza as descobertas usando dados de explorabilidade, CVSS e Threat Intelligence para que as equipes se concentrem no que realmente importa.
  • Automatiza fluxos de trabalho de remediação através da integração com Jira ou Slack.
  • Registra o horário e as ações, criando um rastro claro de evidências para auditores.
  • Documenta automaticamente os prazos de remediação, apoiando as expectativas dos reguladores.

4. Requisito: Garantia de Segurança da Cadeia de Suprimentos

O problema: A maioria das organizações depende fortemente de pacotes upstream e dependências de terceiros. Você permanece responsável pelos riscos introduzidos por esses componentes, mesmo que não os tenha criado.

Como o Aikido resolve

  • Identifica e analisa comprometimentos por malware precocemente, muitas vezes antes que se espalhem. Aikido é o primeiro a detectar comportamentos de pacotes maliciosos, releases comprometidas ou mudanças suspeitas de dependências que poderiam ter um impacto devastador na sua cadeia de suprimentos.
  • Pontua o risco de dependência com base no histórico de segurança, padrões de manutenção e reputação do ecossistema.
  • Detecta pacotes potencialmente maliciosos ou tentativas de typosquatting antes que entrem na sua base de código.
  • Sinaliza bibliotecas abandonadas, desatualizadas ou comprometidas para que as equipes possam substituí-las antes que exponham cargas de trabalho de produção.
  • Oferece rastreabilidade de ponta a ponta, permitindo que você mostre exatamente de onde veio uma dependência, quais serviços ela afeta e como foi remediada durante as verificações de conformidade.

5. Requisito: Garantia Baseada em Evidências para Reguladores do Reino Unido

O problema: Não basta alegar que você tem boas práticas de segurança. Você deve prová-lo através de evidências estruturadas, registros históricos e relatórios de risco transparentes.

Como o Aikido resolve

conformidade de segurança Aikido
  • Produz relatórios automatizados, prontos para conformidade que mapeiam as descobertas às expectativas regulatórias.
  • Mostra cronogramas históricos de vulnerabilidades que demonstram gerenciamento de risco de longo prazo.
  • Documenta a atividade de remediação para que os auditores possam entender o que mudou e por quê.
  • Oferece uma visão clara das medidas de segurança razoáveis adotadas em sua organização.
  • Agrega informações de risco em visualizações amigáveis para a liderança, que ajudam as equipes executivas a cumprir suas obrigações de prestação de contas.

Além de ISO27001, SOC2, NIS2 e CIS: O que o Projeto de Lei de Cibersegurança e Resiliência do Reino Unido Adiciona

A maioria das organizações já mantém a conformidade com frameworks estabelecidos, como ISO 27001, SOC2, benchmarks CIS, NIS2 ou PCI. Esses frameworks focam na gestão de segurança organizacional. Eles definem como você deve gerenciar riscos, documentar políticas, controlar o acesso, monitorar eventos e responder a incidentes. 

Aikido já suporta esses padrões:

  • Conformidade ISO 27001:2022 
  • Conformidade SOC2 
  • Conformidade Top 10 OWASP
  • Conformidade CIS 
  • conformidade NIS2
  • Conformidade NIST 800-53 
  • Conformidade PCI 
  • Conformidade HIPAA 
  • Conformidade DORA 
  • HITRUST 
  • Conformidade LVL3 
  • Conformidade ENS 
  • GDPR

O Projeto de Lei de Cibersegurança e Resiliência do Reino Unido introduz um tipo diferente de requisito. Ele vai além dos controles organizacionais e estabelece expectativas rigorosas sobre a segurança do software e dos serviços que você desenvolve e opera. Ele exige desenvolvimento seguro por design, configurações padrão seguras, transparência verificável de SBOM, tratamento contínuo de vulnerabilidades, garantia da cadeia de suprimentos e evidências de prazos de remediação. Essas obrigações se aplicam diretamente às suas práticas de engenharia, pipelines de CI, bases de código, dependências, Containers, ativos de Cloud e fluxos de trabalho operacionais.

Isso cria uma nova lacuna: você pode atender à ISO 27001 ou SOC2 e ainda não cumprir os requisitos do Projeto de Lei do Reino Unido se seu produto for lançado com vulnerabilidades exploráveis, bibliotecas desatualizadas, controles fracos da cadeia de suprimentos ou fluxos de remediação indocumentados. As estruturas tradicionais não cobrem essas áreas profundamente o suficiente.

A Aikido ajuda a preencher essa lacuna, fornecendo os controles técnicos, a automação e a visibilidade em tempo real necessários para satisfazer as obrigações de nível de produto e serviço do projeto de lei.

Aikido Security: Seu Caminho para uma Conformidade Contínua e Confiante

O Projeto de Lei de Cibersegurança e Resiliência do Reino Unido marca uma clara mudança na forma como as organizações devem abordar a segurança. É aplicável, não consultivo, e exige que as equipes demonstrem resiliência com evidências, não intenção. A Lei de Ciber-Resiliência da UE se alinha a ele com escopos e responsabilidades diferentes, o que significa que as organizações que operam em diferentes regiões precisam de uma abordagem diferenciada que respeite ambas as estruturas, em vez de tratá-las como intercambiáveis.

Aikido oferece a base operacional para atender a essas expectativas. Você obtém visibilidade contínua em seu código, dependências, infraestrutura e pipelines. Você recebe pontuação de risco consistente, fluxos de trabalho de remediação automatizada e trilhas de auditoria nas quais os reguladores podem confiar. A conformidade se torna algo que você mantém todos os dias, em vez de um estressante ponto de verificação anual.

Com o nível certo de automação e o nível certo de observabilidade, você reduz o risco, melhora a velocidade de entrega e remove a incerteza que cerca a preparação regulatória típica. A Aikido ajuda você a transformar requisitos complexos em processos gerenciáveis e repetíveis que escalam com suas equipes de engenharia.

Se você deseja uma conformidade que acompanha o Projeto de Lei do Reino Unido, se alinha com as expectativas da Lei de Ciber-Resiliência da UE e se encaixa naturalmente em seu fluxo de trabalho de desenvolvimento, comece com Aikido Security hoje.

Você também pode gostar:

Compartilhar:

https://www.aikido.dev/blog/uk-cybersecurity-resilience-bill-compliance

Assine para receber notícias sobre ameaças.

Comece hoje, gratuitamente.

Comece Gratuitamente
Não é necessário cc

Fique seguro agora

Proteja seu código, Cloud e runtime em um único sistema centralizado.
Encontre e corrija vulnerabilidades rapidamente de forma automática.

Não é necessário cartão de crédito | Resultados da varredura em 32 segundos.