Autor: Dong Renyuan, gerente geral da JFrog Greater China
Se as empresas nacionais desejam construir, gerenciar e liberar software com rapidez e segurança, elas devem criar um processo de software seguro e desimpedido, desde os desenvolvedores até a integração do equipamento. O código criado pelos desenvolvedores é apenas o começo do desenvolvimento de software, e hoje os desenvolvedores gerenciam toda a cadeia de suprimentos de software. A cadeia de suprimentos de software de uma empresa é composta de muitas partes e inclui várias fontes: pacotes de código aberto, software comercial, arquivos de infraestrutura como código (IaC), contêineres, imagens do sistema operacional e muito mais. Essa diversidade significa que há muitos pontos de risco na cadeia de suprimentos de software de uma empresa, e a gama de ameaças à segurança devido a erros, omissões, baixa qualidade ou ataques maliciosos é muito ampla.
Tendências de risco da cadeia de suprimentos de software
Compreender a localização dos pontos de risco vulneráveis é muito importante para proteger a cadeia de suprimentos de software. Mas responder uma a uma com soluções pontuais é como um jogo de maluco, onde ameaças esmagadas podem ressurgir em outro lugar, sem serem notadas.
Para proteger totalmente a cadeia de suprimentos contra ameaças, é necessária vigilância constante do início ao fim, mesmo antes de os desenvolvedores invocarem pacotes externos. Seja no processo de desenvolvimento de código proprietário, compilação de código e construção temporária, ou no pipeline de computação geral para lançamento e distribuição, até a produção e mesmo após a implantação, todos os detalhes devem ser observados. Além de revelar vulnerabilidades e outros problemas de segurança, você precisa conhecer o contexto para determinar o risco real.
Duas principais vias de ameaça à cadeia de suprimentos de software
A primeira é explorar a "abertura" da cadeia de suprimentos para obter informações sobre o software que um invasor planeja atacar. Um exemplo comum é quando um invasor tenta mapear remotamente um serviço da Web ou descartar um software direcionado a um dispositivo IoT, familiarizando-se com os pacotes de código aberto que ele usa. Eles podem facilmente encontrar informações sobre vulnerabilidades e exposições comuns (CVE) associadas a esses pacotes, aprender sobre a configuração de segurança dos pacotes e até mesmo tentar encontrar vulnerabilidades desconhecidas (também conhecidas como dias zero). Quando informações suficientes sobre o caminho de exploração são obtidas, o invasor pode prosseguir para o segundo estágio.
A segunda é que os invasores usarão a cadeia de suprimentos para injetar pacotes maliciosos e códigos maliciosos em repositórios públicos ou privados, ou para alterar o código existente e incluir partes maliciosas nele.
Quatro riscos proeminentes ameaçam a segurança da cadeia de suprimentos de software
1. Vulnerabilidades conhecidas
Componentes de terceiros (como software de código aberto e comercial) podem conter vulnerabilidades de natureza não intencional, muitas das quais são conhecidas e rastreadas publicamente nos bancos de dados de vulnerabilidade do NVD e VulnDB.
Esse risco pode ser descoberto por meio de uma solução de Análise de Componente de Software (SCA) que identifica a Lista de Materiais de Software (SBOM) para um código ou artefato específico e a correlaciona com CVEs conhecidos, principalmente identificando que os metadados de software são cruzados com bancos de dados CVE públicos.
No entanto, informações suficientes precisam estar disponíveis para tomar decisões baseadas em risco e automatizá-las. Um banco de dados escalável é obrigatório, não apenas para rastrear mais riscos, mas também para conduzir pesquisas de segurança aprofundadas para entender todas as maneiras pelas quais esses riscos podem ser mitigados, para que o método mais prático e econômico possa ser selecionado.
Igualmente importante é a análise de cenário para determinar a probabilidade de uma vulnerabilidade ser explorada. Por exemplo, a funcionalidade vulnerável em um componente pode não ser usada pelo aplicativo, ou o programa vulnerável nunca é executado em compilações de produção, ou uma configuração específica invalidaria um determinado CVE.
Possíveis riscos operacionais também podem ser identificados a partir de componentes aparentemente seguros. Por exemplo, um pacote de código aberto que não é mantido por muito tempo pode não ser monitorado adequadamente quanto a problemas de segurança. Nesse caso, a vulnerabilidade é incerta, mas a ameaça potencial é previsível.
Esses riscos conhecidos e antecipados podem e devem ser descobertos das seguintes maneiras:
- Código-fonte: a vigilância de segurança deslocada para a esquerda até o ponto de criação do código economiza o custo de correções posteriores. As equipes de segurança podem criar um repositório interno de componentes de terceiros aprovados e os desenvolvedores podem ser alertados sobre dependências fracas por meio de extensões para seus ambientes de desenvolvimento integrado (IDEs). Embora inerentemente incompleta, essa abordagem ajuda a evitar riscos conhecidos. Observe que não pode ser exaustivo, porque as ferramentas de segurança shift-left muitas vezes deixam os desenvolvedores com centenas ou milhares de tarefas de trabalho que não são necessariamente impactantes do ponto de vista da segurança, porque completariam cenários que ignoram vulnerabilidades ou problemas de segurança.
- Binários: análise automatizada de composição de software (SCA) de todos os pacotes de software, compilações e imagens em repositórios binários críticos (incluindo componentes próprios e de terceiros), garantindo que toda a cadeia de suprimentos de software esteja protegida contra vulnerabilidades conhecidas e o impacto do risco operacional. Como a representação mais precisa do estado da fase de produção de um aplicativo, os binários permitem a análise de risco do mundo real da mais alta qualidade e fornecem um cenário mais preciso. Os binários também permitem a análise de problemas que são “pontos cegos” para ferramentas shift-left e soluções de segurança na produção.
2. Vulnerabilidades desconhecidas (vulnerabilidades de dia zero)
Erros na codificação são comuns. Falhas lógicas, criptografia ruim e possível corrupção de memória podem inadvertidamente tornar os aplicativos vulneráveis a ataques mal-intencionados, como execução remota de código (RCE) e negação de serviço (DoS). Esses bugs podem permanecer ocultos em códigos próprios e de terceiros, ou até mesmo permanecer inativos por anos antes de serem identificados.
Esses problemas são conhecidos como problemas de "dia zero", em parte por causa de sua longevidade, mas também por causa de sua urgência, o que significa que não há tempo para a equipe corrigi-los no software implantado.
Para capturar e prevenir possíveis problemas de dia zero, cada componente e aplicativo deve ser testado levando em consideração a fluidez entre diferentes binários, processos e serviços. As ferramentas de análise estática de código (revisão do código-fonte) e revisão dinâmica de código (teste do código em execução) normalmente identificam cerca de 85% dos defeitos, mas geralmente geram dezenas de milhares de entradas por compilação e exigem conhecimento especializado para interpretar e priorizar os resultados. No entanto, uma possível vulnerabilidade não significa que ela possa ser explorada.
Técnicas mais avançadas combinam execução simbólica, análise de fluxo de dados e fuzzing automatizado para reduzir significativamente as taxas de falsos positivos e identificar vulnerabilidades que o SAST/DAST típico não consegue. Combinar a análise de código-fonte e binários também produz melhores resultados e ajuda desenvolvedores, equipes de segurança e gerentes de produção a se concentrarem na correção de problemas importantes.
Apesar de todos os esforços, novas vulnerabilidades podem ser descobertas e afetar o software implantado. As varreduras SCA contínuas ajudam a garantir a notificação imediata de quaisquer CVEs mais recentes que afetem o software em estágio de produção. Os metadados SBOM avançados ajudam a entender rapidamente o impacto total de uma vulnerabilidade em uma organização e resolvê-la ou corrigi-la em todo o inventário geral de aplicativos. Os repositórios de código e artefato devidamente integrados permitem uma ação rápida em toda a organização para lidar com as ameaças descobertas.
3. Problemas de não codificação
Nem todas as vulnerabilidades existem no código, mas também podem existir em binários (como EPMs), contêineres de arquivos jar, firmware e artefatos de suporte (como arquivos de configuração ou arquivos IaC). Configuração incorreta, criptografia ruim, exposição de chaves secretas e privadas ou problemas no sistema operacional podem criar superfícies de ataque.
Esses efeitos colaterais de erro humano geralmente são resultado de falta de atenção, não de intenção maliciosa, e geralmente são introduzidos fora do foco de desenvolvimento principal. As configurações usadas para teste podem ser inadvertidamente promovidas para produção. Esses riscos geralmente são fáceis de corrigir, mas mais difíceis de detectar e ainda mais difíceis de se recuperar.
Mesmo boas intenções podem levar a consequências maliciosas, por exemplo, expor uma senha em um servidor público pode convidar à injeção de código mal-intencionado que expõe dados confidenciais. A confusão de dependência entre pacotes com nomes semelhantes também pode ocorrer em situações maliciosas não 30, especialmente quando a resolução do repositório de pacotes está mal configurada.
A detecção precoce desses problemas, antes que eles avancem para o estágio de produção, é fundamental. Esses riscos potenciais precisam ser levados tão a sério quanto as vulnerabilidades em seu código, e essa vigilância incorporada à postura de segurança de ponta a ponta do pipeline.
4. Código malicioso
Ameaças intencionais (seja de ataques de injeção externos ou internos mal-intencionados) geralmente são as mais difíceis de detectar, pois geralmente são mascaradas para aparecer como componentes autenticados. A distribuição de cavalos de Tróia, bots, ransomware, software de criptografia e spyware geralmente são vetores eficazes para os tipos mais benignos de vulnerabilidades. Plantar repositórios comumente usados com pacotes de software prejudiciais, comprometer contas de mantenedor para alterar pacotes existentes ou injetar código em repositórios de origem comprometidos são métodos comuns de ataques de acesso backdoor.
Quando esses ataques são descobertos após a implantação, geralmente é tarde demais, o dano já foi feito e pode custar muito caro. É por isso que deve ser protegido no pipeline geral:
- Controle de acesso: os repositórios de pacotes internos devem restringir o acesso de gravação às principais funções e membros da equipe com permissões consistentes e autenticação de segurança (incluindo autenticação multifator) em toda a organização.
- Repositórios de proxy: o armazenamento em cache de repositórios externos, como Maven Central e npm, fornece instantâneos imutáveis de recursos de terceiros, para que qualquer substituição maliciosa subsequente seja imediatamente aparente.
- Teste e análise: ferramentas avançadas de análise estática e dinâmica detectam e sinalizam códigos maliciosos e pacotes de software problemáticos. A equipe de pesquisa de segurança do JFrog descobriu e divulgou mais de 1.300 pacotes maliciosos em repositórios de pacotes públicos por meio de ferramentas desenvolvidas por ela.
Vigilância de ponta a ponta para gerenciamento de riscos da cadeia de suprimentos de software
Embora algumas dessas tendências de risco possam ser abordadas de uma só vez, as soluções pontuais podem servir apenas como sistemas de alarme e ajudar apenas quando necessário.
Pela mesma razão, as soluções de segurança individuais podem ser de ajuda limitada devido ao seu escopo limitado, elas não podem ajudar a analisar e julgar o cenário completo de riscos em toda a cadeia de suprimentos de software. Quando desconectado de repositórios e soluções de gerenciamento de software, pode ser difícil tomar medidas efetivas para remediar e responder aos problemas encontrados, mesmo que as soluções de ponto de segurança sejam muito precisas.
Uma postura de segurança abrangente não pode se concentrar em pontos isolados no pipeline, ela deve ser capaz de conectar esses muitos pontos de descoberta de diferentes problemas e aspectos de segurança de uma forma que as soluções de nicho sozinhas não conseguem.
Manter a segurança do software requer vigilância de ponta a ponta, desde o IDE do desenvolvedor até a produção, com supervisão de riscos consistente e implementação de contramedidas nos ambientes de desenvolvimento e produção. As soluções de segurança devem ser aplicadas em toda a cadeia de suprimentos de software e ser capazes de atuar em escala. Para garantir consistência em toda a organização, suas operações devem girar em torno de uma única fonte de verdade para todos os binários, profundamente integrada às ferramentas DevOps.