Explorar a validação de segurança contínua

8 minutos

Os desenvolvedores modernos usam rotineiramente componentes disponíveis em fontes de pacotes públicos como npm, NuGet, PyPI, Maven Central e RubyGems. Essa prática tornou-se padrão em todo o setor de software à medida que as organizações adotam componentes de software livre (OSS) para uma entrega mais rápida e melhor produtividade.

A espada de dois gumes dos componentes de terceiros

Benefícios de componentes de terceiros:

Desenvolvimento mais rápido: Os desenvolvedores não precisam criar funcionalidades comuns do zero.
Soluções comprovadas: Pacotes populares foram testados por milhares de usuários.
Suporte da comunidade: As comunidades ativas fornecem documentação, atualizações e assistência.
Economia de custos: Os componentes gratuitos do OSS reduzem significativamente os custos de desenvolvimento.
Aceleração de inovação: O Teams pode se concentrar na lógica de negócios exclusiva em vez de reinventar a funcionalidade padrão.

Riscos crescentes de segurança e conformidade: No entanto, à medida que a dependência em componentes de OSS de terceiros aumenta, os riscos também aumentam:

Vulnerabilidades de segurança:

Pacotes de terceiros podem conter vulnerabilidades de segurança conhecidas que os invasores podem explorar.
As vulnerabilidades são descobertas continuamente em pacotes existentes.
Dependências transitivas (dependências de suas dependências) introduzem vulnerabilidades das quais você talvez não esteja consciente.
Os ataques da cadeia de suprimentos têm como alvo pacotes populares para comprometer muitos aplicativos downstream.

Problemas de conformidade de licença:

Os requisitos de licença ocultos podem criar obrigações legais.
Algumas licenças de OSS exigem que você abra seu próprio código se usar seus componentes.
Violações de licença podem resultar em ações judiciais, penalidades financeiras e versões de código forçadas.
Licenças diferentes podem ser incompatíveis entre si, criando conflitos de conformidade.

Criticidade do negócio: Para uma empresa, esses problemas são críticos. Problemas relacionados à conformidade, ao passivo e aos dados pessoais do cliente podem causar sérias preocupações de privacidade e segurança:

Responsabilidade legal: Violações de licença expõem as organizações a ações legais.
Violações de dados: Componentes vulneráveis podem levar a violações de dados que afetam dados pessoais do cliente.
Conformidade regulatória: Violações de regulamentos como GDPR, CCPA ou HIPAA podem resultar em multas significativas.
Danos à reputação: Incidentes de segurança e violações de licença prejudicam a confiança do cliente e a reputação da marca.
Contratos de cliente: Os clientes corporativos geralmente exigem garantias de segurança e conformidade que os componentes vulneráveis violam.

O valor da detecção precoce

Aviso avançado: Identificar problemas de segurança e conformidade no início do ciclo de lançamento fornece aviso avançado e tempo suficiente para corrigir problemas antes que eles cheguem à produção.

Custo de correção: O custo de corrigir problemas é drasticamente menor no início do projeto em que o problema é descoberto:

Durante o desenvolvimento: Alterar uma dependência custa horas de tempo do desenvolvedor.
Durante o teste: Corrigir problemas requer retestar todo o aplicativo.
Em produção: A correção requer aplicação de patch de emergência, resposta a incidentes de segurança, notificações do cliente e relatórios regulatórios potenciais.

Impacto econômico: Estudos mostram que os problemas de segurança encontrados na produção custam de 10 a 100 vezes mais para corrigir do que aqueles encontrados durante o desenvolvimento.

Validação de segurança de integração contínua

Uma vez que o código é mesclado na ramificação principal, a validação de segurança abrangente deve ser executada como parte do processo de compilação de integração contínua (CI).

Compilação de CI vs. Compilação de PR-CI

Pull request CI (PR-CI): Executa-se durante a validação do pull request, antes da mesclagem do código. Fornece retorno rápido para impedir que código vulnerável entre no repositório de código.

