Inspecionar e validar bases de código para conformidade

Antes de implementar ferramentas automatizadas de Análise de Composição de Software, as organizações devem entender o que precisa ser inspecionado e validado em suas bases de código. Os aplicativos modernos contêm centenas ou milhares de dependências, tornando a inspeção manual impraticável. Abordagens sistemáticas para descoberta de dependência, avaliação de vulnerabilidade e validação de conformidade são essenciais.

Por que a inspeção e a validação importam

O desafio de dependência: Os aplicativos não dependem apenas dos pacotes que você importa diretamente. Cada dependência direta normalmente depende de pacotes adicionais (dependências transitivas), criando árvores de dependência profunda. Um aplicativo típico pode fazer referência direta a 20 a 30 pacotes, mas depende transitivamente de 200 a 500 pacotes. Você é responsável por vulnerabilidades e obrigações de licença em todas as dependências, não apenas nas diretas.

O imperativo de segurança: Vulnerabilidades de segurança em dependências representam riscos significativos. Os invasores exploram ativamente vulnerabilidades conhecidas em pacotes populares, tornando as dependências não atendidas destinos atraentes. Violações de alto perfil geralmente envolvem a exploração de vulnerabilidades conhecidas em componentes de software livre que as organizações não atualizaram.

O requisito de conformidade: Violações de licença podem resultar em ações legais, fornecimento aberto forçado de código proprietário, restrições de distribuição e danos à reputação. As organizações devem acompanhar as obrigações de licença para cada dependência e garantir a conformidade com os termos de licença.

A realidade operacional: As dependências mudam constantemente. Novas vulnerabilidades são divulgadas diariamente, pacotes recebem atualizações, mantenedores abandonam projetos e novas versões são lançadas. A inspeção única não é suficiente– a validação contínua é necessária.

O que inspecionar e validar

A inspeção abrangente da base de código abrange várias dimensões:

Inventário de dependência

Criando uma fatura completa de materiais:

• Dependências diretas: Pacotes explicitamente listados em arquivos de manifesto do pacote (package.json, requirements.txt, pom.xml, *.csproj).
• Dependências transitivas: Pacotes requeridos por suas dependências diretas, em múltiplos níveis de profundidade.
• Dependências de desenvolvimento: Pacotes usados durante o desenvolvimento e teste, mas não fornecidos com código de produção.
• Controle de versão: Versões específicas de cada pacote atualmente em uso.
• Fontes de dependência: Quais registros de pacote fornecem dependências (npm, PyPI, NuGet, Maven Central, registros privados).

Por que os inventários completos importam:

• Gerenciamento de vulnerabilidades: Você não pode corrigir vulnerabilidades que não conhece.
• Conformidade de licença: Deve acompanhar as obrigações de licença para todas as dependências, não apenas as diretas.
• Planejamento de atualização: Noções básicas sobre relações de dependência ajuda a planejar atualizações que não interrompa a compatibilidade.
• Visibilidade da cadeia de suprimentos: Saiba exatamente qual código externo está incluído em seus aplicativos.

Detecção de vulnerabilidades de segurança

Identificando vulnerabilidades conhecidas:

• Mapeamento de CVE (Vulnerabilidades e Exposições Comuns): Corresponder versões de dependência com bancos de dados CVE que contêm vulnerabilidades conhecidas.
• Avaliação de severidade: Avalie a gravidade da vulnerabilidade usando pontuações CVSS (Common Vulnerability Score System) que variam de 0 a 10.
• Análise de explorabilidade: Determine se as vulnerabilidades são exploradas ativamente na natureza.
• Disponibilidade de patch: Identifique quais versões corrige vulnerabilidades e se os patches estão disponíveis.

Noções básicas sobre bancos de dados de vulnerabilidade:

• Banco de Dados de Vulnerabilidade Nacional (NVD): Repositório governamental dos EUA de dados de vulnerabilidade com base em identificadores CVE.
• Banco de dados de consultoria do GitHub: Avisos de segurança coletados para pacotes em vários ecossistemas.
• Listas de discussão de segurança: Notificações de segurança específicas de linguagem de programação e framework.
• Bancos de dados do fornecedor: As ferramentas comerciais de SCA mantêm bancos de dados de vulnerabilidade proprietários com inteligência adicional.

Categorias de vulnerabilidade em dependências:

• Falhas de injeção: injeção de SQL, injeção de comando, vulnerabilidades de script entre sites em estruturas da Web.
• Problemas de autenticação: Implementações de autenticação fracas, problemas de gerenciamento de sessão, falhas de tratamento de credenciais.
• Exposição de dados confidenciais: Armazenamento de dados inseguro, criptografia inadequada, vazamento de informações.
• Configuração incorreta de segurança: Configurações padrão com pontos fracos conhecidos, recursos desnecessários habilitados.
• Negação de serviço: Vulnerabilidades de esgotamento de recursos, problemas de complexidade algorítmica.
• Falhas de desserialização: Desserialização não segura que leva à execução remota de código.

