De acordo com pt.wedoany.com-A Agência de Segurança Cibernética e de Infraestrutura dos EUA (CISA) publicou a orientação "Software de Código Aberto: Princípios e Práticas de Segurança", que orienta agências federais na gestão da segurança de software de código aberto, na participação em projetos de código aberto e na avaliação de sistemas de inteligência artificial de código aberto.
A orientação menciona que o código-fonte de software de código aberto pode ser revisado de forma independente, reduzindo a dependência de declarações de fornecedores e diminuindo o risco de ficar sujeito a um único fornecedor; a isenção de taxas de licença e o compartilhamento do trabalho de desenvolvimento podem reduzir custos, e a publicação de software financiado publicamente, quando apropriado, pode aumentar a transparência.
A CISA recomenda que as agências tratem o software de código aberto como ativos de software comuns, avaliem a segurança antes da adoção e monitorem ao longo de todo o ciclo de vida. Deve-se priorizar projetos com manutenção ativa, compreender os termos de licença e manter um inventário dos componentes de código aberto utilizados.
A orientação recomenda rastrear dependências de software, monitorar vulnerabilidades recém-divulgadas e avaliar regularmente se os projetos ainda são confiáveis. A Lista de Materiais de Software (SBOM) ajuda a identificar componentes afetados quando vulnerabilidades são divulgadas. As agências devem aplicar patches de segurança o mais rápido possível; quando software personalizado ou projetos de código aberto ainda não tiverem atualizações, devem estar preparadas para contribuir com correções. Se um projeto atingir o fim do suporte ou problemas de segurança permanecerem sem solução, deve-se substituí-lo por alternativas suportadas. Ferramentas, incluindo inteligência artificial, estão aumentando o número de vulnerabilidades descobertas e acelerando o desenvolvimento de patches; a CISA incentiva a automação máxima de gerenciamento de dependências, implantação de patches e testes de segurança.
A CISA incentiva as agências a contribuírem com melhorias para os projetos de código aberto que utilizam, incluindo correções de segurança, relatórios de erros, documentação e discussões técnicas, e a compartilharem alterações com a comunidade, a fim de reduzir trabalho duplicado, melhorar o software e divulgar resultados financiados pelo governo. Antes de contribuir, deve-se confirmar que a licença do projeto permite participação e revisar código-fonte, documentação e arquivos de configuração para evitar a exposição de senhas, chaves criptográficas, detalhes de sistemas internos e outras informações confidenciais.
Para agências que desenvolvem software internamente, a CISA incentiva considerar a publicação como código aberto desde o início, a menos que razões legais, de segurança ou operacionais não o permitam. O inventário de software desenvolvido internamente deve indicar se o projeto é publicado publicamente, compartilhado internamente no governo federal ou mantido reservado. Antes da publicação, deve-se verificar informações sensíveis, seguir práticas de desenvolvimento seguro, escolher licenças apropriadas e publicar documentação, guias de contribuição, políticas de divulgação de vulnerabilidades e SBOM em repositórios públicos de código. Após a publicação, é necessário continuar publicando atualizações, resolvendo problemas de segurança e definindo claramente quando o software deixará de ser suportado. Se o software for desenvolvido sob medida por contratados, o governo deve preservar os direitos de reutilização, modificação e, sob condições apropriadas, abertura do código.
A CISA enfatiza que a avaliação de sistemas de inteligência artificial ditos "de código aberto" deve ser diferenciada do software de código aberto: modelos de IA podem ser publicados sob licenças de código aberto sem, no entanto, divulgar os dados de treinamento. Sem acesso aos dados e ao processo de treinamento, as organizações têm dificuldade em determinar a origem do modelo e em avaliar se o processo de desenvolvimento ou os componentes foram manipulados. Antes da implantação, deve-se confirmar visibilidade suficiente sobre o método de desenvolvimento (incluindo dados e processo de treinamento); quando as informações não estiverem disponíveis, o sistema deve ser tratado como software proprietário de origem incompleta, com gestão de risco mais rigorosa.
