A nova prioridade de segurança do CIO: sua cadeia de suprimentos de software

Uma razão pela qual o código aberto é popular nas empresas é que ele fornece blocos de construção bem testados que podem acelerar a criação de aplicativos e serviços sofisticados. Mas os componentes de software de terceiros e a conveniência de pacotes e contêineres trazem riscos junto com os benefícios, porque os aplicativos que você cria são tão seguros quanto essas dependências.

Os ataques à cadeia de suprimentos de software estão se tornando tão difundidos que o Gartner os listou como a segunda maior ameaça para 2022. Até 2025, a empresa de pesquisa prevê que 45% das organizações em todo o mundo terão sofrido um ou mais ataques à cadeia de suprimentos de software – e 82% dos CIOs pensam que eles serão vulneráveis a eles. Isso inclui ataques por meio de vulnerabilidades em componentes de software amplamente usados, como Log4j, ataques contra o pipeline de compilação (c.f., hacks SolarWinds, Kaseya e Codecov) ou hackers comprometendo os próprios repositórios de pacotes.

“Os invasores mudaram a prioridade dos ambientes de produção para as cadeias de suprimentos de software porque as cadeias de suprimentos de software são o elo mais fraco”, explica Lior Levy, CEO da Cycode. “Enquanto as cadeias de suprimentos de software continuarem sendo alvos relativamente fáceis, os ataques à cadeia de suprimentos de software aumentarão”.

Incidentes recentes de alto nível foram um alerta para a indústria de desenvolvimento de software, diz Rani Osnat, Vice-Presidente Sênior de Estratégia da Aqua Security. “Descobrimos décadas de opacidade e falta de transparência e é por isso que é um grande negócio”.

Estudos de bases de código que usam código-fonte aberto mostram que vulnerabilidades e componentes desatualizados ou abandonados são comuns: 81% das bases de código tinham pelo menos uma vulnerabilidade, 50% tinham mais de uma vulnerabilidade de alto risco e 88% usavam componentes que não eram a versão mais recente ou não tiveram nenhum novo desenvolvimento em dois anos.

É improvável que esses problemas prejudiquem a popularidade do código aberto – e software e serviços comerciais também são vulneráveis. Quando o LastPass foi atacado, não perdeu os dados do cliente, mas uma parte não autorizada conseguiu visualizar e baixar parte de seu código-fonte, o que pode facilitar o ataque aos usuários do gerenciador de senhas no futuro, e a violação do Twilio permitiu invasores para lançar ataques da cadeia de suprimentos em organizações downstream.

A ameaça do “código sombra”

Assim como as equipes de segurança defendem suas redes como se já tivessem sido violadas, os CIOs devem assumir todo o código, interno ou externo, e até mesmo os ambientes de desenvolvimento e ferramentas que seus desenvolvedores usam já foram comprometidos e políticas foram implementadas para proteger e minimizar o impacto de ataques contra suas cadeias de fornecimento de software.

Na verdade, Osnat sugere que os CIOs pensem sobre esse “código sombra” da mesma forma que pensam sobre a TI sombra. “Isso precisa ser visto como algo que não é apenas um problema de segurança, mas realmente algo que vai a fundo em como você obtém software, seja de código aberto ou comercial: como você o traz para o seu ambiente, como você o atualiza, que tipo de controles você deseja ter em vigor e que tipo de controles você deseja exigir de seus fornecedores”, diz ele.

Transparência: Rumo a uma lista de materiais de software

As cadeias de suprimentos físicas já usam rótulos, listas de ingredientes, fichas de dados de segurança e listas de materiais para que reguladores e consumidores saibam o que acaba nos produtos. Novas iniciativas visam aplicar abordagens semelhantes ao software, ajudando as organizações a entender a teia de dependências e a superfície de ataque de seu processo de desenvolvimento de software.

A ordem executiva 14028 da Casa Branca sobre segurança da cadeia de suprimentos de software exige que os fornecedores de software, que fornecem ao governo federal, forneçam uma lista de materiais de software (SBOM) e usem os níveis da cadeia de suprimentos para a lista de verificação de segurança de artefatos de software (SLSA), para evitar adulterações. Por causa disso, “estamos vendo muitas empresas dando uma olhada muito mais séria em sua cadeia de suprimentos de software”, diz Janet Worthington, Analista Sênior da Forrester. “Todas as empresas hoje produzem e consomem software e estamos vendo mais produtores virem até nós e dizerem: ‘Como faço para produzir software seguro e que posso atestar com uma lista de materiais de software’”.