Validação de conformidade de licença

Identificando obrigações de licença:

• Detecção de licença: Identifique quais licenças se aplicam a cada dependência.
• Classificação de licença: categorize as licenças como permissivas, com copyleft fraco, com copyleft forte ou proprietárias.
• Análise de compatibilidade: Verifique se as licenças de diferentes dependências são compatíveis quando combinadas.
• Acompanhamento de obrigações: Requisitos de documento, como atribuição, divulgação de código-fonte ou licenciamento de trabalho derivado.

Problemas comuns de conformidade:

• Contaminação por copyleft: Dependências licenciadas pelo GPL em software proprietário podem exigir a disponibilização do código-fonte de todo o aplicativo.
• Falhas de atribuição: Faltam avisos de direitos autorais necessários e texto de licença em software distribuído.
• Combinações incompatíveis: Usando dependências com licenças conflitantes que não podem ser combinadas legalmente.
• Alterações de licença: Os projetos às vezes alteram licenças entre versões, exigindo reavaliação.

Avaliação de risco de licença:

• Alto risco: licenças copyleft fortes (GPL, AGPL) na distribuição de software proprietária.
• Risco médio: Licenças copyleft fracas (LGPL, MPL) que exigem práticas de integração cuidadosas.
• Baixo risco: Licenças permissivas (MIT, Apache 2.0, BSD) com restrições mínimas.
• Risco desconhecido: Licenças personalizadas, licenciamento não claro ou informações de licença ausentes.

Avaliação da qualidade da dependência

Avaliando a manutenção da dependência:

• Status da manutenção: Determine se as dependências são ativamente mantidas ou abandonadas.
• Frequência de atualização: Avalie com que frequência as dependências recebem atualizações e correções de bug.
• Saúde da comunidade: Avalie a atividade dos colaboradores, os tempos de resposta a problemas e o envolvimento da comunidade.
• Qualidade da documentação: Examine se as dependências têm documentação adequada para uso adequado.
• Práticas de segurança: Verifique se os projetos têm processos de divulgação responsáveis e avisos de segurança.

Indicadores de qualidade:

• Manutenção ativa: Confirmações regulares, versões recentes, mantenedores responsivos.
• Grande comunidade: Muitos colaboradores, estrelas, ramificações e usuários garantem a sustentabilidade.
• Comunicação clara: Rastreador de problemas ativos, discussões responsivas, notas de versão claras.
• Conscientização de segurança: Política de segurança publicada, aplicação rápida de patches de vulnerabilidade, avisos de segurança.

Sinalizadores vermelhos:

• Projetos abandonados: Nenhuma atualização por anos, mantenedores sem resposta, acumulando problemas não corrigidos.
• Risco de mantenedor único: Dependência crítica mantida por uma pessoa que pode ficar indisponível.
• Baixa qualidade: Testes inadequados, bugs frequentes, alterações incompatíveis em versões menores.
• Falta de segurança: Nenhuma política de segurança, resposta de vulnerabilidade lenta, problemas de segurança não revelados.

Desafios manuais de inspeção

Por que a inspeção manual não é dimensionada:

Volume avassalador

• Centenas de dependências: Mesmo aplicativos pequenos dependem transitivamente de centenas de pacotes.
• Vários aplicativos: As organizações mantêm dezenas ou centenas de aplicativos, multiplicando a contagem de dependências.
• Alterações constantes: Novas versões lançadas diariamente tornam qualquer inventário manual imediatamente desatualizado.
• Erro humano: O acompanhamento manual inevitavelmente deixa de lado as dependências, especialmente as transitivas.

Informações dispersas

• Várias fontes: As informações de vulnerabilidade vêm de bancos de dados CVE, listas de endereçamento de segurança, avisos do GitHub, notificações do fornecedor e divulgações de pesquisadores de segurança.
• Pesquisa de licença: Determinar licenças exatas requer examinar arquivos de código-fonte, documentos leiame e arquivos de licença em cada pacote.
• Detalhes específicos da versão: Vulnerabilidades e licenças podem ser alteradas entre versões, exigindo pesquisas específicas de versão.
• Informações conflitantes: Às vezes, fontes diferentes fornecem informações de licença ou vulnerabilidades contraditórias.

Análise demorada

• Avaliação de vulnerabilidade: Pesquisar a gravidade, a exploração e o status do patch de cada vulnerabilidade leva um tempo significativo.
• Análise de licença: Noções básicas sobre termos de licença, compatibilidade e obrigações requer conhecimento jurídico.
• Planejamento de atualização: Determinar caminhos de atualização seguros considerando alterações interruptivas e conflitos de dependência é complexo.
• Monitoramento contínuo: O monitoramento contínuo de novas vulnerabilidades e atualizações requer recursos dedicados.

