Código aberto, um assassino silencioso?

Pat Martlew, IDG Connect em 25/03/2019 no site CIO

Foto: Shutterstock

O software de código aberto é bastante difícil de evitar na TI corporativa hoje. As promessas do modelo open source são simplesmente boas demais para serem ignoradas, permitindo que as organizações armarem seus desenvolvedores com código olhado por milhares de olhos, todos se esforçando para melhorá-lo ou adaptá-lo a casos de uso específicos que qualquer um pode aproveitar. É uma grande promessa que leva a grandes recompensas, e a implementação reduzirá tão cedo .

Por outro lado, os ativos de software de código aberto de uma empresa podem apresentar um campo minado, pois pode ser difícil determinar exatamente de onde os componentes vêm originalmente, e quem já trabalhou neles. Isso representa um desafio também para as vulnerabilidades de segurança (ou seja, existem pontos fracos conhecidos em determinados códigos OSS?) e para questões de Propriedade Intelectual, pois pode ser difícil determinar em quais licenças  open source código se encaixa.

Algumas licenças exigem que qualquer modificação significativa ou utilização do software, de acordo com os princípios open source, também seja disponibilizada publicamente. Isso pode até mesmo se estender aos componentes do software de código aberto usados ​​como pequenos blocos de construção de um aplicativo "proprietário" mais amplo. O que isso significa é que, mesmo que as empresas usem um pequeno código em seus aplicativos internos, elas podem estar sujeitas à obrigação de liberar o código-fonte ou enfrentar uma ação legal por não conformidade.

É por essas questões que o mercado de ferramentas de análise de composição de software (SCA) está ganhando impulso. As ferramentas SCA visam fornecer uma visão de 'diagnóstico' de todos os componentes do software de código aberto existentes dentro de uma empresa e determinam se há ou não uma vulnerabilidade ou um requisito de licenciamento específico a ser considerado. A CAST é um desses fornecedores e acaba de anunciar uma nova aliança com o Software Heritage, com o objetivo de levar a SCA um passo adiante.

Basicamente, a CAST está trabalhando com a Software Heritage, que supervisiona o maior arquivo aberto de código fonte do software, para desenvolver um "índice de proveniência" que permitirá aos usuários vasculhar o arquivo da Heritage Heritage usando o software Highlight SCA da CAST para identificar a ocorrência original de qualquer arquivo fonte, e todas as suas ocorrências subsequentes. O CAST diz que isso permitirá que os usuários avaliem qualquer código-fonte de terceiros dentro da biblioteca do Software Heritage de mais de cinco bilhões de arquivos de código-fonte conhecidos, eliminação e vulnerabilidades e riscos de licenciamento que eles apresentam.

Conversamos com Vincent Delaroche, CEO da CAST, para descobrir um pouco mais sobre o projeto e o que ele poderia oferecer aos usuários.

IDG Connect - Em relação à parceria de indexação de procedência com o Software Heritage, por que a CAST decidiu trabalhar nisso e quais foram os objetivos do projeto?

Vincent Delaroche - A CAST entrou no mercado de SCA (análise de composição de software) em 2018, e percebemos que havia uma grande necessidade de uma solução para verificar e controlar adequadamente a exposição ao risco de Propriedade Intelectual. Mas, para fazê-lo de forma eficaz, é necessário detectar com segurança o componente original que possui a licença inicial, pois é ele quem dirige todos os "descendentes". Isso deve ser feito automaticamente para permitir um processo repetível e sistemático que possa ser replicado em cada projeto (ou seja, não manual).

Como o Software Heritage é o maior banco de dados disponível e eles estão comprometidos com o crescimento do arquivamento, fez muito sentido que fôssemos parceiros deles. Estamos alinhados com a missão do Software Heritage e também sabemos que identificar e arquivar todo o software de código aberto no mundo não pode ser feito por uma única empresa ... é um projeto comunitário, onde todos devem contribuir.

Como o projeto funcionará?

O repositório do Software Heritage já está acessível por meio de uma API aberta. Com o CAST Highlight, os usuários podem automatizar e dimensionar suas pesquisas para extrair uma lista completa de componentes que aparecem em seu código-fonte. Por meio de nosso contrato com o Software Heritage, o CAST também identificará o "ancestral" original desse componente.

Quais riscos de segurança são apresentados a uma organização por código-fonte aberto não identificado?

Quando o código aberto não é gerenciado adequadamente, as organizações podem ser invadidas ou processadas. No caso de um hack, os componentes de código aberto são ótimos para usar, porque eles aceleram o processo de desenvolvimento, mas também significa que os black hats têm acesso a esses mesmos componentes e podem encontrar pontos fracos no código. Se as organizações não rastrearem o uso de código aberto, elas usarão componentes que têm vulnerabilidades conhecidas, facilitando muito a violação ou a invasão da empresa.

No caso de uma ação - a maioria dos componentes de código aberto é regida por uma licença, essencialmente definindo as regras básicas para uso. Algumas licenças são muito abertas e permitem que uma pessoa ou organização use o componente de código aberto de qualquer maneira desejada. Outras licenças são muito mais restritivas, muitas vezes afirmando que qualquer coisa construída ou usando esse componente também deve se tornar open source. Isso pode ser catastrófico para a Propriedade Intelecutal de uma organização, já que pode ser perdido para o mundo de código aberto se os componentes forem usados ​​com licenciamento restritivo.

