CISA lays out new guidance for using open-source software
The US Cybersecurity and Infrastructure Security Agency (CISA) has published the Open Source Software: Security Principles and Practices guide, which provides federal agencies with recommendations for managing the security of open source software, contributing to OSS projects, and evaluating open source AI systems.
Using open source software
Federal agencies can benefit from open source software because its source code can be independently reviewed, reducing reliance on vendor claims. It can reduce dependence on a single supplier, lower costs by eliminating licensing fees and sharing development efforts, and support transparency by making publicly funded software available where appropriate.
CISA recommends treating open source software like any other software asset by assessing its security before adoption and monitoring it throughout its lifecycle. Agencies should choose actively maintained projects, understand the licenses governing their use, and maintain an inventory of the open-source components they depend on, the agency advises.
The guidance recommends tracking software dependencies, monitoring projects for newly disclosed vulnerabilities, and regularly assessing whether projects remain trustworthy. Software bills of materials (SBOMs) can help identify affected components when new vulnerabilities are disclosed.
Agencies should apply security patches as soon as practical and be prepared to contribute fixes when using custom-built software or when an open source project has not yet released an update. If a project reaches the end of support or security issues remain unresolved, the agency recommends replacing it with a supported alternative.
Tools, including AI, are increasing the number of vulnerabilities discovered and accelerating patch development. CISA encourages organizations to automate dependency management, patch deployment, and security testing where possible.
Contributing to projects
CISA encourages agencies to contribute improvements to the open source projects they use, including security fixes, bug reports, documentation, and technical discussions. Sharing those changes with the wider community can reduce duplicate work, improve software for all users, and make government-funded improvements publicly available.
Before contributing, agencies should confirm that a project’s license permits participation and should definitely review contributed source code, documentation, and configuration files to make sure they do not expose passwords, encryption keys, internal system details, or other confidential information.
Developing and publishing OSS
Agencies that develop software are encouraged to consider open source development and publication from the start unless legal, security, or operational reasons prevent release, CISA says.
An inventory of internally developed software should indicate whether each project will be released publicly, shared only within the federal government, or withheld for legal, security, or operational reasons.
Before publishing a project, agencies should review it for sensitive information such as passwords, encryption keys, and internal system details. They should follow secure software development practices, select an appropriate open source license, and publish the project in a public code repository with documentation, contribution guidelines, a vulnerability disclosure policy, and an SBOM.
After release, agencies are encouraged to maintain projects by publishing updates, addressing security issues, and clearly communicating when software is no longer supported.
When contractors develop custom software, CISA recommends ensuring the government retains the rights needed to reuse, modify, and, where appropriate, release the code as open source.
Evaluating open source AI systems
The guidance says organizations should evaluate so-called “open source” AI systems differently from open source software, because AI models can be released under an open source license without making their training data publicly available.
Without access to the training data and training process, organizations may be unable to establish a model’s provenance or fully assess whether its development process or components have been manipulated, the agency noted.
Before deploying an open source AI system, organizations should determine whether they have sufficient visibility into how it was developed, including its training data and training process. If that information is unavailable, the guidance recommends treating the system as proprietary software with incomplete provenance and applying stricter risk management practices.