Existem vários projetos intersetoriais, incluindo a Iniciativa Nacional do NIST para Melhorar a Segurança Cibernética em Cadeias de Suprimentos (NIICS), a Iniciativa de Integridade, Transparência e Confiança da Cadeia de Suprimentos (SCITT), da Microsoft, e outros membros do IETF, bem como o Grupo de Trabalho de Integridade da Cadeia de Suprimentos OpenSSF.

“Todo mundo está adotando uma abordagem mais holística e dizendo: ‘Espere um minuto, preciso saber o que estou trazendo para minha cadeia de suprimentos com a qual estou criando o software’”, diz Worthington.

Uma pesquisa recente da Linux Foundation descobriu que a conscientização do SBOM é alta, com 47% dos fornecedores de TI, provedores de serviços e setores regulamentados usando SBOMs hoje e 88% esperando usá-los em 2023.

SBOMs serão mais úteis para organizações que já possuem gerenciamento de ativos para componentes de software e APIs. “As pessoas que têm processos robustos de desenvolvimento de software hoje acham mais fácil inserir ferramentas que podem gerar uma lista de materiais de software”, diz Worthington.

SBOMs podem ser criados pelo sistema de compilação ou podem ser gerados por ferramentas de análise de composição de software após o fato. Muitas ferramentas podem ser integradas em pipelines de CI/CD e executadas como parte de uma compilação ou mesmo quando você baixa bibliotecas, diz ela. “Ele pode avisá-lo: ‘Ei, você tem esse componente em seu pipeline e tem um problema crítico, você quer continuar?’”

Para que isso seja útil, você precisa de políticas claras sobre como as equipes de desenvolvedores adquirem software de código aberto, diz Dan Lorenc, CEO da Chainguard. “Como os desenvolvedores sabem quais são as políticas de sua empresa para o que é considerado ‘seguro’ e como eles sabem que o código aberto que estão adquirindo, que constitui a grande maioria de todos os softwares usados pelos desenvolvedores hoje em dia, é realmente inalterado?”

Ele aponta para o projeto Sigstore de código aberto que JavaScript, Java, Kubernetes e Python usam para estabelecer a proveniência de pacotes de software. “Sigstore é para integridade de software o mesmo que certificados são para sites; eles basicamente estabelecem uma cadeia de custódia e um sistema de verificação de confiança”, diz ele.

“Acho que um CIO deve começar doutrinando suas equipes de desenvolvedores nessas etapas fundamentais de usar abordagens padrão do setor emergente para: um, bloquear sistemas de compilação; e dois, criar um método repetível para verificar a confiabilidade dos artefatos de software antes de trazê-los para o ambiente”, diz Lorenc.

Fazendo a contribuição

Sejam componentes, APIs ou funções sem servidor, a maioria das organizações subestima o que está usando em uma ordem de magnitude, a menos que executem inventários de rotina, aponta Worthington. “Eles descobrem que algumas dessas APIs não estão usando métodos de autenticação adequados ou talvez não estejam escritas da maneira que esperavam e talvez algumas delas estejam até obsoletas”, diz ela.

Além das vulnerabilidades, avaliar o suporte da comunidade por trás de um pacote é tão importante quanto entender o que o código faz, porque nem todos os mantenedores querem o ônus de ter seu código tratado como um recurso crítico. “Nem todo código aberto é igual”, ela adverte.

“O código aberto pode ser gratuito para download, mas certamente o uso dele não é gratuito. Seu uso significa que você é responsável por entender a postura de segurança por trás disso, porque está em sua cadeia de suprimentos. Você precisa contribuir de volta para ele. Seus desenvolvedores precisam participar da correção de vulnerabilidades”, diz Worthington, que sugere que as organizações também devam estar preparadas para contribuir monetariamente, seja diretamente para projetos de código aberto ou para iniciativas que os apoiem com recursos e fundos. “Quando você cria uma estratégia de código aberto, parte disso é entender o orçamento e as implicações”.

