Segurança de Dependências e Análise de Composição de Software

As aplicações modernas são compostas em grande parte por bibliotecas e frameworks de código aberto de terceiros. Uma aplicação típica em Node.js pode ter mais de 1.000 dependencies transitivas; um projeto Java pode incorporar centenas de artefatos Maven. Cada dependency é uma possível superfície de ataque. A vulnerabilidade Log4Shell (CVE-2021-44228) na biblioteca Log4j demonstrou que uma única dependency poderia tornar milhões de aplicações imediatamente exploráveis em todo o mundo poucos dias após sua divulgação.

As ferramentas de Software Composition Analysis (SCA) fazem automaticamente o inventário de todos os componentes de código aberto de uma aplicação — incluindo dependencies transitivas (as dependencies das suas dependencies) — e verificam continuamente esses componentes em bancos de dados de vulnerabilidades em busca de CVEs conhecidos. A SCA produz uma Software Bill of Materials (SBOM) que lista cada componente e sua versão, permitindo identificar rapidamente os sistemas afetados quando novas vulnerabilidades são divulgadas.

Dependencies transitivas são bibliotecas das quais suas dependencies diretas dependem, mas que você não escolheu explicitamente. Você pode depender diretamente do Package A, que depende do Package B (versão 1.2), que depende do Package C (versão 3.0 — uma versão vulnerável). Você não tem conhecimento do Package C, mas sua aplicação o executa. As ferramentas de SCA percorrem toda a árvore de dependencies para revelar essas vulnerabilidades ocultas, que não são diretamente visíveis aos desenvolvedores.

Uma Software Bill of Materials (SBOM) é um inventário formal e legível por máquina de todos os componentes de um produto de software — semelhante à lista de ingredientes de um alimento. Os formatos de SBOM incluem SPDX (Linux Foundation) e CycloneDX (OWASP). A Ordem Executiva 14028 (2021) dos US determinou o uso de SBOMs para softwares vendidos ao governo federal. Com uma SBOM, as equipes de segurança podem consultar imediatamente: "quais dos nossos produtos contêm Log4j?" e obter respostas em minutos, em vez de passar dias fazendo buscas manuais.

A fixação de versões de dependencies especifica versões exatas das dependencies, em vez de intervalos flexíveis (^1.2.3 ou *). Os arquivos de bloqueio (package-lock.json, yarn.lock, Pipfile.lock, Gemfile.lock) registram a versão exata resolvida de cada dependency no momento da instalação. Esses arquivos devem ser enviados ao controle de código-fonte para garantir que todos os membros da equipe e todos os pipelines de CI/CD usem versões idênticas das dependencies, evitando ataques à cadeia de suprimentos que envenenem as versões dos pacotes entre instalações.

Os ataques à cadeia de suprimentos têm como alvo o ecossistema de dependencies. Typosquatting consiste em publicar pacotes maliciosos com nomes semelhantes aos de pacotes populares (por exemplo, lodahs em vez de lodash), na esperança de que os desenvolvedores digitem o nome incorretamente. Ataques de Dependency Confusion exploram a ordem em que os gerenciadores de pacotes pesquisam os registros — um atacante publica um pacote malicioso com o mesmo nome de um pacote privado interno, mas com um número de versão maior, fazendo o gerenciador de pacotes instalar a versão pública maliciosa.

Várias ferramentas de SCA são amplamente usadas no setor. A Snyk fornece verificação de dependencies voltada para desenvolvedores, com solicitações de pull automáticas para correção. O OWASP Dependency-Check é uma ferramenta gratuita e amplamente adotada para Java, .NET, Python e Ruby. O GitHub Dependabot abre automaticamente solicitações de pull para atualizar dependencies vulneráveis em repositórios do GitHub. O JFrog Xray e o Sonatype Nexus IQ integram a SCA aos repositórios de artefatos para impedir que compilações vulneráveis cheguem à produção.

A SCA é mais eficaz quando integrada como um gate de qualidade no pipeline de CI/CD. A cada solicitação de pull e compilação, o pipeline executa a ferramenta de SCA e interrompe a compilação se forem encontrados CVEs de severidade crítica ou alta nas dependencies. Essa abordagem de "shift left" detecta dependencies vulneráveis antes que cheguem à produção — e não meses depois, durante uma revisão manual de segurança ou após uma violação. As equipes devem definir limites claros de severidade de vulnerabilidades para determinar quais bloqueiam a implantação e quais geram apenas avisos.

Antes de adicionar uma dependency, avalie sua postura de segurança usando vários indicadores. Atividade de manutenção: o projeto é mantido ativamente? Quando ocorreu o último commit e lançamento? Histórico de vulnerabilidades conhecidas: quantos CVEs ele teve e com que rapidez foram corrigidos? Volume de downloads: pacotes amplamente usados atraem mais atenção de segurança. Quantidade de dependencies: pacotes com menos dependencies introduzem menos riscos transitivos. O OpenSSF Scorecard fornece uma pontuação automatizada das práticas de segurança de projetos de código aberto.

Quando a SCA identifica uma dependency vulnerável, existem várias estratégias de correção. Atualizar para uma versão corrigida — a opção preferencial quando disponível. A aplicação de correções virtuais por meio de regras do WAF pode reduzir o risco de caminhos de exploração conhecidos enquanto uma atualização é preparada. Remover a dependency se ela não for mais necessária. Aceitar o risco, com justificativa documentada, se a vulnerabilidade não for explorável no contexto específico de uso (por exemplo, uma vulnerabilidade do lado do servidor em uma biblioteca do lado do cliente). Nunca deixe vulnerabilidades críticas sem tratamento e sem uma aceitação documentada.

As ferramentas de SCA têm uma finalidade dupla: identificam vulnerabilidades de segurança e sinalizam problemas de conformidade de licenças em dependencies de código aberto. Entre as licenças problemáticas comuns estão a GPL v2/v3 (copyleft — exige que seu produto também seja disponibilizado como código aberto se você o distribuir), a AGPL (estende a GPL aos serviços de rede) e a SSPL. Usar uma biblioteca licenciada sob a GPL em um software comercial proprietário sem uma licença comercial pode gerar sérias responsabilidades jurídicas. Ferramentas de SCA como FOSSA, Black Duck e WhiteSource automatizam a verificação de licenças juntamente com a detecção de vulnerabilidades, garantindo a conformidade com as obrigações relativas ao código aberto.

Teste sua compreensão dos conceitos do CompTIA Security+ (SY0-701) apresentados nesta lição.

Nesta lição, você aprendeu que: as ferramentas de SCA analisam toda a árvore de dependencies, incluindo as dependencies transitivas, em busca de CVEs conhecidos; as SBOMs fornecem um inventário legível por máquina, permitindo uma resposta rápida quando novas vulnerabilidades são divulgadas; e a integração da SCA como um gate de qualidade de CI/CD detecta dependencies vulneráveis antes que cheguem à produção. A seguir, exploraremos o DevSecOps e como deslocar os controles de segurança para o início de todo o pipeline de CI/CD.