Como rastrear e manter seguro o código aberto na sua empresa

Os CIO têm de estar cientes de que os programadores estão a utilizar componentes de código aberto. Para fazer face a esta realidade é preciso liderar e criar políticas.

O SAS disse recentemente que as empresas devem limitar o número de projectos desenvolvidos em código aberto a uma percentagem reduzida relativamente arbitrária. O aviso foi mal recebido pelo mercado pois aparenta ser uma tentativa óbvia de protestar face ao crescimento da linguagem de programação de código aberto “R” para ciência e análise de dados, um mercado em que o SAS tem sido dominante. Mas há algo que importa atentar, explica a jornalista Mary Branscombe, da CIO.com: utilizar código aberto de forma responsável significa que tem de se saber o que de facto existe para o rastrear e manter.

A maioria das empresas não está consciente da quantidade de código aberto utilizada pelos programadores e das vulnerabilidades inerentes a estas práticas. Não é possível fazer avaliações de segurança ou gestão de “patches” em projectos de código aberto que não sabe sequer que existem.

Um estudo de 2016 da Sonatype sobre a cadeia de valor do software, revela que os componentes de terceiros representam 80 a 90% do código numa típica aplicação empresarial em Java. Revela ainda que um em cada 16 componentes descarregados nas empresas têm vulnerabilidades de segurança. Os pedaços de código mais antigos são três vezes mais vulneráveis que versões mais recentes e mais de metade dos componentes utilizados em aplicações empresariais têm mais de dois anos.

Em 2014, a Veracode revelou que o código aberto e outros componentes de terceiros utilizados nas aplicações web empresariais incluíam uma média de 24 vulnerabilidades conhecidas em cada uma das 5000 aplicações analisadas.

“Até as empresas que já sabem que estão a utilizar código-fonte aberto podem precisar de ferramentas para os gerir melhor. As empresas raramente têm noção da quantidade de código que estão realmente a utilizar” – Rami Sass (WhiteSource)

“Até as empresas que já sabem que estão a utilizar código-fonte aberto podem precisar de ferramentas para os gerir melhor. As empresas raramente têm noção da quantidade de código que estão realmente a utilizar”, explica Rami Sass, CEO e co-fundador do serviço de gestão e monitorização de código aberto WhiteSource, à CIO.com.

“Organizações como bancos, serviços financeiros ou empresas de media têm actualmente grandes departamentos de engenharia de software. Muitas vezes são surpreendidos pela extensão da utilização de código aberto e também pela reduzida percentagem que é de facto acompanhada pelos processos de inventário manual. Em média, encontram três vezes mais componentes do que previam e algumas vezes é 10 vezes maior”.

Isto não significa que não se queira que os programadores tirem partido do código aberto, especialmente se estão a migrar para DevOps. “Utilizar código aberto nas empresas faz sentido, porque desse modo os programadores focam-se no negócio essencial da empresa”, diz Sass. “Muito do que é necessário já foi inventado. Se pretende reutilizar algo que já foi testado e que é mantido pela comunidade não há necessidade de começar do zero. É por isso que toda a gente adora código aberto. Mas, infelizmente, este código também tem os seus problemas”.

Licenças de código aberto

No passado, as empresas estavam muitas vezes preocupadas com as questões de licenciamento do open source. “O código aberto é grátis, mas tem algumas condicionantes”, explica Sass. O licenciamento de open source pode ser um campo minado para as organizações comerciais. Embora cada vez mais projectos utilizem licenças permissivas (por exemplo MIT ou Apache), que incluem requisitos mínimos sobre a forma como o código pode ser redistribuído, outras são mais complexas. As recentes orientações da Google sobre como utilizar software aberto referem que distribuições – como por exemplo a Affero General Public License (AGPL) – estão internamente proibidas devido à obrigatoriedade de publicação do código criado a partir daqueles componentes.

Mesmo quando os projectos de software que assumem ser de domínio público ou “livre para qualquer utilização” devem ser considerados cautelosamente, porque não é uma questão trivial disponibilizar software em domínio público – Rami Sass (WhiteSource)

Mesmo quando os projectos de software que assumem ser de domínio público ou “livre para qualquer utilização” devem ser considerados cautelosamente, porque não é uma questão trivial disponibilizar software em domínio público. Se tem uma empresa, deve evitar software gratuito para uso não comercial, incluindo licenças Creative Commons.