Não pense nisso apenas como uma despesa, mas como uma oportunidade de entender melhor os componentes dos quais você depende. “Até ajuda a reter os desenvolvedores porque eles sentem que fazem parte da comunidade. Eles estão sendo capazes de contribuir com suas habilidades. Eles podem usar isso em seu currículo”, acrescenta ela.

Lembre-se de que as vulnerabilidades podem ser encontradas em qualquer lugar em sua pilha de tecnologia, incluindo mainframes, que cada vez mais executam Linux e código aberto como parte da carga de trabalho, mas geralmente não possuem os processos e estruturas de segurança que se tornaram comuns em outros ambientes.

Protegendo seu pipeline

Proteger seu pipeline de entrega de software também é importante. O Secure Software Development Framework (SSDF) e SLSA, do NIST, é um bom lugar para começar: abrange as melhores práticas em vários níveis de maturidade, começando com um sistema de compilação simples, usando logs e metadados para auditoria e resposta a incidentes até um pipeline de compilação totalmente seguro. O white paper de práticas recomendadas da cadeia de suprimentos de software da CNCF, a orientação do Gartner sobre mitigar os riscos de segurança da cadeia de suprimentos de software e o OSS Secure Supply Chain Framework, da Microsoft, que inclui processos e ferramentas, também são úteis.

É importante observar, no entanto, que simplesmente ativar ferramentas de varredura automatizadas destinadas a encontrar códigos maliciosos pode produzir muitos falsos positivos para serem úteis. E embora os sistemas de controle de versão como BitBucket, GitHub, GitLab e outros incluam recursos de segurança e proteção de acesso (incluindo controles de política de acesso cada vez mais granulares, proteção de filiais, assinatura de código, exigindo MFA para todos os colaboradores e verificação de segredos e credenciais), eles muitas vezes precisam ser explicitamente habilitados.

Além disso, projetos como Factory for Repeatable Secure Creation of Artifacts (FRSCA) que visam proteger pipelines de compilação implementando SLSA em uma única pilha ainda não estão prontos para produção, mas os CIOs devem esperar que os sistemas de compilação incluam mais dessas práticas no futuro.

De fato, enquanto os SBOMs são apenas parte da resposta, as ferramentas para criá-los e trabalhar com eles também estão amadurecendo, assim como os processos para solicitá-los e consumi-los. Os contratos precisam especificar não apenas que você deseja SBOMs, mas com que frequência você espera que eles sejam atualizados e se eles incluirão relatórios e notificações de vulnerabilidades, aconselha Worthington. “Se uma nova vulnerabilidade importante como o Log4j for encontrada, o fornecedor vai me dizer ou terei que pesquisar sozinha no SBOM para ver se sou afetada?”

As organizações também precisarão de ferramentas para ler SBOMs e implementar processos para realizar ações sobre o que essas ferramentas encontrarem. “Preciso de uma ferramenta que possa me dizer quais são as vulnerabilidades conhecidas [no SBOM], quais são as implicações da licença. E isso acontece continuamente”, diz Worthington.

Os CIOs devem ter em mente que um SBOM “é um facilitador, mas na verdade não resolve nada em termos de segurança de sua cadeia de suprimentos. Ele ajuda você a lidar com incidentes que podem surgir no seu caminho”, diz Osnat, que está otimista sobre a velocidade de resposta do setor e a ampla colaboração que está acontecendo em torno de padrões para SBOMs e atestado de código que ajudará a tornar as ferramentas interoperáveis ​​(algo que as organizações levantaram como uma preocupação particular na pesquisa da Linux Foundation). Isso poderia levar às mesmas melhorias nos padrões de transparência e relatórios em todo o setor que o SOC 2 forneceu.

Dito isso, os CIOs não precisam esperar por novos padrões ou ferramentas para começar a tornar a segurança uma parte tão importante do papel do desenvolvedor quanto a qualidade se tornou nos últimos anos, diz Osnat. Sua sugestão: “Comece reunindo seu CISO e o engenheiro-chefe em uma sala para descobrir qual é o modelo certo para fazer isso funcionar para sua organização e como essa transformação ocorrerá”.