Compilação completa de CI: Executa após o código ser mesclado na ramificação principal. Inclui verificações mais abrangentes e prepara artefatos para implantação.

Diferenças típicas: A principal diferença entre compilações de PR-CI e compilações completas de CI é que o PR-CI não precisa de empacotamento ou artefatos de preparação que a compilação completa de CI produz. Isso mantém o PR-CI rápido enquanto garante a validação de segurança.

Ambos devem incluir verificações de segurança: Ambos os tipos de build devem executar validações de segurança principais, mas builds de CI completos podem incluir verificações adicionais demoradas.

Análise de código estático em builds de CI

Propósito: Os builds de CI devem executar testes de análise de código estático para garantir que o código siga todas as regras para manutenção e segurança.

Ferramentas comuns de análise estática:

SonarQube:

Plataforma abrangente de qualidade e segurança de código.
Detecta bugs, cheiros de código e vulnerabilidades de segurança.
Controla as métricas de qualidade do código ao longo do tempo.
Integra portas de qualidade que falham nas compilações quando os limites de qualidade não são atendidos.
Dá suporte a várias linguagens de programação.

Análise de Código do Visual Studio e Analisadores de Segurança Roslyn:

Análise embutida para aplicativos .NET.
Os Analisadores de Segurança do Roslyn detectam vulnerabilidades de segurança no código C#.
É executado durante a compilação fornecendo comentários imediatos.
Nenhuma infraestrutura adicional necessária para projetos do .NET.

Checkmarx:

Ferramenta SAST (Teste de Segurança de Aplicativo Estático).
Análise de segurança profunda do código-fonte.
Identifica vulnerabilidades como injeção de SQL, XSS e problemas de autenticação.
Fornece diretrizes detalhadas de correção.
Dá suporte a muitas linguagens de programação e estruturas.

BinSkim:

Ferramenta de análise estática binária da Microsoft.
Fornece resultados de segurança e correção para arquivos PE (executáveis portáteis do Windows).
Analisa binários compilados em vez de código-fonte.
Identifica problemas de segurança nas configurações de compilação e na estrutura binária.
Útil para analisar componentes compilados de terceiros.

Ferramentas adicionais:

ESLint com plug-ins de segurança: Análise de segurança de JavaScript/TypeScript.
Bandit: Análise de segurança do Python.
Brakeman: Scanner de segurança para Ruby on Rails.
gosec: Verificador de segurança para Go.

Integração do Azure Pipelines: Muitas ferramentas de segurança se integram perfeitamente ao Azure Pipelines e a outras plataformas de CI/CD. O Visual Studio Marketplace fornece extensões para várias ferramentas de segurança, tornando a integração simples:

Ferramentas aparecem como tarefas de fluxo de trabalho que você pode adicionar à sua definição de fluxo de trabalho.
Os resultados são exibidos nos logs do pipeline e podem causar falha nas construções quando problemas são detectados.
As descobertas de segurança se integram ao acompanhamento de item de trabalho do Azure DevOps.

Verificação de vulnerabilidades em pacotes de terceiros

Crítico, mas muitas vezes negligenciado: Além de verificar a qualidade do código, duas outras validações críticas geralmente são ignoradas ou executadas inadequadamente:

Verificando pacotes de terceiros em busca de vulnerabilidades de segurança conhecidas.
Verificando a conformidade da licença do OSS.

Resposta organizacional comum: Quando perguntado sobre vulnerabilidades e licenças de pacotes de terceiros, muitas organizações respondem com medo ou incerteza. Eles não têm processos claros para gerenciar esses riscos.

Problemas manuais de processo: As organizações que tentam gerenciar vulnerabilidades de pacote de terceiros ou licenças de OSS geralmente explicam que seu processo é entediante e manual:

Os desenvolvedores pesquisam manualmente bancos de dados de vulnerabilidade.
As equipes de segurança mantêm planilhas de pacotes aprovados.
As revisões de licença exigem o envolvimento da equipe jurídica para cada pacote.
As atualizações são controladas manualmente, levando a informações de dependência desatualizadas.
O processo leva semanas, retardando significativamente o desenvolvimento.

