Por Mary Branscombe

Uma razão pela qual o código aberto é popular na empresa é porque fornece blocos de construção bem testados que podem acelerar a criação de aplicações e serviços sofisticados. Mas os componentes de software de terceiros e a conveniência dos pacotes e contentores trazem riscos juntamente com os benefícios, porque as aplicações construídas são apenas tão seguras como essas dependências.

Os ataques à cadeia de fornecimento de software estão a tornar-se tão generalizados que a Gartner os listou como a segunda maior ameaça para 2022. Até 2025, a empresa de investigação prevê que 45% das organizações a nível mundial terão sofrido um ou mais ataques à cadeia de fornecimento de software – e 82% dos CIO pensam que serão vulneráveis a eles. Estes incluem ataques através de vulnerabilidades em componentes de software amplamente utilizados, tais como Log4j, ataques contra o gasoduto de construção (c.f., SolarWinds, Kaseya, e hacks do Codecov), ou hackers que comprometem os próprios repositórios de pacotes.

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

Os recentes incidentes de grande visibilidade têm sido 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 assunto tão importante”.

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

No entanto, é pouco provável que estas questões prejudiquem a popularidade do código aberto – e o software e serviços comerciais também são vulneráveis. Quando a LastPass foi atacada, não perdeu dados de clientes, mas uma parte não autorizada pôde ver e descarregar algum do seu código fonte, o que pode tornar mais fácil atacar utilizadores do gestor de senhas no futuro, e a violação do Twilio permitiu aos atacantes lançar ataques da cadeia de fornecimento a organizações a jusante.

A ameaça do código sombra

Tal como as equipas de segurança defendem as suas redes como se já tivessem sido violadas, os CIO devem assumir todo o código, interno ou externo, e mesmo os ambientes e ferramentas de desenvolvimento que os seus programadores utilizam já foram comprometidos e pôr em prática políticas de proteção contra e minimizar o impacto dos ataques contra as suas cadeias de fornecimento de software.

De facto, a Osnat sugere aos CIO que pensem sobre este “código sombra” da mesma forma que pensam sobre a TI sombra. “Isto precisa de ser visto como algo que não é apenas um problema de segurança, mas realmente algo que vai fundo na forma como se obtém software, seja ele de código aberto ou comercial: como o traz para o seu ambiente, como o atualiza, que tipo de controlos quer ter em vigor e que tipo de controlos quer exigir dos seus fornecedores”, diz ele.

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

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

A ordem executiva 14028 da Casa Branca sobre segurança da cadeia de fornecimento de software exige que os fornecedores de software que abastecem o governo federal forneçam uma lista de materiais de software (SBOM) e utilizem os níveis da cadeia de fornecimento de artefactos de software (SLSA) para evitar adulterações. Por causa disto, “estamos a ver muitas empresas a olhar muito mais seriamente para a sua cadeia de fornecimento de software”, diz a analista sénior da Forrester Janet Worthington. “Todas as empresas hoje produzem e consomem software e estamos a ver mais produtores a virem ter connosco e dizerem: ‘Como produzo software que é seguro e que posso atestar com uma lista de materiais de software'”.

Existem numerosos projetos intersectoriais, incluindo a Iniciativa Nacional do NIST para Melhorar a Segurança Cibernética nas Cadeias de Fornecimento (NIICS), a iniciativa Supply Chain Integrity, Transparency, and Trust (SCITT) da Microsoft e outros membros da IETF, bem como o OpenSSF Supply Chain Integrity Working Group.

“Toda a gente está a adotar uma abordagem mais holística e a dizer, espera um minuto, preciso de saber o que estou a trazer para a minha cadeia de fornecimento com que estou a criar o software”, diz Worthington.

Um recente inquérito da Linux Foundation revelou que a sensibilização para o SBOM é elevada, com 47% dos fornecedores de TI, fornecedores de serviços, e indústrias regulamentadas que utilizam atualmente SBOM e 88% que esperam utilizá-los em 2023.

Os SBOM serão mais úteis para organizações que já possuem gestão de ativos para componentes de software e API. “As pessoas que têm hoje em dia processos robustos de desenvolvimento de software acham mais fácil encaixar ferramentas que possam gerar uma lista de materiais de software”, diz Worthington.

As SBOM podem ser criadas pelo sistema de construção, ou podem ser geradas por ferramentas de análise da composição do software após o facto. Muitas ferramentas podem integrar-se em condutas CI/CD e funcionar como parte de uma construção, ou mesmo quando se retiram bibliotecas, diz ela. “Pode alertá-lo: ‘Ei, tem este componente no seu pipeline e tem um problema crítico, quer continuar?'”

Para que isso seja útil, precisa de políticas claras sobre como as equipas de desenvolvimento adquirem software de código aberto, diz Chainguard CEO Dan Lorenc. “Como é que os programadores sabem quais são as políticas da sua empresa para o que é considerado ‘seguro’ e como é que sabem que o software de código aberto que estão a adquirir, que constitui a grande maioria de todo o software que está a ser utilizado pelos programadores nos dias de hoje, não é de facto adulterado”?

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

“Penso que um CIO deveria começar por doutrinar as suas equipas de desenvolvimento nestes passos fundamentais de utilização de abordagens padrão emergentes da indústria para um, bloqueando sistemas de construção, e dois, criando um método repetível para verificar a fiabilidade dos artefactos de software antes de os trazer para o ambiente”, diz Lorenc.

