A grande lacuna na segurança da cadeia de fornecimento de software

Se as cadeias de fornecimento de software consistissem apenas em código-fonte aberto, seria fácil protegê-las. Existem ferramentas e metodologias eficazes para descobrir e remediar riscos de segurança da cadeia de fornecimento de software que surgem de componentes de código aberto.

Mas as cadeias de abastecimento também podem conter, e normalmente contêm, código-fonte fechado derivado de fontes de terceiros. Proteger esta parte da cadeia de fornecimento muitas vezes se mostra muito mais desafiador porque as ferramentas de segurança da cadeia de fornecimento de software muitas vezes não se concentram em código-fonte fechado. Quando você adiciona aplicativos de software como serviço (SaaS) ao mix, proteger a cadeia de suprimentos se torna ainda mais complicado.

Esses desafios podem ser resolvidos, mas exigem uma abordagem mais ampla à segurança da cadeia de fornecimento de software do que algumas empresas adotam. Veja por que proteger o código aberto por si só não é suficiente e como as organizações podem fazer melhor.

As três categorias de cadeias de fornecimento de software

Em termos gerais, podem existir três tipos de software dentro de uma cadeia de fornecimento de software (o que significa o conjunto de recursos de software de terceiros que uma empresa utiliza):

• Bibliotecas de código aberto, módulos e outros códigos que os desenvolvedores integram em aplicativos que constroem ou aproveitam como dependências
• Produtos de código fechado de fornecedores externos que as empresas implantam e gerenciam em sua infraestrutura
• Aplicativos SaaS desenvolvidos, hospedados e gerenciados por um fornecedor externo, mas usados ​​pela empresa

A maioria das organizações utiliza uma combinação desses tipos de recursos de software. Por exemplo, a IDC descobriu que 66,7% das empresas identificaram o código aberto como “crítico” ou “importante” para as suas organizações (da IDC Cinco temas de software de código aberto para abraçarnovembro de 2023). Ao mesmo tempo, aproximadamente um terço das empresas depende de aplicações SaaS para alimentar as principais funções empresariais, um número que a IDC espera aumentar ao longo do tempo (o relatório da IDC Resumo executivo do SaaSPath 2023: examinando a jornada do comprador de SaaSjunho de 2023). Outras funções de negócios provavelmente são abordadas usando aplicativos de código fechado de terceiros que as próprias organizações operam, uma vez que poucas empresas criam software de negócios totalmente do zero.

O estranho papel do código-fonte fechado na segurança da cadeia de suprimentos

Apesar dos diversos tipos de software que existem na maioria das cadeias de abastecimento, as ferramentas e estratégias de segurança da cadeia de abastecimento de software tendem a concentrar-se principalmente nos riscos associados ao código aberto.

Por exemplo, uma categoria chave de ferramentas de segurança da cadeia de fornecimento de software é a análise de composição de software (SCA). Normalmente, as soluções SCA funcionam verificando aplicativos para identificar componentes que se assemelham ao código-fonte aberto e, em seguida, sinalizando quaisquer componentes que estejam sujeitos a vulnerabilidades de segurança conhecidas. Essa abordagem não funciona bem para descobrir falhas vinculadas ao código-fonte fechado porque esse código é secreto. Como resultado, os scanners SCA normalmente não conseguem identificar componentes vulneráveis ​​de código fechado, a menos que tenham acesso a repositórios de códigos privados e bancos de dados de vulnerabilidades — o que raramente é o caso.

Da mesma forma, a criação de uma lista de materiais de software (SBOM), que rastreia componentes e dependências de software de terceiros, tornou-se uma prática recomendada para proteger a cadeia de fornecimento de software. Mas os SBOMs são projetados principalmente para catalogar software de código aberto. Documentar componentes de código-fonte fechado usando SBOMs pode ser tecnicamente possível, mas muitas das suposições feitas pelos padrões de formatação SBOM não fazem sentido no contexto do código-fonte fechado. Como resultado, poucos SBOMs rastreiam componentes de código fechado.

Em suma, o código-fonte fechado de terceiros se encaixa de maneira estranha, na melhor das hipóteses, nas abordagens modernas de segurança da cadeia de suprimentos de software. Dada a falta de ferramentas e métodos de acompanhamento eficazes, é fácil para as empresas negligenciarem esta parte das suas cadeias de abastecimento.

