Projeto de lei que obriga o compartilhamento de código-fonte entre agências dos EUA é promulgado

 (fedscoop.com)
1 pontos por GN⁺ 2024-12-27 | 1 comentários | Compartilhar no WhatsApp
  • Ao assinar o SHARE IT Act em 23 de dezembro, o presidente Joe Biden determinou que as agências federais dos EUA devem compartilhar entre si códigos-fonte personalizados para reduzir contratos de desenvolvimento duplicados
  • O ponto central é catalogar publicamente o código personalizado de cada agência e torná-lo reutilizável, com o objetivo de reduzir os cerca de US$ 12 bilhões que se estima que o governo federal gaste por ano na compra de software
  • Ficam fora do escopo da lei código classificado, sistemas de segurança nacional e códigos cujo compartilhamento possa criar riscos à privacidade
  • Os CIOs das agências devem estabelecer, em até 180 dias após a entrada em vigor, políticas de implementação que incluam conformidade com boas práticas, divulgação de metadados e procedimentos padronizados de relatório
  • Atlassian e GitLab Inc. apoiaram o projeto, que foi aprovado em dezembro na Câmara e no Senado sem votação nominal registrada

Obrigação de compartilhamento de código no SHARE IT Act

  • O Source Code Harmonization And Reuse in Information Technology Act, ou SHARE IT Act, exige que agências federais compartilhem com outras agências o código-fonte desenvolvido sob medida
  • O foco é reduzir o desenvolvimento duplicado, em que código já criado para outra agência é contratado e produzido novamente por desconhecimento
  • As agências devem catalogar publicamente o código personalizado e permitir que outras agências utilizem esse código

Meta de redução de custos e exceções de aplicação

  • Os patrocinadores da lei estimam que o governo federal gaste cerca de US$ 12 bilhões por ano na compra de software
  • O SHARE IT Act busca reduzir esse custo por meio da reutilização de código personalizado
  • Os seguintes códigos ficam excluídos da aplicação da lei
    • código classificado
    • sistemas de segurança nacional
    • código cujo compartilhamento possa gerar riscos à privacidade

Obrigação dos CIOs de definir políticas em até 180 dias

  • Os chief information officers (CIOs) das agências devem criar uma política de implementação do SHARE IT Act em até 180 dias após a entrada em vigor da lei
  • A política deve incluir os seguintes procedimentos
    • procedimentos para garantir que o código desenvolvido sob medida siga as boas práticas
    • procedimentos para disponibilizar publicamente os metadados do código personalizado
    • procedimentos padronizados de relatório

Metadados que devem ser divulgados

  • Os metadados mencionados na lei incluem informações que permitem verificar o status de desenvolvimento e compartilhamento do código personalizado
  • Os itens incluídos são os seguintes
    • se o código personalizado foi desenvolvido nos termos de um contrato
    • se o código foi compartilhado em um repositório
    • número do contrato
    • hiperlink para o repositório onde o código foi compartilhado

Tramitação legislativa e apoio da indústria

  • O projeto foi patrocinado por Ted Cruz e Gary Peters no Senado, e por Nicholas Langworthy e William Timmons na Câmara
  • Câmara e Senado aprovaram o projeto em dezembro sem votação nominal registrada
  • Segundo o anúncio de setembro feito por Langworthy sobre a apresentação do projeto na Câmara, Atlassian e GitLab Inc. apoiaram a proposta
  • Stan Shepard, diretor jurídico da Atlassian, considera que ampliar a colaboração e o compartilhamento de código personalizado promove abertura, eficiência e inovação em toda a estrutura das organizações federais

Leituras relacionadas

