Classificação de bibliotecas que exigem verificação de segurança especial

O fundo estruturado pela organização Linux Foundation Core Infrastructure Initiative, no qual as principais corporações uniram esforços para apoiar projetos abertos nas áreas-chave da indústria de computação, realizou segundo estudo do programa Census, focado em identificar projetos abertos que necessitam de uma auditoria de segurança prioritária.

O segundo estudo se concentra na análise de código aberto compartilhado, frequentemente utilizado em diversos projetos empresariais na forma de dependências baixadas de repositórios externos. Vulnerabilidades e comprometimentos de desenvolvedores de componentes de terceiros envolvidos no trabalho de aplicativos (supply chain) podem anular todos os esforços para melhorar a proteção do produto principal. Como resultado da pesquisa, foram identificados 10 pacotes mais utilizados em JavaScript e Java, cuja segurança e manutenção exigem atenção especial.

Bibliotecas JavaScript do repositório npm:

• assíncrono (196 mil linhas de código, 11 autores, 7 colaboradores, 11 problemas não resolvidos);
• inherits (3.8 mil linhas de código, 3 autores, 1 colaborador, 3 problemas não resolvidos);
• isarray (317 linhas de código, 3 autores, 3 colaboradores, 4 problemas não resolvidos);
• kind-of (2 mil linhas de código, 11 autores, 11 colaboradores, 3 problemas não resolvidos);
• lodash (42 mil linhas de código, 28 autores, 2 colaboradores, 30 problemas não resolvidos);
• minimist (1.2 mil linhas de código, 14 autores, 6 colaboradores, 38 problemas não resolvidos);
• natives (3 mil linhas de código, 2 autores, 1 colaborador, sem problemas não resolvidos);
• qs (5.4 mil linhas de código, 5 autores, 2 colaboradores, 41 problemas não resolvidos);
• readable-stream (28 mil linhas de código, 10 autores, 3 colaboradores, 21 problemas não resolvidos);
• string_decoder (4.2 mil linhas de código, 4 autores, 3 colaboradores, 2 problemas não resolvidos).

Bibliotecas Java dos repositórios Maven:

• jackson-core (74 mil linhas de código, 7 autores, 6 colaboradores, 40 problemas não resolvidos);
• jackson-databind (74 mil linhas de código, 23 autores, 2 colaboradores, 363 problemas não resolvidos);
• guava.git, bibliotecas Google para Java (1 milhão de linhas de código, 83 autores, 3 colaboradores, 620 problemas não resolvidos);
• commons-codec (51 mil linhas de código, 3 autores, 3 colaboradores, 29 problemas não resolvidos);
• commons-io (73 mil linhas de código, 10 autores, 6 colaboradores, 148 problemas não resolvidos);
• httpcomponents-client (121 mil linhas de código, 16 autores, 8 colaboradores, 47 problemas não resolvidos);
• httpcomponents-core (131 mil linhas de código, 15 autores, 4 mantenedores, 7 problemas não resolvidos);
• logback (154 mil linhas de código, 1 autor, 2 mantenedores, 799 problemas não resolvidos);
• commons-lang (168 mil linhas de código, 28 autores, 17 mantenedores, 163 problemas não resolvidos);
• slf4j (38 mil linhas de código, 4 autores, 4 mantenedores, 189 problemas não resolvidos);

O relatório também aborda questões de padronização de nomenclatura para componentes externos, proteção de contas de desenvolvedores e manutenção de versões antigas após o lançamento de novas versões significativas. Além disso, a organização Linux Foundation publicou um documento com recomendações práticas para organizar um processo de desenvolvimento seguro em projetos abertos.

O documento aborda questões de distribuição de funções no projeto, criação de equipes responsáveis pela segurança, definição de políticas de segurança, supervisão das permissões dos participantes do projeto, uso correto do Git ao corrigir vulnerabilidades para evitar vazamentos antes da publicação da correção, definição de processos de resposta a relatos de problemas de segurança, implementação de sistemas de teste de segurança, aplicação de procedimentos de revisão de código, e consideração de critérios de segurança ao formar lançamentos.

Fonte: opennet.ru