Os Estados Unidos que garantem o Open Source Software Act

Por Mike Dolan, Cailean Osborne, e David A. Wheeler, com contribuições de Ashwin Ramaswami

“O software de código aberto (OSS) é a base do mundo digital e a vulnerabilidade do Log4j demonstrou o quanto confiamos nele. Esse senso comum, a legislação bipartidária ajudará a proteger a OSS e fortalecer ainda mais nossas defesas de cibersegurança contra cibercriminosos e adversários estrangeiros que lançam ataques incessantes contra redes em todo o país.”

– Senador Gary Peters (D-MI), Presidente, Comissão de Segurança Interna e Assuntos Governamentais do Senado

Sobre o que é o Ato de Software de Código Aberto?

Em 21 de setembro de 2022, os senadores norte-americanos Gary Peters (D-MI) e Rob Portman (R-OH), presidente e membro do Comitê de Segurança Interna e Assuntos Governamentais do Senado, introduziram legislação bipartidária, a Lei de Software de Código Aberto (o “Act”), para ajudar a proteger agências federais e sistemas críticos de infraestrutura, fortalecendo a segurança do software.

Qual é a razão por trás deste Ato?

A Lei de Software de Código Aberto é uma resposta à vulnerabilidade Log4Shell descoberta no final de novembro de 2021. Uma audiência subsequente no Log4Shell discutiu as principais descobertas e aprendizados, que se concentraram nos desafios práticos de segurança que se aplicam a todos os softwares, não apenas a código aberto.

Em uma declaração por escrito na audiência, o senador Peters, presidente da Comissão de Segurança Interna e Assuntos Governamentais do Senado, escreveu que o incidente do Log4Shell “apresentou uma séria ameaça aos sistemas federais e às empresas de infraestrutura críticas — incluindo bancos, hospitais e serviços públicos — que os americanos dependem todos os dias para serviços essenciais”. Em julho de 2022, o Conselho Federal de Revisão de Segurança Cibernética chamou o Log4Shell de “endêmico” e disse que isso representaria um perigo por décadas.

O que a legislação fará?

Foco de código aberto para CISA

Como introduzido, o projeto de lei daria novas responsabilidades à Agência de Segurança cibernética e infraestrutura (CISA), a agência federal responsável pelo fortalecimento da segurança cibernética e proteção da infraestrutura. A legislação exige que a CISA contrate profissionais com experiência na comunidade de código aberto “na maior medida possível” e permite que a CISA estabeleça um Subcomitê consultivo de segurança de software, que abrange a segurança de código aberto, dentro do Comitê Consultivo de Cibersegurança da CISA. CISA é um componente operacional do Departamento de Segurança Interna (DHS).

Quadro de avaliação de risco de código aberto

A CISA produziria uma estrutura inicial de avaliação para lidar com o risco de código aberto, incorporando estruturas governamentais, industriais e comunitárias de código aberto e práticas recomendadas a partir da segurança do software. Usando essa estrutura, a CISA realizaria uma análise automatizada dos componentes de software de código aberto usados por sistemas federais não menos do que a cada dois anos. Finalmente, a CISA estabeleceria um programa piloto para considerar fazer uma análise semelhante para sistemas de infraestrutura críticos não federais.

OSPOs da Agência Federal

Finalmente, a Lei estabeleceria um programa piloto para estabelecer um Escritório de Programa de Código Aberto (OSPO) dentro de pelo menos uma agência federal, que seria modelada em OSPOs existentes do setor privado, sem fins lucrativos e academia. Além disso, o Escritório de Gestão e Orçamento (OMB) emitiria orientações para diretores de informação de cada agência federal sobre como contribuir e gerenciar riscos para softwares de código aberto, considerando as melhores práticas da indústria e da comunidade.

Para obter mais informações, consulte “Resumo do Rascunho que garante o Open Source Software Act de 2022” abaixo.

Quais são os próximos passos?

Esta legislação proposta é o mais recente sinal do Congresso em torno da segurança cibernética dentro do governo federal. Houve um foco tremendo, começando com a Ordem Executiva da Casa Branca de maio de 2021 sobre a melhoria da segurança cibernética do país e seu foco em práticas de gerenciamento do ciclo de vida dentro de agências federais. É possível que a conta possa ser alterada ainda mais. A legislação proposta terá que passar por votação no Senado, na Câmara dos Deputados, e ser assinada pelo presidente. O próximo passo atual para a legislação é uma sessão de marcação em 28 de setembro de 2022, na comissão de Segurança Interna e Assuntos Governamentais.