1 comentários

 
GN⁺ 2024-12-27
Opiniões no Hacker News

  • Se você não tem experiência com governo, talvez não tenha noção de por que isso é tão difícil. As Forças Armadas têm alergia a software interno, e TI militar é um mundo completamente diferente, atacado todos os dias por invasores patrocinados por Estados no mais alto nível mundial
    Startups não passam por isso, e mesmo grandes empresas como o Facebook só chegam perto de uma experiência semelhante em termos de importância; no setor privado, o mais próximo talvez sejam grandes instituições financeiras. As Forças Armadas dos EUA também são o maior empregador individual do planeta, equivalentes a 4,5 Walmarts
    Por isso, os militares monitoram tudo em várias camadas e travam fortemente o ambiente com listas de software aprovado por camada. As pessoas que escrevem ou supervisionam as políticas de segurança provavelmente não são diretores de software experientes; quando olham para NPM ou Maven, veem vetores de ataque ilimitados criados por gente que não entende de segurança — e não estão totalmente erradas
    Nas áreas civil e de contratadas, a propriedade do código também é complicada. Se foi feito com dinheiro do governo, deveria pertencer ao governo, mas as contratadas veem isso como um ativo próprio, separado do governo, que precisam manter para poder cobrar de novo. Fica ainda mais complexo quando as subcontratadas não estão alinhadas às metas financeiras da contratante principal. Pessoalmente, acho que bastaria entregar tudo ao governo, mas é estranho como as pessoas erguem barreiras em camadas. A infraestrutura do lado do governo tem um nível de certificação de segurança muito mais alto, então em geral também há menos restrições

    • Retratar a TI militar como quase inexpugnável ignora a realidade de que infraestrutura antiga e políticas obtusas reduzem muito a eficiência
      Algumas áreas das Forças Armadas dos EUA podem de fato enfrentar o nível de ameaças e sofisticação de segurança descrito, mas, no conjunto, há muitos sistemas legados que dificultam a integração de soluções modernas e boas práticas. Esses sistemas, fluxos de trabalho e burocracias antiquados tendem mais a gerar ineficiências e vulnerabilidades do que uma segurança excepcional
      O fato de você não ouvir falar que as Forças Armadas dos EUA foram comprometidas não significa que isso não aconteça, e sim que, quando acontece, é tratado como sigiloso. Evitar constrangimento público é o principal uso da classificação de sigilo, o que cria uma crença de competência. Eu colocaria a segurança do Facebook à frente da militar a qualquer momento, e acho que a diferença não é pequena. O Facebook também é um processador de pagamentos
    • É difícil concordar com a ideia de que “grandes empresas como o Facebook só passam por algo parecido porque não são tão importantes”. Quando trabalhei na Microsoft e conversei com a equipe de segurança, a impressão era de que a MSFT sofria ataques em nível estatal constantemente, incluindo tentativas de infiltrar ativos governamentais na Microsoft para extrair informações sigilosas
      Considerando a importância da AWS, é evidente que a Amazon também deve enfrentar ameaças semelhantes
    • A meu ver, esse projeto de lei tem muito pouco a ver com os militares. O texto real diz que código-fonte sigiloso ou código-fonte para sistemas de segurança nacional não está no escopo
      (A) Disposição geral — Esta lei não se aplica a código-fonte sigiloso ou a código-fonte desenvolvido principalmente para uso em sistemas de segurança nacional, conforme definido em 40 U.S.C. 11103
      (B) Segurança nacional — A isenção dos requisitos da seção 3 aplica-se a código-fonte sigiloso ou ao seguinte código-fonte: (i) código desenvolvido principalmente para uso em sistemas de segurança nacional, ou (ii) código desenvolvido por uma entidade componente da comunidade de inteligência, ou por parte dela, conforme definida na seção 3(4) da Lei de Segurança Nacional de 1947
    • Durante um ano conversei com a equipe de segurança do meu departamento, com pessoas em torno do departamento cliente, com a rede local de contratadas e com vários fornecedores; quando vi o cliente do governo me encarar sem reação ao ouvir que outro ramo das Forças Armadas já havia concluído exatamente a mesma coisa que meu projeto alguns anos antes e que “talvez fosse só falar com eles”, larguei o trabalho com contratos
      Foi aí que entendi como funciona o negócio de contratos governamentais e por que as coisas se arrastam por anos além do necessário
    • Concordo com a ideia de “entregar tudo ao governo”. Na prática, trabalhei em uma contratada em que o cliente era dono de todos os entregáveis, e sempre achei estranho ver colegas trabalhando em contratadas onde isso não era assim
      É dinheiro pago com nossos impostos, então a pergunta é: por que apoiar um modelo que tira dinheiro do bolso de todos para enriquecer muito alguns figurões e equipes de vendas de empresas?
      Se a posição for “não vamos dar tudo ao governo”, a forma razoável, a meu ver, seria dar ao governo o direito de usar os entregáveis como quiser, permitindo ao mesmo tempo que componentes não sigilosos e seus derivados sejam vendidos livremente ao setor privado

  • A lei exige que o CIO de cada agência crie uma política em até 180 dias após a entrada em vigor, e essa política deve garantir que o código desenvolvido sob medida siga as melhores práticas, além de definir procedimentos para divulgar os metadados do código sob medida e procedimentos padronizados de relatório
    Na nova lei, os metadados incluem se o código sob medida foi desenvolvido por contrato, se foi compartilhado em um repositório, o número do contrato e o link para o repositório onde o código foi compartilhado
    Infelizmente, não parece ser uma lei que obrigue as agências a tornar o código open source público, mas apenas a exigir compartilhamento entre agências. O que deve ser compartilhado publicamente é apenas os “metadados”. O texto integral do projeto está em https://www.congress.gov/bill/118th-congress/house-bill/9566...

    • É um bom primeiro passo. A próxima etapa deve ser compartilhar com governos estaduais, governos locais e universidades. O compartilhamento público distribui muitas responsabilidades de TI que hoje não existem
    • Só pelo título publicado, isso já parece suficientemente claro
    • Quando vejo o termo “melhores práticas”, começo a desconfiar. Porque há uma grande chance de isso incentivar ainda mais o culto à carga burocrático
    • A maioria dos contratos do DOE, ou seja, contratos do governo com universidades ou consórcios que operam laboratórios, costuma conter algo como: “se não for comprovado que este código-fonte tem potencial comercial ou valor para SBIR, ele pode ser mantido privado ou publicado como open source. Mas GPL não pode”
      Há exceções, mas também existia a lógica de que outros contratados deveriam manter a capacidade de modificar o código-fonte e, da mesma forma, não divulgá-lo. Imagino que provavelmente seja por causa da área de defesa
      Para mantê-lo privado por motivos financeiros, o critério era alto, mas sempre foi possível mantê-lo privado por qualquer outro motivo. DOE Code é um programa que rastreia software open source e normalmente é gerenciado por meio de organizações no GitHub. O OSTI é o departamento que rastreia toda a propriedade intelectual e pesquisa
    • Alguns, como o ZFSOnLinux, já são compartilhados publicamente. O repositório agora virou o repositório OpenZFS e melhorou a vida de muita gente. A minha também ficou mais fácil
      O modelo de desenvolvimento open source também foi benéfico para o LLNL, que acabou com uma base de código muito melhor do que teria se desenvolvesse sozinho
      Também há coisas que já são públicas, como o NASA IKOS: https://github.com/NASA-SW-VnV/ikos
      Esse projeto recebe muito menos atenção de terceiros do que deveria. Se ele puder evoluir para um analisador estático sólido e de uso geral que lide com multithreading, ajudará a melhorar muitos outros projetos

  • Já tentei promover um modelo open source completo com a ideia de que “se o orçamento é público, o público deve ver os resultados gerados por esse dinheiro”: https://web.archive.org/web/20200920095030/http://oss4gov.or...
    Eu achava que o padrão para software do governo deveria ser open source, salvo exceções aprovadas em nível ministerial. Mas eu era jovem e ingênuo na época

    • Não acho que isso seja tão controverso assim. O governo do Reino Unido vê de forma parecida: https://www.gov.uk/service-manual/technology/making-source-c...
    • Trabalhei por anos em uma contratada militar, e muita gente acredita que, se o contribuinte pagou e o software não é sigiloso, ele deveria ser open source
      Ghidra é um bom exemplo, e o fato de esse software ter se tornado gratuito foi um grande benefício para a comunidade de segurança
    • A FSFE também compartilha a mesma ideia do outro lado do Atlântico: https://publiccode.eu/en/
    • Você não era ingênuo; estava à frente do seu tempo. Progresso é trabalho árduo e uma maratona

  • Nós criamos software open source e tentamos fazer com que órgãos governamentais o adotem ou usem, mas é impressionante o nível de alergia a open source que esses órgãos demonstram
    Alguns preferem criar tudo por conta própria, usando métodos legados como upload de CSV ou parsers quebrados, em vez de usar o código de outras pessoas, e acabam criando junto os bugs e falhas previsíveis
    Mesmo ao responder a solicitações de proposta, a opção open source passa por uma análise mais rigorosa do que sistemas fechados. Quando está aberto, é preciso provar que isso é bom; quando é fechado, o fornecedor diz “sim, é perfeito” e o órgão pode seguir em frente. Dá a impressão de que os órgãos e seus funcionários não querem assumir nenhuma responsabilidade. Ainda assim, nunca vi alguém perder um emprego no governo por incompetência

    • No quadro geral, isso é protecionismo de empregos; no nível individual, é uma estrutura em que especialistas no assunto tentam usar sua própria base de código para avançar na carreira. Em geral, as agências não se veem como parte do mesmo time. Podem ser muito competitivas ao fazer lobby no Congresso para obter recursos para sua própria agência
      Trabalho no governo e falo por experiência própria. A cultura é muito tóxica e quebrada. Estou curioso para ver que mudanças a equipe de Elon e Trump vai propor
    • Em open source, não há ninguém a quem atribuir responsabilidade. Com software fechado, quando algo dá errado, há alguém para apontar o dedo

  • O Departamento de Defesa dos EUA tem um FAQ sobre software de código aberto: http://dodcio.defense.gov/OpenSourceSoftwareFAQ.aspx e https://github.com/risacher/DoD-OSS-FAQ
    Esta versão foi publicada no GitHub como um experimento de ferramenta colaborativa para participação pública em documentos de política governamental, e afirma que militares, civis, contratados e cidadãos podem enviar sugestões de alterações ou acréscimos por meio de pull requests
    Vídeo de 2010: https://www.youtube.com/watch?v=WWt0YiXcEkE
    Dan Risacher, do escritório do CIO do DoD, e o especialista em segurança de código aberto David A. Wheeler explicam a história e os impactos de um memorando recente do DoD que deixou clara a posição de que o Departamento de Defesa vê o open source como uma forma viável de software comercial
    Material de 2024: https://openssf.org/press-release/2024/10/29/openssf-expands...
    A OpenSSF da Linux Foundation disse reconhecer a necessidade de treinamento em segurança e, segundo David A. Wheeler, diretor de segurança da cadeia de suprimentos open source da OpenSSF, mais de 25.000 pessoas se inscreveram nesses materiais de treinamento desde o início do curso

  • A intenção é boa, mas, na prática, acho que não vai acontecer muita coisa além de potenciais concorrentes do contratado 1 reduzirem a distância ou atacarem com base na qualidade do código do contrato existente. Ler código é mais difícil do que escrever código

    • Se potenciais concorrentes reduzirem a distância, do ponto de vista do governo isso aumenta a concorrência e reduz custos
      Se atacarem com base na qualidade do código do contrato existente, isso é code review e, de um jeito ou de outro, leva a melhorias na qualidade do código. Não vejo qual é o problema aqui

  • É uma ótima iniciativa. Lembro de ter sofrido por não conseguir ler código nem dentro da mesma organização. Esse tipo de mudança deve facilitar a vida de quem constrói modelos mentais de cima para baixo

  • Em geral, tudo que foi pago com dinheiro do contribuinte deveria ser público. Public Monies Public Goods deveria ser um princípio básico absoluto

    • Essa regra já existe, mas a única instituição que a leva a sério é o DoD. Exemplos incluem BRL-CAD e FalconView
      Ainda assim, isso não impede contratados antiéticos de colocar copyright no código e cobrar taxas de licenciamento. A maior parte do código do DoE é assim, com exceções como o NWCHEM. Sempre me perguntei por que isso não virou processo, mas provavelmente é porque ninguém se importa muito
    • É interessante que alguns governos locais coloquem copyright em suas próprias leis para impedir que outros governos locais as copiem sem pagar
      Por um lado, dá para entender a visão de que outras regiões estão pegando carona, sem pagar, em um sistema de normas financiado pelos contribuintes daquela localidade. Ainda mais se essas leis se aplicarem principalmente ao governo local da própria região. Por outro lado, parece estranho que leis sejam restringidas por copyright
    • Discordo. Por causa da China. O governo dos EUA precisa manter seu código fechado, inclusive o código lixo de contratadas absurdamente caras
    • No caso de software, discordo
    • Você está propondo tornar tudo público, de materiais sigilosos a memorandos administrativos e registros de pessoal? Isso não vai acontecer
      Quando você contrata alguém para fazer um trabalho em casa, também precisa pensar exatamente no que passa a possuir além do produto final

  • É uma excelente direção. Ao trabalhar com equipes governamentais, já vi essa abordagem ser apresentada como prática recomendada em alguns lugares: https://www.forgov.qld.gov.au/information-and-communication-...
    No entanto, em muitos casos, para que essa recomendação seja de fato seguida, ainda é necessário dar o passo de transformá-la em requisito legal. Especialmente nos serviços públicos, onde é comum haver pessoas que nunca participaram de uma comunidade open source
    Como outros destacaram, orçamento público deve gerar benefício público, e o open source é uma boa forma de ampliar esse benefício

  • Há um trecho que diz: “a nova lei não se aplica a código sigiloso, sistemas de segurança nacional ou código que, se compartilhado, causaria riscos à privacidade”
    Que tipo de código causaria riscos à privacidade se fosse compartilhado? Isso soa como se código e dados estivessem bastante mal misturados

    • Não há risco real, mas isso dá uma boa desculpa para não publicar. Empresas e órgãos governamentais já negaram pedidos de acesso à informação sobre documentação técnica por motivos de proteção de dados pessoais. Diziam coisas como “aplica-se a sistemas que tratam dados pessoais” ou “conhecer o funcionamento interno do sistema aumenta a chance de o sistema ser comprometido”
      Contratados do governo admitem de bom grado, nas entrelinhas, que seu código é ruim e depende em grande parte de segurança por obscuridade. A comissão de informação também ficou do lado deles algumas vezes
    • Código suficientemente customizado acaba tendo funcionalidades que revelam muita informação sobre a atividade-alvo
      Basta pensar no que você poderia ver em fórmulas do Excel, por exemplo
    • Não há diferença entre os dois