Tal não significa que se deva evitar o código aberto. É, no entanto, necessário compreender as ramificações do licenciamento que se está a aceitar ao utilizar um projecto de open source. A natureza interconectada dos projectos de código aberto podem criar dificuldades. Essa situação foi constatada pelos utilizadores do pacote de gestão “npm” quando, após uma disputa sobre nomes de pacotes, o programador “eliminou” vários pacotes dos quais estavam dependentes centenas de outros projectos”.

“Determinado componente de código aberto pode estar dependente de muitos outros. Sempre que um programador utiliza um componente de open source, este traz consigo uma árvore de dependências e, muitas vezes, não existe visibilidade. É necessário verificar o repositório de componentes de código aberto, mas a maioria das organizações não está atenta a essa questão”, explica Sass.

O especialista exemplifica com as chamadas licenças “copyleft”, como as licenças GPL, que, geralmente, obrigam à publicação de qualquer modificação feita sobre esse código. “Uma empresa comum utilizará provavelmente componentes com licenças GPL”, diz Sass. “Entre os 300 componentes, talvez tenham um, dois ou três [com GPL]. E normalmente não estão cientes disso”.

Tão importante como saber que código aberto está a ser utilizado é a capacidade de rastrear os projectos para os quais os programadores da sua empresa poderão estar a contribuir com código – Connor Sears (GitHub)

Tão importante como saber que código aberto está a ser utilizado é a capacidade de rastrear os projectos para os quais os programadores da sua empresa poderão estar a contribuir com código. Uma das maneiras de o fazer é com o “GitHub Business”. Não obstante a maioria das organizações considerar que o “GitHub Business” é um serviço cloud que lhes poupa o trabalho de correr o GitHub Enterprise nos seus próprios servidores, aquele acaba por dar acesso ao controlo das identidades sob as quais os programadores de uma organização consomem e contribuem para repositório GitHub.

“Os nossos clientes querem uma conexão directa aos programadores e aos projectos, a comunidade que compõe o GitHub. Muito desse código open source é valioso para os nossos clientes. Eles tiram partido dele e querem contribuir para eles. Querem acesso ao vasto conjunto de ferramentas da plataforma que resultam dos contributos dos parceiros”, assinala Connor Sears, director sénior de design de produto da GitHub à CIO.com.

O GitHub Business integra-se com outas ferramentas de gestão de identidades existentes (Azure Active Directory, Okta ou outra SAML e sistemas de identidade compatíveis com SCIM, como é o caso da OneLogin e da Shibboleth). Isto significa que se os programadores de uma empresa descarregarem código open source e contribuírem de volta para o projecto, o estarão a fazer a partir das contas oficiais das empresas, que a empresa irá continuar a controlar, mesmo que eles se vão embora, e não a partir dos seus logins pessoais GitGHub.

Segurança do open source

Outra questão fundamental quando se utiliza código aberto é assegurar-se que são actualizados quando são encontrados problemas de segurança. “Quando um programador pega num componente de código aberto vulnerável e o incorpora no seu software, a sua empresa estará vulnerável e os seus clientes também ficarão”, assinala Sass.

A grande questão, no entanto, não é a existência de vulnerabilidades – porque haverá sempre vulnerabilidades -, mas que se mantenham por resolver. “Haverá sempre bibliotecas desactualizadas, irá sempre encontrar componentes vulneráveis e irá encontrar quase sempre licenças que a empresa não tinha intenções de utilizar”, destaca.

“O que é bom no open source é que os problemas são resolvidos facilmente a partir do momento em que são descobertos. Normalmente, alguém na comunidade open source já encontrou solução para resolver o problema” – Rami Sass (WhiteSource).

“O que é bom no open source é que os problemas são resolvidos facilmente a partir do momento em que são descobertos. Normalmente a actualização de um componente não requer muito esforço, embora existam por vezes questões de compatibilidade. Normalmente, alguém na comunidade open source já encontrou solução para resolver o problema”.

Aplicar essas correcções automaticamente significa acompanhar e gerir o open source que é utilizado como qualquer outra parte da cadeia de valor e fazê-lo manualmente é ineficiente. Ferramentas de análise de composição do software como a WhiteSource, a Black Duck, a Palamida (recentemente adquirida pela Flexera), a Sonatype Nexus, a Synopsys ou a Veracode ajudam a automatizar esta questão.

