Como rastrear e proteger o código aberto em sua empresa

Da Redação, com CIO/EUA 

Publicada em 26 de abril de 2017 

Usar open source responsavelmente significa saber o que você está usando para que você possa rastrear e manter.

A maioria das empresas desconhece quantas fontes de código aberta seus desenvolvedores usam e quais vulnerabilidades podem expô-los. Você não pode fazer avaliações de segurança ou gerenciar patches em projetos de código aberto sem saber a origem dos componentes usados.

Estudo recente da Sonatype descobriu que componentes de terceiros compreendem 89% do código em um aplicativo Java típico - e um em dezesseis desses componentes tem uma vulnerabilidade de segurança. Componentes mais antigos têm três vezes mais falhas de segurança que as versões mais recentes e mais de metade dos componentes usados ​​em aplicativos corporativos têm mais de dois anos. Dois anos depois que o erro Heartbleed foi encontrado, mais da metade das versões do OpenSSL testadas pela Cisco Security Research em 2015 ainda estavam vulneráveis.

Em 2014, a Veracode descobriu que os componentes de código aberto e de terceiros usados ​​em aplicativos corporativos da Web introduziram uma média de 24 vulnerabilidades conhecidas em cada uma das 5 mil aplicações analisadas.

"As empresas raramente sabem quanta fonte aberta estão usando ", disse Rami Sass, CEO e co-fundador do serviço de monitoramento e gerenciamento de código aberto WhiteSource. "Bancos, empresas de serviços financeiros e empresas de mídia têm grandes departamentos de engenharia de software. E muitas vezes ficam surpresas ao descobrirem quão extenso é o uso de código aberto e o quão pouco de seus processos de inventário manuais têm acompanhado esse uso. Em média, eles encontram três vezes o número de componentes que eles achavam que tinham. Às vezes é tão alto quanto 10 vezes."

Isso não quer dizer que você não deva querer que seus desenvolvedores aproveitem código aberto, especialmente se está se movendo em direção a DevOps. "Usar o código aberto nos negócios faz sentido, porque você quer que seus desenvolvedores permaneçam focados em seu core business", diz Sass. "Muito do que você precisa já foi inventado; você quer reutilizar algo que já foi testado e que é mantido pela comunidade, para que você não tenha que fazer todo o trabalho pesado. É por isso que todo mundo gosta de código aberto - mas infelizmente, o código aberto tem seus próprios problemas. "

Passivos de licença de código aberto

No passado, as empresas estavam mais preocupadas com o lado de licenciamento de código aberto. "O código-fonte aberto é gratuito, mas ele vem com um monte de strings anexadas", lembra Sass. O licenciamento de código aberto pode ser um campo minado para organizações comerciais. Embora um número crescente de projetos usem licenças permissivas como as licenças MIT e Apache, que têm requisitos mínimos sobre como o código pode ser redistribuído, outras licenças têm requisitos mais onerosos. Orientação recente do Google sobre como ele usa código aberto inclui notas sobre qual licenças, como AGPL, são proibidos internamente por causa das exigências de publicar o código de obras derivadas.

Mesmo projetos de software que afirmam ser de domínio público ou "livre para qualquer uso" precisam ser cuidadosamente considerados, pois é uma questão não trivial colocar o software em domínio público. Se você é um negócio comercial, você precisa evitar software que é gratuito para uso não comercial, que inclui várias licenças Creative Commons.

Isso não significa que você deva evitar o código aberto, mas você precisa entender as ramificações das licenças que você está aceitando usando um projeto de código aberto. A natureza interconectada de projetos de código aberto pode tornar isso mais complicado, pois muitas pessoas que usam o gerenciador de pacotes nem descobriram, após disputas sobre nomes de pacotes, que o desenvolvedor não publicou uma série de pacotes que dependiam de milhares de outros projetos.

"Um componente de código aberto pode ter dependências em muitos outros componentes de código aberto. Sempre que um desenvolvedor assume um componente de código aberto, ele está trazendo toda a árvore de dependências por trás dele e muitas vezes não se tem visibilidade disso. Você precisa ver qual é o seu inventário de componentes de código aberto, mas a maioria das organizações não faz isso ", diz Sass.