Fazer a contribuição

Quer sejam componentes, API, ou funções sem servidor, a maioria das organizações subestima o que estão a utilizar por uma ordem de grandeza, a menos que executem inventários de rotina, a Worthington assinala. “Descobrem que algumas destas API não estão a utilizar métodos de autenticação adequados ou talvez não estejam escritas de uma forma que esperavam e talvez algumas delas sejam mesmo depreciadas”, diz ela.

Para além das vulnerabilidades, avaliar o apoio da comunidade por detrás de um pacote é tão importante como compreender o que o código faz porque nem todos os mantenedores querem o fardo de ter o seu código tratado como um recurso crítico. “Nem todo o código aberto se torna o mesmo”, adverte ela.

“O código aberto pode ser gratuito para descarregar, mas certamente a sua utilização não é gratuita. A sua utilização significa que é responsável por compreender a postura de segurança por detrás dele, porque está na sua cadeia de fornecimento. Tem de contribuir de novo para ela. Os seus criadores precisam de participar na correção de vulnerabilidades”, diz Worthington, que sugere que as organizações também devem estar preparadas para contribuir monetariamente, quer diretamente para projetos de fonte aberta, quer para iniciativas que os apoiem com recursos e fundos. “Quando se cria uma estratégia de fonte aberta, parte disso é compreender o orçamento e as implicações”.

Não pense nisso apenas como uma despesa, mas como uma oportunidade para compreender melhor os componentes de que depende. “Até ajuda a reter os programadores porque se sentem como se fizessem parte da comunidade. Eles estão a ser capazes de contribuir com as suas capacidades. Eles podem usar isto no seu currículo”, acrescenta ela.

Lembre-se que as vulnerabilidades podem ser encontradas em qualquer parte da sua pilha de tecnologia, incluindo mainframes, que cada vez mais correm Linux e open source como parte da carga de trabalho, mas muitas vezes carecem dos processos e estruturas de segurança que se tornaram comuns em outros ambientes.

Protegendo o seu pipeline

A proteção do seu canal de entrega de software é também importante. O NIST Secure Software Development Framework (SSDF) e SLSA é um bom local para começar: Isto abrange as melhores práticas a vários níveis de maturidade, começando com um sistema de construção simples, depois utilizando registos e metadados para auditoria e resposta a incidentes, até uma conduta de construção totalmente segura. O Livro Branco de Melhores Práticas de Cadeia de Fornecimento de Software da CNCF, as orientações da Gartner sobre a mitigação dos riscos de segurança da cadeia de fornecimento de software, e o OSS Secure Supply Chain Framework da Microsoft, que inclui tanto processos como ferramentas, também são úteis.

É importante notar, no entanto, que simplesmente ligar ferramentas de digitalização automatizada destinadas a encontrar código malicioso pode produzir demasiados falsos positivos para ser útil. E embora os sistemas de controlo de versões tais como BitBucket, GitHub, GitLab, e outros incluam características de segurança e proteção de acesso (incluindo controlos de política de acesso cada vez mais granulares, proteção de filiais, assinatura de código, exigindo AMF para todos os contribuidores, e digitalização de segredos e credenciais), muitas vezes têm de ser explicitamente ativados.

Além disso, projetos como o Factory for Repeatable Secure Creation of Artifacts (FRSCA), que visam garantir a construção de condutas através da implementação do SLSA numa única pilha, ainda não estão prontos para produção, mas os CIO devem esperar que os sistemas de construção incluam mais destas práticas no futuro.

De facto, embora os SBOM sejam apenas parte da resposta, as ferramentas para criar e trabalhar com eles ainda estão a amadurecer, assim como os processos para os solicitar e consumir. Os contratos precisam de especificar não só que pretende SBOM, mas também com que frequência espera que sejam atualizadas e se incluirão relatórios de vulnerabilidade e notificações, aconselha a Worthington. “Se for encontrada uma nova vulnerabilidade importante como Log4j, será que o vendedor me vai dizer ou terei de me procurar no SBOM para ver se sou afetado?”.

As organizações também precisarão de ferramentas para ler as SBOM e pôr em prática processos para tomar medidas sobre o que estas ferramentas encontram. “Preciso de uma ferramenta que me possa 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 CIO devem ter em mente que um SBOM “é um capacitador, mas na realidade não resolve nada em termos de segurança da sua cadeia de abastecimento”. Ajuda-o a lidar com incidentes que possam surgir”, diz Osnat, que está otimista tanto com a rapidez de resposta da indústria como com a ampla colaboração que está a decorrer em torno de normas para SBOMs e atestados de código que ajudarão a tornar as ferramentas interoperáveis (algo que as organizações levantaram como uma preocupação particular na investigação da Linux Foundation). Isso poderia levar às mesmas melhorias nas normas de transparência e de elaboração de relatórios em toda a indústria que o SOC 2 forneceu.

Dito isto, os CIO não têm de esperar por novas normas ou ferramentas para começar a tornar a segurança tão parte do papel do desenvolvedor como a qualidade se tornou nos últimos anos, diz Osnat. A sua sugestão: “Comece por reunir o seu CISO e o seu engenheiro-chefe numa sala para descobrir qual é o modelo certo para fazer com que isso funcione para a sua organização e como essa transformação irá ocorrer”.