Por que aplicativos de código fechado e SaaS devem ser rastreados

Tais descuidos podem resultar em riscos enormes. Alguns dos ataques de maior destaque à cadeia de fornecimento de software até o momento – como a violação da SolarWinds – envolveram código-fonte fechado, e não produtos de código-fonte aberto. Quando incidentes como esses ocorrem, as empresas que não conseguem rastrear quais aplicativos de código fechado de terceiros usam correm o risco de não saber que estão vulneráveis ​​ou de não conseguir confirmar se os patches foram instalados.

No geral, vale a pena notar que o risco que envolve as vulnerabilidades de segurança de código fechado é um pouco diferente das falhas de código aberto. Com aplicativos de código fechado, é mais provável que um fornecedor instale automaticamente um patch – embora isso não aconteça necessariamente. Além disso, como as vulnerabilidades de código aberto são documentadas publicamente e, às vezes, acompanhadas de código de exploração, é relativamente fácil para os agentes de ameaças tirar vantagem delas. Explorar vulnerabilidades em código-fonte fechado pode ser mais desafiador porque as informações sobre elas muitas vezes não estão tão prontamente disponíveis.

Mas só porque os aplicativos de código fechado são um pouco menos propensos a ataques em certos aspectos, não significa que as empresas possam simplesmente ignorar o software que não é de código aberto ao proteger suas cadeias de suprimentos. As consequências de um ataque contra aplicativos de código fechado podem ser bastante graves, como sabem muitas empresas que usavam SolarWinds por volta de 2020.

Integrando código fechado na segurança da cadeia de suprimentos de software

Dada a falta de ferramentas de segurança da cadeia de fornecimento de software concebidas para aplicações de código fechado, como podem as empresas obter visibilidade sobre estes recursos e os seus potenciais riscos de segurança?

Parte da resposta é usar ferramentas de arquitetura empresarial (EA) para documentar quais aplicativos a empresa implantou. Neste contexto, estas ferramentas podem servir um propósito semelhante aos SBOMs para código aberto.

Usar SBOMs para rastrear aplicativos SaaS também seria uma prática inteligente. A ideia foi proposta, mas atualmente não é amplamente utilizada.

De um modo mais geral, os líderes de TI e de cibersegurança devem deixar claro que a gestão de código-fonte fechado de terceiros no contexto da segurança da cadeia de abastecimento é tão prioritária como a proteção de componentes de código-fonte aberto. O processo é complicado e não tão simples quanto encontrar e corrigir vulnerabilidades de código aberto, mas é um imperativo para as empresas que desejam assumir um compromisso abrangente com a segurança da cadeia de fornecimento de software.

Saiba mais sobre Pesquisa da IDC para líderes de tecnologia.

A International Data Corporation (IDC) é a principal fornecedora global de inteligência de mercado, serviços de consultoria e eventos para os mercados de tecnologia. A IDC é uma subsidiária integral do International Data Group (IDG Inc.), empresa líder mundial em serviços de mídia, dados e marketing de tecnologia. Recentemente eleita a Empresa Analista do Ano pela terceira vez consecutiva, a Technology Leader Solutions da IDC fornece orientação especializada apoiada por nossos serviços de pesquisa e consultoria líderes do setor, programas robustos de liderança e desenvolvimento e os melhores benchmarking e fornecimento de dados de inteligência da categoria. dos consultores mais experientes do setor. Contate-nos hoje para saber mais.

Christopher Tozzi, consultor adjunto de pesquisa do IDC, é professor sênior de TI e sociedade no Rensselaer Polytechnic Institute. Ele também é autor de milhares de postagens em blogs e artigos para diversos sites de mídia tecnológica, bem como de diversas publicações acadêmicas. Antes de voltar ao seu foco atual em pesquisar e escrever sobre tecnologia, Christopher trabalhou em tempo integral como professor titular de história e como analista para uma startup de tecnologia na área da Baía de São Francisco. Ele também é um geek de longa data em Linux e ocupou cargos na administração de sistemas Linux. Esta combinação incomum de habilidades técnicas “duras” com foco em questões sociais e políticas ajuda Christopher a pensar de maneiras únicas sobre como a tecnologia impacta os negócios e a sociedade.