O Google propõe estabelecer novas regras para melhorar a segurança do código aberto

A segurança do software de código aberto atraiu a atenção da indústria, mas as soluções requerem consenso sobre os desafios e cooperação na implementação.

O problema é complexo e há muitas facetas a serem abordadas, da cadeia de suprimentos, gerenciamento de dependências, identidade, entre outras coisas. Para fazer isso, o Google lançou recentemente uma estrutura ("Conhecer, Prevenir, Consertar") que explica como a indústria pode pensar sobre vulnerabilidades em código aberto e áreas específicas que precisam ser resolvidas primeiro.

O Google explica seus motivos:

“Devido a eventos recentes, o mundo do software ganhou uma compreensão mais profunda do risco real de ataques à cadeia de suprimentos. O software de código-fonte aberto deve ser menos arriscado do ponto de vista da segurança, já que todos os códigos e dependências estão abertos e disponíveis para inspeção e verificação. E embora isso seja geralmente verdade, presume-se que as pessoas estejam realmente fazendo esse trabalho de inspeção. Com tantas dependências, é impossível monitorar todas elas e muitos pacotes de código aberto não são bem mantidos.

“É comum um programa depender, direta ou indiretamente, de milhares de pacotes e bibliotecas. Por exemplo, o Kubernetes agora depende de cerca de 1000 pacotes. O código aberto provavelmente usa dependências em vez de software proprietário e vem de uma gama mais ampla de fornecedores; o número de entidades independentes em que se pode confiar pode ser muito grande. Isso torna extremamente difícil entender como o código aberto é usado em produtos e quais vulnerabilidades podem ser relevantes. Também não há garantia de que o que é construído corresponderá ao código-fonte.

Dentro da estrutura proposta pelo Google, sugere-se dividir essa dificuldade em três áreas de problemas amplamente independentes, cada uma com objetivos específicos:

Conheça as vulnerabilidades do seu software

Conhecer as vulnerabilidades do seu software é mais difícil do que você imagina por muitas razões. Sim, bem mecanismos existem para relatar vulnerabilidades, não está claro se eles realmente afetam as versões específicas do software que você está usando:

• Objetivo: Dados precisos de vulnerabilidade: Primeiro, é fundamental capturar metadados de vulnerabilidade precisos de todas as fontes de dados disponíveis. Por exemplo, saber qual versão introduziu uma vulnerabilidade ajuda a determinar se o software foi afetado e saber quando foi corrigido resulta em correções precisas e oportunas (e uma janela estreita para exploração potencial). Idealmente, esse fluxo de trabalho de classificação deve ser automatizado.
• Em segundo lugar, a maioria das vulnerabilidades reside em suas dependências, e não no código que você escreve ou controla diretamente. Portanto, mesmo quando seu código não muda, o panorama de vulnerabilidades que afetam seu software pode mudar constantemente - algumas são corrigidas e outras adicionadas.
• Objetivo: Esquema padrão para bancos de dados de vulnerabilidade Os padrões de infraestrutura e de mercado são necessários para rastrear e manter vulnerabilidades de código aberto, entender suas consequências e gerenciar suas atenuações. Um esquema de vulnerabilidade padrão permitiria que ferramentas comuns fossem executadas em vários bancos de dados de vulnerabilidade e simplificaria a tarefa de rastreamento, especialmente quando as vulnerabilidades cruzam vários idiomas ou subsistemas.

Evite adicionar novas vulnerabilidades

Seria ideal para evitar a criação de vulnerabilidades E embora as ferramentas de teste e análise possam ajudar, a prevenção sempre será um assunto difícil.

Aqui, O Google se propõe a focar em dois aspectos específicos:

• Compreenda os riscos ao decidir sobre uma nova dependência
• Melhorar os processos críticos de desenvolvimento de software

Reparar ou remover vulnerabilidades

O Google reconhece que o problema geral de reparo está além de seu alcance, mas o editor acredita que há muito mais que os atores podem fazer para resolver o problema específico para gerenciar vulnerabilidades em dependências.

Também menciona: 

“Hoje há pouca ajuda nessa frente, mas conforme melhoramos a precisão, vale a pena investir em novos processos e ferramentas.

“Uma opção, claro, é corrigir a vulnerabilidade diretamente. Se você puder fazer isso de maneira compatível com versões anteriores, a solução estará disponível para todos. Mas o desafio é que é improvável que você tenha experiência com o problema ou a capacidade direta de fazer alterações. A correção de uma vulnerabilidade também pressupõe que os responsáveis ​​pela manutenção do software estejam cientes do problema e tenham o conhecimento e os recursos para divulgar a vulnerabilidade.

fonte: https://security.googleblog.com