Este blog aborda os principais pontos do nosso webinarSupply Chain Software : os pontos fracos que os invasores exploram”. Assista ao webinar completo aqui.
Os riscos da cadeia Software aumentaram drasticamente à medida que as organizações passaram a depender mais de componentes de código aberto, pacotes externos e pipelines de desenvolvimento automatizados. Pequenas lacunas que antes pareciam inofensivas agora trazem consequências reais, especialmente à medida que as dependências se tornam mais profundas e difíceis de verificar.
Um exemplo claro dessa mudança foi o recente worm npm Shai-Hulud e Shai-Hulud 2.0, que se espalhou por pacotes comprometidos e afetou milhares de projetos downstream em questão de horas. Incidentes como esse deixam uma coisa clara: as vulnerabilidades da cadeia de suprimentos não ficam mais contidas; elas se espalham por ecossistemas inteiros.
Com 70 a 90% dos softwares modernos compostos por componentes de código aberto, a maioria dos quais os programadores nunca veem diretamente, pequenos problemas podem rapidamente tornar-se grandes riscos. No entanto, apenas 15% das organizações sentem-se confiantes na forma como gerem esse risco de código aberto. Com 70% dos ataques maliciosos de IA previstos para atingir as cadeias de abastecimento até 2025, identificar os pontos fracos na cadeia de abastecimento de software é agora essencial.
Para as equipas de engenharia e segurança, a vantagem é simples: saber onde estão esses pontos fracos significa menos surpresas, tempos de resposta mais rápidos e uma probabilidade muito menor de acabar nas manchetes sobre a cadeia de abastecimento.
As SBOMs já não são opcionais
Para gerir os riscos da cadeia de fornecimento de software e responder às vulnerabilidades, as organizações precisam de uma visão clara do que está na sua pilha de software. A base dessa visibilidade é a SBOM (lista de materiais de software), que cria a transparência necessária para compreender os riscos dos componentes e agir rapidamente quando surgem problemas.
Uma SBOM é definida como um inventário detalhado de todos os componentes fechados e de código aberto, licenças e dependências usados numa aplicação. Esse inventário fornece dados essenciais para transparência, conformidade e gestão de riscos.
O que não é vulnerável ou malicioso hoje pode facilmente tornar-se assim amanhã. Como as vulnerabilidades são descobertas continuamente, inclusive em versões mais antigas, é necessário um monitoramento e um inventário contínuos.
George PrichiciVP, Produtos, OPSWAT
SBOM vs. SCA
Uma coisa importante é a distinção entre SBOM e SCA (AnáliseSoftware ). O SBOM é o inventário, ou uma lista de componentes. O SCA avalia se algum desses componentes é vulnerável, desatualizado ou arriscado. Juntos, eles fornecem às organizações as informações necessárias para tomar decisões informadas, responder mais rapidamente a questões de segurança e fortalecer a gestão geral de riscos.
| Categoria | SBOM | SCA |
|---|---|---|
Objetivo | Inventário de componentes |
Identificar vulnerabilidades nos componentes
|
Cobertura de risco | Conformidade e visibilidade | Riscos de segurança, CVEs, risco de tempo de execução |
Tempo | Pré-implantação/aquisição | Contínuo / compilação e tempo de execução |
Movimentos globais, impulsionados em parte por ataques como o SolarWinds, agora exigem SBOMs, com pressões regulatórias vindas de entidades como CISA, NSA e NIST, bem como da UE e dos países aliados da OTAN, tornando a transparência do SBOM não mais opcional, mas uma expectativa fundamental para qualquer fornecedor de software.
Os 7 pontos fracos críticos que os invasores exploram
A velocidade do desenvolvimento moderno, aliada à forte dependência de código de terceiros e código aberto, introduziu vulnerabilidades graves. Os agentes maliciosos estão a explorar sete pontos fracos principais:
1. Código aberto e risco de dependência
Quando os programadores priorizam a velocidade, muitas vezes utilizam grandes bibliotecas de código aberto sem uma revisão completa do código. Um único componente pode introduzir dependências transitivas adicionais. Se monitorizar apenas o nível superior, pode deixar passar código malicioso injetado nessas dependências transitivas ocultas.
Esse padrão é algo que continuamos a observar em ecossistemas de código aberto. Um pacote comprometido pode se espalhar por cadeias de dependências e atingir milhões de downloads antes que alguém perceba. Um recente ataque à cadeia de suprimentos npm envolvendo criptomalware destaca exatamente como isso acontece na prática.
Melhores práticas:
- Analise todos os pacotes de código aberto e suas cadeias completas de dependências para identificar vulnerabilidades, componentes desatualizados ou malware oculto antes que eles cheguem à sua base de código.
- Monitorize continuamente as dependências ao longo do tempo, uma vez que componentes seguros podem tornar-se arriscados à medida que novos CVEs ou atualizações maliciosas aparecem.
- Use registos confiáveis e verifique a integridade dos pacotes para garantir que os pacotes que você baixa não foram adulterados.
- Aplique políticas que sinalizem ou bloqueiem licenças arriscadas para que termos de licença incompatíveis ou virais não se infiltrem nas suas compilações.
- Adiar a utilização de pacotes recém-publicados até que sejam verificados, reduzindo a possibilidade de introduzir versões não revisadas ou maliciosas no seu ambiente.
2. Risco de licenciamento
As questões de licenciamento agora afetam tanto a engenharia quanto o jurídico. Licenças virais, como a GPL, podem forçar a publicação da sua aplicação resultante sob a mesma licença, potencialmente fazendo com que a sua empresa perca a sua própria propriedade intelectual (PI). É necessário um monitoramento contínuo, pois os termos da licença podem mudar, mesmo para versões mais antigas e anteriormente compatíveis.
Melhores práticas:
- Use uma ferramenta automatizada de detecção de licenças para sinalizar licenças de alto risco ou incompatíveis no início do desenvolvimento. Uma explicação mais detalhada sobre a importância disso está descrita aqui: O papel crucial da detecção de licenças na segurança de código aberto.
- Acompanhe continuamente as alterações nas licenças para detectar mudanças que possam afetar a conformidade ou a exposição de IP.
- Bloqueie ou analise componentes com licenças restritivas ou virais antes que eles entrem na base de código.
- Mantenha um inventário claro de todas as licenças em uso para simplificar auditorias e avaliações de risco.
3. Lacunas nos dados da SBOM ou SBOMs em falta
Embora as regulamentações exijam o compartilhamento de SBOMs, uma lista de alto nível é insuficiente. Dados detalhados, incluindo o autor, colaboradores, frequência de lançamento e status de manutenção, são necessários para uma mitigação e prevenção eficazes.
Melhores práticas:
- Melhore os relatórios SBOM ao verificar novamente os componentes para enriquecê-los com dados de licença atualizados, status de vulnerabilidade e outros metadados críticos. Um exemplo detalhado de como fazer isso está descrito aqui em Validação e enriquecimento do relatório SBOM do CycloneDX.
- Valide e enriqueça as SBOMs usando ferramentas automatizadas para garantir que as informações estejam completas, precisas e acionáveis.
- Exigir que os fornecedores forneçam uma SBOM completa, incluindo dependências transitivas e todos os metadados relevantes.
- Atualize e monitore continuamente os inventários SBOM à medida que os componentes evoluem ou novas vulnerabilidades surgem.
4. Fornecedores terceirizados
Todos os fornecedores em que confia tornam-se parte da sua cadeia de abastecimento. Se eles enviam componentes desatualizados ou comprometidos, você herda esse risco. SBOMs completas, incluindo dependências transitivas, permitem compreender rapidamente a sua exposição, em vez de ter de contactar os fornecedores durante um incidente. Uma publicação recente sobre como gerir vulnerabilidades de dependência na suaSupply Chain Software explora como as equipas podem fortalecer esta parte do processo.
5. Supply Chain com IA
Devido à rápida adoção da IA, as equipas muitas vezes ignoram as restrições normais, tornando isso um importante vetor de ataque. Os invasores injetam código malicioso em modelos de aprendizagem automática, ficheiros PICO ou bibliotecas de código aberto. O typosquatting é comum em ambientes como o Pytorch, onde os utilizadores podem baixar a biblioteca errada, o que pode entregar malware e levar à execução completa de código remoto na máquina de um engenheiro.
6.Container
A verificação de contentores deve evoluir para além do foco exclusivo nas vulnerabilidades. A segurança moderna também deve verificar a presença de malware, mineradores de criptomoedas e ameaças de ação rápida publicadas em imagens de contentores disponíveis publicamente. Uma análise recente do NVIDIA Container CVE-2024-0132 mostra como essas questões podem ser facilmente ignoradas.
7. Fuga de segredos e credenciais
Quando as equipas agem rapidamente, muitas vezes codificam chaves de acesso ou credenciais no código-fonte para testes. Mesmo que sejam sobrescritas posteriormente, essas informações confidenciais geralmente permanecem no histórico do Git, onde são fáceis de serem encontradas por invasores através de varreduras. Desmascarando ameaças ocultas: como detectar informações confidenciais no código mostra como essas exposições acontecem e o que as equipas podem fazer para evitá-las.
O caminho para umaSupply ChainSoftware Secure
Para combater essas ameaças, a segurança deve adotar uma mentalidade de «mudança para a esquerda», o que significa que as mesmas políticas aplicadas antes do lançamento devem ser aplicadas mais cedo no ciclo de desenvolvimento. O objetivo é integrar a segurança como uma sobreposição ao pipeline de CI/CD existente. Essa abordagem automatizada garante a aplicação quando necessário, sem afetar a produtividade da engenharia.
Uma solução abrangente deve fornecer:
- Digitalização automatizada da cadeia de abastecimento em todo o pipeline
- Visibilidade do código-fonte, contentores e ficheiros fornecidos pelo fornecedor
- Análise que vai além dos CVEs para detetar malware, problemas de licença e segredos expostos
Como OPSWAT colmatar essas lacunas
- Multiscanning detetar malware numa fase inicial do processo
- Portas de segurança CI/CD integradas para GitHub, GitLab, TeamCity, Jenkins e muito mais
- Geração automatizada de SBOM e mapeamento de vulnerabilidades
- Assinatura de artefactos e validação da integridade
- Verificação de segredos e aplicação de higiene de credenciais
Fale com um dos nossos especialistas para encontrar soluções personalizadas para a sua pilha hoje mesmo.