Pegue as chamadas licenças "copyleft", como a GPL, que geralmente exigem que você publique as modificações feita no código. "A empresa média estará usando alguns componentes de código aberto com uma licença GPL", diz Sass. "De 300 componentes, talvez um, dois ou três [será GPL]. Isso quase sempre é novidade para eles. "

Além de saber que código aberto você está usando, você precisa rastrear os projetos de código aberto aos quais seus desenvolvedores podem estar contribuindo. Uma maneira de fazer isso é com o GitHub Business. Embora a maioria das organizações considere o GitHub Business um serviço em nuvem que economiza o problema de executar o GitHub Enterprise em seus próprios servidores, ele também dá controle sobre como os desenvolvedores da sua organização consomem e contribuem para os repositórios do GitHub.

O GitHub Business integra-se às ferramentas de gerenciamento de identidade existentes, seja Azure Active Directory, Okta ou outros sistemas de identidade compatíveis com SAML e SCIM, como o OneLogin e o Shibboleth. Isso significa que se os seus desenvolvedores baixarem código aberto, contribuírem de volta para o projeto ou usá-lo para um projeto interno, eles estarão fazendo isso a partir de contas oficiais da empresa que você continuará a controlar, não de seus logins pessoais GitHub . 

Segurança de código aberto

A outra questão-chave com o uso de open source é ter certeza de atualizá-lo quando forem encontrados problemas de segurança. "Quando um desenvolvedor toma um componente vulnerável de código aberto e o incorpora em seu software, você é vulnerável e torna seus clientes vulneráveis", diz Sass.

A verdadeira questão, no entanto, não é se existem vulnerabilidades, porque sempre existirão, mas que elas não sejam corrigidas. "Você sempre encontrará bibliotecas desatualizadas, você sempre encontrará componentes vulneráveis, você quase sempre encontrará licenças que uma empresa não pretende usar."

"A coisa boa sobre open source é que os problemas são bastante fáceis de corrigir uma vez que você saiba sobre eles. Normalmente, não é preciso um esforço enorme para sair e atualizar os componentes, embora às vezes haja problemas de compatibilidade. A comunidade de código aberto já passou pelo esforço de resolver o problema. "

Aplicar essas correções sistematicamente significa rastrear e gerenciar o código aberto que você usa como qualquer outra parte de sua cadeia de suprimentos, e fazer isso manualmente é ineficiente. Ferramentas de análise de composição de software como WhiteSource, Black Duck, Palamida (recentemente adquirida pela Flexera), Sonatype Nexus, Synopsys ou Veracode ajudam a automatizar isso.

O WhiteSource, por exemplo, tem plug-ins para ferramentas e serviços de gerenciamento de fontes populares, como o Visual Studio Team Services e o Jenkins, e está sendo construído no Visual Studio 2017 para que ele colete automaticamente detalhes dos componentes de código aberto que seus desenvolvedores estejam usando e produz relatórios mostrando quais vulnerabilidades de segurança foram encontradas e o que você precisa fazer para mitigar os problemas. Você também pode obter relatórios sobre quais licenças esses componentes usam e até mesmo definir políticas para agir com base em problemas de licenciamento ou vulnerabilidades de segurança.

"Você pode ter uma lista negra e uma lista branca de licenças. Os clientes costumam ter uma lista negra para licenças como a GPL e uma lista branca para licenças permissivas como o MIT ", diz Sass. "Você também pode ter uma política em torno de vulnerabilidades de segurança. Se um desenvolvedor apresentar uma nova biblioteca de código aberto com uma vulnerabilidade conhecida, podemos bloqueá-la. Também podemos enviar proativamente uma notificação push sobre uma vulnerabilidade recém-descoberta em uma biblioteca que você está usando. "

CIOs não podem dar ao luxo de fechar os olhos para a quantidade de componentes de código aberto que os desenvolvedores estão usando. Em vez disso, você precisa iniciar o acompanhamento e gerenciá-lo para certificar-se de que você está no controle das questões de licenciamento e segurança. "Os benefícios compensam consideravelmente as falhas", diz Sass. "Você só precisa gerenciar isso, então você é capaz de usar o código aberto, ter aumento produtividade e não se preocupar com isso."

- See more at: http://cio.com.br/tecnologia/2017/04/26/como-rastrear-e-proteger-o-codigo-aberto-em-sua-empresa/#sthash.kU4Rrw7E.dpuf