Como proteger sua cadeia de suprimentos de código aberto

Views: 296
0 0
Read Time:3 Minute, 36 Second

O código aberto nunca foi tão popular, o que significa que é hora de descobrir como proteger efetivamente o código aberto que você usa.

O mundo é feito de software, e mais de 99% de qualquer software que você usa – código aberto ou proprietário – inclui componentes de código aberto. Alguns desses componentes vêm com um vendedor atrás deles, disposto a indenizar você no caso de algo dar errado. Para outros componentes, você pode ser capaz de obter uma assinatura através de uma empresa como a Tidelift para garantir uma manutenção constante.

Mas então algo como o inseto Heartbleed abre um buraco no OpenSSL, e você fica se perguntando: “Como eu poderia ter evitado isso?” A resposta curta, mas esperançosa é: você não pode. Nem por isso. Não completamente. Como o co-fundador da Chef and System Initiative, Adam Jacob, enfatizou em uma recente entrevista ao Open Source in Business,a verdadeira questão é “quão rapidamente você pode reagir à interrupção em sua cadeia de suprimentos?” não como antecipar tais interrupções.

Segurança de código aberto: É sempre sobre processo

O código aberto historicamente tem entregue menos defeitos – ou “bugs” – do que o software proprietário. Isso faz sentido intuitivo: Desenvolvedores que estarão mostrando seu código são mais propensos a investir o tempo necessário para prepará-lo para o consumo público. Para pegar menos atalhos. Para polir.

No entanto, o verdadeiro segredo para a segurança de código aberto não é o código livre de erros, o que é impossível. Não, a segurança de código aberto vem através da divulgação. Porque qualquer um pode ver o código, todos também podem ver qualquer problema. Ou, mesmo que não seja detectado antes de uma vulnerabilidade ser violada, a natureza aberta do código torna mais fácil corrigir o problema. Não é de admirar, então, que a empresa de pesquisa WhiteSource descobriu que 85% das vulnerabilidades de código aberto são divulgadas e têm uma correção já disponível quando divulgada.

Então, ao determinar quais componentes de código aberto usar, disse Jacob, concentre-se no processo de correção de problemas que inevitavelmente surgem com sua “cadeia de suprimentos”:

A questão é, quão rápido você pode reagir à interrupção em sua cadeia de suprimentos? Porque é disso que se trata gerenciar cadeias de suprimentos. Sim, há uma parte proativa que [inclui] a verificação se deve assumir uma dependência ou não. Mas quando algo dá errado na cadeia de suprimentos, torna-se uma questão de “Quão rápido podemos virar a correção? Quão rápido podemos reparar o que está quebrado e levá-lo para o mundo? E é aí que você precisa se concentrar. Não é que você não se concentre na prevenção. Claro que sim. Mas você não pode impedi-lo porque a cadeia de suprimentos é tão grande e você não é. E essa é a natureza do universo.

Preste atenção às contribuições a montante para projetos de código aberto

Se você é um fornecedor vendendo serviços ou suporte em torno desses componentes de código aberto, Jacob continuou, em última análise, o que você está prometendo é “que eu sou o único que vai reagir a isso e eu vou reagir mais rápido do que você [o cliente] para obter uma correção em suas mãos.”

É por isso que (na mesma entrevista) Scott McCarty, gerente de produtos da Red Hat, ressaltou a importância das contribuições upstream para projetos de código aberto. (Uma “contribuição upstream” significa simplesmente as contribuições de volta para a fonte principal do código.) Contribuições a montante não são algo para se gabar, disse McCarty. Não, eles são apenas uma maneira de “expressar ao cliente que você tem envolvimento suficiente na cadeia de suprimentos” para poder cuidar deles quando os problemas invariavelmente surgem.

Isso não é “apoio”, por si só, embora às vezes possa se sentir assim. Em vez disso, o produto é a capacidade de influenciar um projeto de código aberto de forma a obter correções entregues rapidamente, o que é mais fácil se o fornecedor tiver colaboradores upstream. Tais contribuições são inerentemente auto-interessadas, apontou McCarty, mas não de alguma forma “ruim”. Não, é esse interesse próprio que motiva mais contribuições, o que ajuda o fornecedor a cuidar melhor dos clientes, que pagam o favor com a receita, o que gera mais contribuições. É um ciclo virtuoso de segurança de código aberto.

FONTE: TECHREPUBLIC

POSTS RELACIONADOS