O projeto de indexação providencial é sobre segurança ou há outros benefícios?

O objetivo da colaboração entre o Software Heritage e a CAST é alavancar as tecnologias patenteadas da CAST para criar um "Índice de Proveniência". O objetivo aqui é ajudar a economizar tempo e dar transparência aos desenvolvedores sobre os componentes de código aberto que eles usam, para que eles possam projetar e codificar softwares mais seguros do ponto de vista legal e de segurança.

Você tem alguma informação ou dados sobre a probabilidade de uma organização ter código vulnerável?

O National Vulnerability Database rastreia mais de 100 mil vulnerabilidades conhecidas. Para organizações que têm mais de um punhado de aplicativos que usam código aberto, há quase 100% de chance de que seu software tenha uma vulnerabilidade conhecida.

O uso de código aberto só aumentará no futuro. As organizações não precisam ter medo disso, elas só precisam catalogar e rastrear seu uso de código aberto.

Usando a análise de composição de software, as organizações podem detectar e gerenciar todos os seus componentes de código aberto e identificar quaisquer vulnerabilidades conhecidas. Se eles tiverem um processo para verificar e corrigir essas vulnerabilidades conhecidas, isso reduzirá drasticamente o risco de usar o software de código aberto

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

Blog Lambda3 - Retrospectiva remota? Conheça o Suricato Ágil!

Programa interessante para reuniões de equipe como brainstorm. JEPAlayon.


Por Arthur Fücher 
jan 19, 2017 

Aloha! Sou Arthur Fücher e iniciei como Scrum Master aqui na Lambda3 esse ano \o/ Vou utilizar o blog para compartilhar minhas experiências e aprendizados nessa jornada.

Estou atuando em um time que possui uma pessoa remota, utilizamos no dia-a-dia diversas ferramentas que facilitam a comunicação e diminuem essa distância física, como por exemplo, Slack e Skype.

Eis que chegou o momento onde teria que fazer a Retrospectiva com o time, normalmente a retrospectiva era feita com a pessoa remota via Skype e no ambiente onde o resto do time estava era utilizado um board com post-its.

Com o intuito de tentar aproximar a experiência de todas as pessoas do time, resolvi utilizar um board on-line para isso! Recebi uma ótima indicação da Ceci, para utilizar o Suricato Ágil:

E ainda para minha surpresa descobri que conheço o Lucas, que criou o projeto junto com o Marcio. (Parabéns pelo projeto!! )

Foi a primeira vez que utilizei a ferramenta, pretendo mostrar o básico da utilização e contar um pouco da experiência e percepções. Antes de continuar uma característica muito importante do Suricato: OpenSource, ou seja, é possível contribuir para que a ferramenta evolua!

Utilização básica

Bom, vamos lá! Para começar a utilizar o Suricato basta fazer um cadastro simples, e você já tem acesso ao dashboard:

No botão + é possível tanto um Board para retrospectiva ou um Time, e dentro do time é possível adicionar outros usuários do Suricato.

Com um time criado, é possível adicionar boards específicos para aquele time e com isso todos irão conseguir acessar.

Na criação de um board são apresentados algumas atividades pré-definidas pelo sistema, como por exemplo:

Starfish:

Open the Box:

Depois de criar, o board estará disponível para todos do time!

Ao acessar será apresentada a atividade na tela, e na lateral diversas opções de cores de post-its para serem usadas:

Para utilizar um post-it, basta arrastar um da cor desejada para o painel, ao soltar será aberta a edição de texto para colocar o que deseja.

O post-it apenas aparece para os outros usuários quando você dá Enter pela primeira vez depois de digitar o texto do post-it, ou seja, é possível adicionar vários e somente depois torná-los públicos!

Experiências e percepções

Bom, agora que já expliquei um pouco de como usar, vamos falar da experiência e percepções que tivemos:

A dinâmica que ia fazer não tinha disponível no Suricato

Bom, essa foi fácil de resolver. Peguei uma atividade parecida, e utilizando o post-it branco coloquei por cima das coisas, substitui palavras, e pronto! Atividade customizada 🙂

Atualização real-time!

O board é atualizado automaticamente, com isso todos conseguem ter uma experiência bem parecida com a de um boardfísico.

Os post-its são anônimos! Não aparece quem escreveu, o que em vários momentos é bem legal! Mas e se eu quiser saber quem foi?

Essa também foi fácil, cada um escolheu uma cor de post-it para chamar de seu 😉

Um ponto que o próprio time levantou foi a não utilização de papel!

Geralmente retrospectivas gastam uma quantidade razoável de post-its, e com a utilização da ferramenta isso não foi necessário.

Open-source

Não gostou de alguma coisa? Precisa de alguma feature que não tem? Abra uma issue, discuta e mande PR!! Ajude a ferramenta a evoluir!

---

Espero que tenham gostado do meu primeiro post! Comentem o que acharam, e também me digam: quais ferramentas conhecem/utilizam?

Abraços, e até breve 😉

Links:http://suricatoagil.com/https://github.com/mxball/suricato