A WhiteSource, por exemplo, tem plugins para as ferramentas de gestão de código mais populares (Visual Studio Team Services, Jenkins, e está a ser integrada no Visual Studio 2017), para que os CIO possam recolher automaticamente detalhes sobre componentes de open source utilizados pelos seus programadores, produzindo relatórios com as vulnerabilidades de segurança encontradas e com informação sobre o que é necessário fazer para mitigar essas falhas. Também se podem obter relatórios sobre as licenças que esses componentes utilizam e até criar políticas para agir de acordo com as questões de licenciamento ou vulnerabilidades de segurança.

“Pode existir uma lista negra e uma lista branca de clientes. Os clientes habitualmente têm uma lista negra de licenças como as GPL e uma lista branca de licenças permissivas como a MIT”- Rami Sass (WhiteSource)

“Pode existir uma lista negra e uma lista branca de clientes. Os clientes habitualmente têm uma lista negra de licenças como as GPL e uma lista branca de licenças permissivas como a MIT”, explica Sass. “Também poderá ter uma política em torno das vulnerabilidades de segurança. Se um programador introduzir uma nova biblioteca de código aberto com uma vulnerabilidade já conhecida, esta pode ser bloqueada. Podemos enviar proactivamente uma notificação “push” sobre a recentemente descoberta vulnerabilidade numa biblioteca que estamos a utilizar, não é necessário aguardar pela geração de um relatório”, acrescenta.

Essa política pode integrar-se directamente com o fluxo de trabalho do programador através do servidor local ou da integração com sistemas como o Git, o GitHub, o JIRA e o Artefactory.

“Se estiver a fazer uma integração contínua e um programador introduzir uma nova biblioteca que utilize uma licença do tipo GPL ou que tenha uma vulnerabilidade de segurança de grande impacto, a política entra em acção; a construção é impedida e o programador será notificado sobre a biblioteca que tem problemas. Quando alguém tentar adicionar um novo elemento num repositório, pode verificar-se a política e depois bloqueá-lo. Se se adicionar uma biblioteca que tem uma vulnerabilidade de segurança média ou baixa, a notificação pode ser reencaminhada pelo responsável de segurança de informação, para que possa haver mais do que uma pessoa envolvida no processo de tomada de decisão”.

Esta mudança de governação deve ser implementada tão cedo quanto possível no processo de desenvolvimento e na automatização de parte do trabalho envolvido na conformidade. Depois de identificar o problema é possível bloquear um componente impedindo-o de entrar nos sistemas.

A WhiteSoure tem também um plugin para navegadores criado para ajudar os programadores a fazer as melhores escolhas entre os componentes de open source disponíveis. Quando os programadores visitam páginas web que mencionem componentes de open source, o plugin cruza-os com a base de dados da WhiteSource e apresenta um “popup” com os detalhes de licenciamento, qualquer vulnerabilidade ou política de empresa. “Testamo-los face às políticas da organização e dizemos ao programador se esse componente vai ser aprovado. Também listamos as localizações em que o componente já está a ser utilizado na organização e pode verificar-se se existe outra equipa a utilizar a mesma versão ou outra versão do componente que o programador está a analisar”, explica Sass.

Se a empresa tem de estar em conformidade com padrões financeiros, será necessário ter políticas de governação para a utilização de código aberto ou componentes de terceiros. Ainda não existem standards de políticas para lidar com o open source que tenham sido amplamente adoptadas por empresas noutras indústrias, mas Sass acredita que se irá atingir esse patamar, especialmente numa altura em que a administração norte-americana começou a criar esse tipo de políticas internamente. “O Governo [norte-americano] está a entrar no campo do código aberto. Agora são obrigados a disponibilizar uma percentagem do código que escrevem como código aberto e vão querer regular estas obrigações com algum tipo de política. A partir do momento em que tal aconteça, as grandes organizações irão seguir o exemplo”, sugere.

Os CIO não se podem dar ao luxo de ignorar a quantidade de componentes de open source que os programadores nas empresas estão a utilizar. Devem, no entanto, começar a acompanhar e a gerir esses componentes para assegurar que não estão a trabalhar rodeados de questões de licenciamento e de segurança.

“As vantagens sobrepõem-se consideravelmente às lacunas”, diz Sass. “Só é necessário gerir a situação de modo a que seja possível utilizar código aberto, contribuindo para o aumento da produtividade, sem preocupações adicionais”.

Autores

Artigos relacionados

O seu comentário...

*

Top