Detecção atrasada

• Atraso de descoberta: Processos manuais detectam vulnerabilidades semanas ou meses após a divulgação.
• Resposta reativa: As organizações aprendem sobre vulnerabilidades de incidentes de segurança em vez de verificação proativa.
• Ciclos de auditoria: Auditorias periódicas deixam os aplicativos vulneráveis entre auditorias.
• Patches de emergência: Sem monitoramento contínuo, as vulnerabilidades críticas exigem aplicação de patches de emergência que causam interrupções.

A solução automatizada

As ferramentas de Análise de Composição de Software resolvem desafios de inspeção manual:

Descoberta automatizada

• Análise de dependência: As ferramentas SCA analisam automaticamente os arquivos de manifesto do pacote para identificar dependências.
• Resolução transitiva: As ferramentas seguem cadeias de dependência para criar uma fatura completa de materiais.
• Análise de arquivo de bloqueio: Analise arquivos de bloqueio (package-lock.json, Pipfile.lock) mostrando exatamente quais versões estão instaladas.
• Verificação binária: Algumas ferramentas verificam binários e contêineres compilados para descobrir dependências inseridas.

Monitoramento contínuo

• Alertas de vulnerabilidade em tempo real: Receba notificações imediatas quando novas vulnerabilidades afetarem suas dependências.
• Atualizações automatizadas: Ferramentas como o GitHub Dependabot criam solicitações de pull automaticamente quando as atualizações de segurança estão disponíveis.
• Visibilidade do painel: Os painéis centralizados mostram o status de vulnerabilidade em todos os aplicativos.
• Verificação agendada: Verificações automatizadas regulares garantem que os dados de dependência permaneçam atuais.

Bancos de dados abrangentes

• Dados de vulnerabilidade agregados: As ferramentas de SCA agregam informações do NVD, do Banco de Dados de Consultoria do GitHub, das listas de endereçamento de segurança e dos bancos de dados do fornecedor.
• Bancos de dados de licença: Mantenha informações abrangentes de licença, incluindo textos de licença completos e resumos de obrigações.
• Cura e verificação: os fornecedores verificam e coletam dados de vulnerabilidade para reduzir falsos positivos.
• Inteligência proprietária: As ferramentas comerciais fornecem pesquisas e análises adicionais além dos bancos de dados públicos.

Análise inteligente

• Pontuação de severidade: Calcule automaticamente as pontuações do CVSS e priorize vulnerabilidades por risco.
• Análise de acessibilidade: Determine se caminhos de código vulneráveis são realmente usados em seu aplicativo.
• Diretrizes de correção: Forneça recomendações de versão específicas que corrija vulnerabilidades, mantendo a compatibilidade.
• Imposição de política: Faz com que builds falhem automaticamente ou bloqueia implementações quando são detectadas violações de política.

Estabelecendo linhas de base de validação

Antes de implementar a verificação automatizada, estabeleça critérios de validação:

Políticas de segurança

• Tolerância a vulnerabilidades: Defina quais severidades de vulnerabilidade são aceitáveis (por exemplo, nenhum meio crítico ou alto e limitado).
• Quadros de tempo de patch: Estabeleça a rapidez com que diferentes vulnerabilidades de severidade devem ser corrigidas.
• Processos de exceção: Crie procedimentos para aceitar riscos quando a aplicação de patch imediata não for viável.
• Requisitos de relatório: Defina quem precisa de notificações de vulnerabilidade e quão rapidamente.

Políticas de conformidade

• Licenças aprovadas: Listar licenças que são sempre aceitáveis (por exemplo, MIT, Apache 2.0).
• Licenças restritas: Identificar licenças que exigem aprovação especial (por exemplo, LGPL) ou proibição (por exemplo, GPL para software proprietário).
• Requisitos de atribuição: Defina como a atribuição deve ser fornecida no software distribuído.
• Trilhas de auditoria: Especifique os requisitos de documentação para evidências de conformidade.

Padrões de qualidade

• Requisitos de manutenção: Defina expectativas mínimas de manutenção (por exemplo, atualizações no ano passado).
• Tamanho da comunidade: Estabeleça limites para métricas aceitáveis de integridade da comunidade.
• Padrões de documentação: Especifique os requisitos mínimos de documentação para dependências.
• Práticas de segurança: Exigir que as dependências tenham políticas de segurança publicadas e tratamento de vulnerabilidades responsivas.

Entender o que inspecionar e validar fornece a base para implementar ferramentas automatizadas de Análise de Composição de Software. A próxima unidade explora os conceitos básicos do SCA e como as ferramentas automatizadas abordam os desafios do gerenciamento manual de dependências.