Soluções automatizadas: As ferramentas de SCA (análise de composição de software) moderna automatizam esse processo de identificação, tornando-o quase instantâneo:

Mend (anteriormente WhiteSource):

Detecta automaticamente todos os componentes do OSS em seus aplicativos.
Identifica vulnerabilidades de segurança conhecidas em dependências.
Verifica a conformidade da licença em relação às políticas organizacionais.
Fornece diretrizes de correção, incluindo versões fixas disponíveis.
Monitora continuamente novas vulnerabilidades em pacotes usados.

GitHub Dependabot:

Verifica automaticamente as dependências em busca de vulnerabilidades conhecidas.
Cria solicitações de pull para atualizar dependências vulneráveis.
Dá suporte a muitos ecossistemas de pacotes (npm, Maven, pip etc.).
Gratuito para repositórios públicos e privados do GitHub.

Snyk:

Ferramenta de segurança voltada para desenvolvedores para localizar e corrigir vulnerabilidades.
Escaneia dependências, imagens de contêiner e infraestrutura em forma de código.
Fornece conselhos de correção e solicitações de pull automatizadas.
Integra-se a IDEs, controle de versão e pipelines de CI/CD.

Fontes upstream do Azure Artifacts:

Pode ser configurado para analisar pacotes de fontes upstream.
Bloqueia pacotes com vulnerabilidades conhecidas.
Fornece visibilidade de todos os pacotes usados em toda a organização.

Benefícios da análise de composição de software

Visibilidade abrangente: As ferramentas de SCA fornecem visibilidade completa da cadeia de fornecimento de software:

Inventaria todas as dependências diretas e transitivas.
Acompanhe as versões e o status da atualização.
Identifique os componentes que não são mais mantidos.
Mapear dependências para aplicativos e equipes específicos.

Priorização de risco: Nem todas as vulnerabilidades são igualmente críticas. As ferramentas de SCA ajudam a priorizar:

Pontuações de severidade (classificações CVSS) que indicam gravidade da vulnerabilidade.
Classificações de explorabilidade mostrando se ataques são conhecidos por existir.
Análise de acessibilidade determinando se o código vulnerável é realmente usado em seu aplicativo.
Contexto comercial sobre quais aplicativos são mais críticos.

Monitoramento contínuo: Vulnerabilidades de segurança são descobertas constantemente. As ferramentas de SCA fornecem monitoramento contínuo:

Alertas quando novas vulnerabilidades são descobertas em pacotes que você usa.
Relatórios regulares sobre tendências de postura de segurança.
Integração com sistemas de acompanhamento de problemas para gerenciar o trabalho de correção.

Documentação de conformidade: As ferramentas de SCA geram relatórios de conformidade:

Obrigações de licença para todos os componentes usados.
Requisitos de atribuição que devem ser atendidos.
Evidências de que as revisões de segurança foram realizadas.
Trilhas de auditoria para conformidade regulatória.

Integração no pipeline

A validação contínua de segurança integra-se ao seu pipeline de CI/CD como tarefas automatizadas:

Mesclagem de código: A solicitação de pull é aprovada e o código é mesclado no branch principal.
Gatilhos de compilação de CI: A mesclagem aciona automaticamente a compilação completa de CI.
A análise estática é executada: As ferramentas SAST analisam o código-fonte em busca de vulnerabilidades.
Verificação de dependência: As ferramentas de SCA verificam todas as dependências em busca de vulnerabilidades e problemas de licença.
Portões de qualidade: O build falhará se os problemas de segurança excederem os limites aceitáveis.
Resultados disponíveis: As descobertas de segurança estão disponíveis para desenvolvedores e equipes de segurança.
Criação de artefato: Se as verificações de segurança forem aprovadas, artefatos de construção serão criados para implantação.

Em módulos posteriores, discutiremos a integração de várias ferramentas de segurança e conformidade úteis e comumente usadas em sua configuração de pipeline específica.

Comentários

Esta página foi útil?