Inspecionar e validar bases de código para fins de 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. As aplicações modernas contêm centenas ou milhares de dependências, tornando a inspeção manual impraticável. Abordagens sistemáticas para deteção de dependência, avaliação de vulnerabilidade e validação de conformidade são essenciais.

Por que a inspeção e a validação são importantes

O desafio da 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 profundas. Um aplicativo típico pode fazer referência direta a 20-30 pacotes, mas depende transitivamente de 200-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: As vulnerabilidades de segurança nas dependências representam riscos significativos. Os atacantes exploram ativamente vulnerabilidades conhecidas em pacotes populares, tornando as dependências não corrigidas alvos atraentes. Violações de alto perfil geralmente envolvem a exploração de vulnerabilidades conhecidas em componentes de código aberto que as organizações não conseguiram atualizar.

O requisito de conformidade: As 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 controlar 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 — é necessária uma validação contínua.

O que inspecionar e validar

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

Inventário de dependência

Criação de uma lista completa de materiais:

• Dependências diretas: Pacotes explicitamente listados em arquivos de manifesto de pacote (package.json, requirements.txt, pom.xml, *.csproj).
• Dependências transitivas: Pacotes exigidos pelas suas dependências diretas, com vários níveis de profundidade.
• Dependências de desenvolvimento: Pacotes usados durante o desenvolvimento e teste, mas não enviados com código de produção.
• Acompanhamento da 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 são importantes:

• Gestão de vulnerabilidades: Não é possível corrigir vulnerabilidades que não conhece.
• Conformidade com a licença: Deve rastrear as obrigações de licença para todas as dependências, não apenas as diretas.
• Planejamento de atualizações: Compreender as relações de dependência ajuda a planejar atualizações que não quebrarão a compatibilidade.
• Visibilidade da cadeia de abastecimento: Saiba exatamente qual código externo está incluído em seus aplicativos.

Deteção de vulnerabilidades de segurança

Identificação de vulnerabilidades conhecidas:

• Mapeamento CVE (Common Vulnerabilities and Exposures): Faça a correspondência entre versões de dependência e bancos de dados CVE que contenham vulnerabilidades conhecidas.
• Avaliação da gravidade: Avalie a gravidade da vulnerabilidade usando pontuações do CVSS (Common Vulnerability Scoring System) que variam de 0 a 10.
• Análise de explorabilidade: Determine se as vulnerabilidades são ativamente exploradas na natureza.
• Disponibilidade do patch: Identifique quais versões corrigem vulnerabilidades e se patches estão disponíveis.

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

• Base de Dados Nacional de Vulnerabilidades (NVD): Repositório do governo dos EUA de dados de vulnerabilidade com base em identificadores CVE.
• Base de Dados de Avisos do GitHub: Compilação de alertas de segurança para pacotes em vários ecossistemas.
• Listas de correio de segurança: Notificações de segurança específicas da linguagem e do framework.
• Bancos de dados de fornecedores: As ferramentas comerciais SCA mantêm bancos de dados proprietários de vulnerabilidades com inteligência adicional.

Categorias de vulnerabilidade em dependências:

• Falhas na 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 sensíveis: 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 ativados.
• Recusa de serviço: Vulnerabilidades de esgotamento de recursos, problemas de complexidade algorítmica.
• Falhas de desserialização: Desserialização insegura levando à execução remota de código.

Validação de conformidade de licença

Identificação das obrigações de licença:

• Deteção de licença: Identifique quais licenças se aplicam a cada dependência.
• Classificação da licença: Categorize as licenças como permissivas, copyleft fraca, 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 das obrigações: Requisitos de documentos 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 pela GPL em software proprietário podem exigir a disponibilização do código aberto de todo o software.
• 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 mudam de licença entre versões, exigindo reavaliação.

Avaliação de risco de licença:

• Alto risco: Fortes licenças copyleft (GPL, AGPL) na distribuição de software proprietário.
• Risco médio: Licenças copyleft fracas (LGPL, MPL) que requerem 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 pouco claro ou informações de licença ausentes.

Avaliação da qualidade da dependência

Avaliando a capacidade de manutenção da dependência:

• Estado de manutenção: Determine se as dependências são mantidas ativamente ou abandonadas.
• Frequência de atualização: Avalie a frequência com que as dependências recebem atualizações e correções de bugs.
• Saúde comunitária: Avalie a atividade do colaborador, os tempos de resposta ao problema e o envolvimento da comunidade.
• Qualidade da documentação: Analise 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, lançamentos recentes, mantenedores responsivos.
• Grande comunidade: Muitos contribuidores, estrelas, garfos e usuários fornecem sustentabilidade.
• Comunicação clara: Rastreador de problemas ativo, discussões responsivas, notas de versão claras.
• Sensibilização para a segurança: Política de segurança publicada, correção imediata de vulnerabilidades, avisos de segurança.

Bandeiras vermelhas:

• Projetos abandonados: Sem atualizações há anos, mantenedores sem resposta, acumulando problemas não resolvidos.
• Risco único do mantenedor: Dependência crítica mantida por uma pessoa que pode ficar indisponível.
• Má qualidade: Testes inadequados, bugs frequentes, alterações que quebram compatibilidade em versões menores.
• Falta de segurança: Nenhuma política de segurança, resposta lenta à vulnerabilidade, problemas de segurança não divulgados.

Desafios da inspeção manual

Por que a inspeção manual não se adapta à escala:

Volume ensurdecedor

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

Informação dispersa

• Várias fontes: As informações sobre vulnerabilidades vêm de bancos de dados CVE, listas de e-mails de segurança, avisos do GitHub, notificações de fornecedores e divulgações de pesquisadores de segurança.
• Pesquisa de licenças: 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 mudar entre versões, exigindo pesquisa específica da versão.
• Informações contraditórias: Fontes diferentes às vezes fornecem informações contraditórias sobre vulnerabilidades ou licenças.

Análise demorada

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

Deteção tardia

• Atraso de descoberta: Os processos manuais detetam 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: As auditorias periódicas deixam os aplicativos vulneráveis entre as auditorias.
• Patches de emergência: Sem monitoramento contínuo, vulnerabilidades críticas exigem patches de emergência disruptivos.

A solução automatizada

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

Deteção 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 lista 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.
• Varredura binária: Algumas ferramentas verificam binários e contêineres compilados para descobrir dependências incorporadas.

Monitorização contínua

• 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 pull automaticamente quando as atualizações de segurança estão disponíveis.
• Visibilidade do painel: Painéis centralizados mostram o status da vulnerabilidade em todos os aplicativos.
• Verificação programada: Verificações automatizadas regulares garantem que os dados de dependência permaneçam atualizados.

Bases de dados abrangentes

• Dados agregados de vulnerabilidade: As ferramentas SCA agregam informações de NVD, GitHub Advisory Database, listas de discussão de segurança e bancos de dados de fornecedores.
• Bases de dados de licenças: Mantenha informações de licença abrangentes, incluindo textos completos de licença e resumos de obrigações.
• Curadoria e verificação: Os fornecedores verificam e selecionam dados de vulnerabilidade para reduzir falsos positivos.
• Inteligência proprietária: As ferramentas comerciais fornecem pesquisa e análise adicionais para além das bases de dados públicas.

Análise inteligente

• Pontuação de gravidade: Calcule automaticamente as pontuações do CVSS e priorize as vulnerabilidades por risco.
• Análise de acessibilidade: Determine se os caminhos de código vulneráveis são realmente usados em seu aplicativo.
• Orientação de remediação: Forneça recomendações de versão específicas que corrijam vulnerabilidades, mantendo a compatibilidade.
• Aplicação da política: Falha automaticamente nas compilações ou bloqueia implantações quando violações de política são detetadas.

Estabelecimento de bases de referência de validação

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

Políticas de segurança

• Tolerância à vulnerabilidade: Defina quais gravidades de vulnerabilidade são aceitáveis (por exemplo, nenhum meio crítico ou alto, limitado).
• Prazos de aplicação: Estabeleça a rapidez com que diferentes vulnerabilidades de gravidade devem ser corrigidas.
• Processos de exceção: Crie procedimentos para aceitar riscos quando a aplicação imediata de patches não for viável.
• Requisitos em matéria de apresentação de relatórios: Defina quem precisa de notificações de vulnerabilidade e com que rapidez.

Políticas de conformidade

• Licenças aprovadas: Liste 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: Especificar os requisitos de documentação para evidência de conformidade.

Normas 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 saúde comunitária.
• Normas de documentação: Especifique os requisitos mínimos de documentação para dependências.
• Práticas de segurança: Exija que as dependências tenham políticas de segurança publicadas e tratamento de vulnerabilidades responsivo.

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