Qual é a nossa opinião?

É muito encorajador ver o Congresso tomando medidas afirmativas para enfrentar os desafios da segurança cibernética na cadeia de fornecimento de software. O foco do Congresso dos EUA no papel crítico que o software de código aberto desempenha corresponde ao foco da Casa Branca nessas questões. Algumas das ideias soam familiares para nós – por exemplo, o uso de SBOMs (Software Bill of Materials, SBOMs), a importância das práticas de segurança de desenvolvimento, construção e liberação de processos (níveis de SLSA, Cartões de Pontuação OpenSSF e o selo OpenSSF Best Practices são indicadores indicativos do setor), e um apelo para uma estrutura de avaliação de risco ecoa nosso fluxo “Painel de Avaliação de Riscos” do nosso Plano de Mobilização . Isso sugere que há oportunidades para a OpenSSF trabalhar nisso juntamente com agências governamentais como faríamos com qualquer outra organização. Também gostamos do apelo para que os OSPOs sejam pilotados, pois acreditamos que eles podem desempenhar um papel fundamental no uso seguro do OSS e mais contribuições rio acima. Talvez o mais importante, haja um reconhecimento de que há a necessidade de considerar a indústria e a comunidade de software de código aberto.

Surpreendentemente, alguns dos pontos discutidos na audiência log4Shell não fazem parte da legislação proposta. Por exemplo, a audiência discutiu que a avaliação do software de terceiros deve ser aplicada a todos os softwares (código aberto ou fonte fechada). Como Brad Arkin, SVP e Diretor de Segurança e Confiança da Cisco testemunhou, seria um erro apontar o código aberto como uma fonte única de risco. Arkin declarou:

“É, no entanto, incorreto assumir que o software de código aberto é exclusivamente uma fonte de risco. Todo software tem o potencial de conter vulnerabilidades. Todos os softwares usados em produtos e serviços corporativos e comerciais exigem gerenciamento do ciclo de vida. Juntos, precisamos melhorar ainda mais as linhas de base para a segurança do software, incluindo o software de código aberto. Precisamos, coletivamente, melhorar nossa velocidade e eficiência para encontrar e corrigir problemas quando eles surgirem. E juntos precisamos aumentar nossa resiliência contra ataques, especialmente à medida que trabalhamos para desenvolver, distribuir e aplicar patches de software e mitigações.”

O foco do projeto de lei em software de código aberto pode fazer com que muitos ignorem os riscos inerentes a todos os softwares – o software de código fechado não é imune. A instalação de software de código aberto pode levar a custos e mandatos adicionais para os quais nenhum financiamento parece ser explicitamente fornecido. Se isso tem o impacto de aumentar o custo de adoção ou implantação do OSS dentro de um governo, em relação ao software de origem fechada, isso seria lamentável. Quaisquer mandatos ou avaliações de risco devem ser aplicadas ao software, não importa a licença. O projeto de lei também parece omitir o impacto potencialmente muito positivo que o financiamento público para o trabalho de segurança em código aberto crítico teria, como todo tipo de usuário se beneficiaria.

A Open Source Security Foundation (OpenSSF) está comprometida em colaborar e trabalhar tanto a montante quanto com as comunidades existentes para promover a segurança de código aberto para todos. Estamos ansiosos para colaborar com os formuladores de políticas em todo o mundo para melhorar a segurança do software de que todos dependemos.

Resumo do Projeto de Lei de Software de Código Aberto de 2022

O projeto de lei foi introduzido em 22 de setembro de 2022. A minuta estabelece que seu objetivo é estabelecer as funções do Diretor da Agência de Segurança cibernética e infraestrutura (CISA) em relação à segurança de software de código aberto. CISA é uma divisão operacional dentro do Departamento de Segurança Interna. O CISA coordena como um dos órgãos federais no âmbito do Escritório do Diretor Cibernético Nacional (ONCD) e do Escritório de Gestão e Orçamento (OMB).

A Lei começa definindo termos que nós, no ecossistema de código aberto, podemos encontrar interesse em revisar:

Open Source Software significa “software para o qual o código-fonte legível pelo homem é disponibilizado ao público para uso, estudo, reutilização, modificação, aprimoramento e re-distribuição.””
Open Source Software Community significa “a comunidade de indivíduos, fundações, organizações sem fins lucrativos, corporações e outras entidades que:
- desenvolver, contribuir para, manter e publicar software de código aberto; ou
- caso contrário, trabalhar para garantir a segurança do ecossistema de software de código aberto.””
Open Source Software Component significa “um repositório individual de software de código aberto que é disponibilizado ao público.”.

A Lei, então, estabelece os deveres do diretor da CISA:

Divulgação, engajamento e coordenação com entidades federais e não federais para fortalecer e apoiar a segurança do software de código aberto
Publicamente publique um quadro, incorporando estruturas governamentais, industriais e comunitárias de código aberto e práticas recomendadas “para avaliar o risco de componentes de software de código aberto, incluindo dependências diretas e indiretas”. O quadro deve incorporar, no mínimo:
- as propriedades de segurança do código em um determinado componente de software de código aberto, como se o código está escrito em uma linguagem de programação segura para a memória;
- as práticas de segurança de desenvolvimento, construção e liberação de processos de um determinado componente de software de código aberto, como o uso de autenticação multifatorial por mantenedores e assinatura criptográfica de lançamentos;
- o número e a gravidade das vulnerabilidades publicamente conhecidas e não reparadas em um determinado componente de software de código aberto;
- a amplitude da implantação de um determinado componente de software de código aberto;
- o nível de risco associado ao qual um determinado componente de software de código aberto é integrado ou implantado, como se o componente opera em um limite de rede ou em um local privilegiado; e
- a saúde da comunidade para um determinado componente de software de código aberto, incluindo, quando aplicável, o nível de investimento e manutenção atual e histórico no componente de software de código aberto, como o número e a atividade dos mantenedores individuais.
Use a estrutura para realizar uma avaliação de software de código aberto federal não menos do que a cada 2 anos. O escopo da avaliação incluirá componentes de software de código aberto usados direta ou indiretamente por agências federais com base em SBOMs prontamente disponíveis, inventários de software e outras fontes de dados acessíveis.
- A Lei orienta a CISA a automatizar a avaliação “na maior medida possível” e “publicar quaisquer ferramentas usadas para conduzir a avaliação como software de código aberto”.
- A Lei orienta a CISA a desenvolver “1 ou mais listas de componentes” identificadas na avaliação, “como classificada pela criticidade, nível de risco ou uso dos componentes, ou uma combinação dela”.
- A Lei capacita a CISA a facilitar o compartilhamento dos resultados e conjuntos de dados publicamente, conforme apropriado.
Realizar um estudo piloto da viabilidade do CISA realizando a mesma avaliação-quadro para entidades críticas de infraestrutura (fora do governo Federal)

O projeto de lei adiciona um subcomitê para “segurança de software, incluindo segurança de software de código aberto” ao Comitê Consultivo de Segurança Cibernética existente. O Comitê Consultivo tem a tarefa de “aconselhar, consultar, informar e fazer recomendações ao Diretor, conforme apropriado, sobre o desenvolvimento, refinamento e implementação de políticas, programas, planejamento e treinamento relativos à missão de cibersegurança da Agência”.

O projeto de lei exige que oncd, OMB e CISA emitam orientações para os diretores de informações da agência federal (CIOs) para:

como os CIOs “devem, considerando as melhores práticas da comunidade de software de código aberto e industrial,
- gerenciar e reduzir os riscos de uso de software de código aberto; e
- guia contribuindo e liberando software de código aberto;”
como os CIOs “devem permitir, em vez de inibir, o uso seguro de software de código aberto em cada agência coberta”;

Em seguida, o projeto de lei exige um programa piloto para estabelecer um OSPO dentro de pelo menos uma agência federal, que é modelada em OSPOs do setor privado, sem fins lucrativos e academia, para:

“suporte o uso seguro de software de código aberto na agência coberta;
desenvolver políticas e processos de contribuições e lançamentos de software de código aberto na agência coberta, em consulta, conforme apropriado, junto aos Escritórios de Assessoria Geral e Aquisição da agência coberta;
interface com a comunidade de software de código aberto; e
gerenciar e reduzir os riscos de consumir software de código aberto na agência coberta.””

Artigo Original