S 917 Introduced
CISA and Open-Source Software
Last month Sen Peters (D,MI) introduces S 917, the Securing Open Source Software Act of 2023. The bill establishes several areas of responsibility for CISA regarding open-source software security. No funding is authorized in the bill. This bill is very similar to S 4913 that was introduced by Peters last session. That bill was reported by the Senate Homeland Security and Governmental Affairs Committee with minor amendments, but no further action was taken.
Definitions
Section 3(a)(1) of the bill adds three new definitions to 6 USC 650 {this new section was added last session by HR 7776 (PL 117-263), pg 1260, and not yet codified to USC} by, the section of US Code that provides definitions used in outlining the responsibilities for the Cybersecurity and Infrastructure Security Agency in 6 USC SUBCHAPTER XVIII. The three new terms are:
In the new (see discussion below) §2220F, Open Source Software Security Duties, subsection (a) provides for the definition of the term ‘software bill of materials’ to be used in that new section by reference to the definition in the Minimum Elements for a Software Bill of Materials published by the Department of Commerce. There is no simple definition of SBOM in that document, the entire document is a discussion of what constitutes an SBOM in the eyes of National Telecommunications and Information Administration (NTIA) as required by EO 14028.
Open Source Software Security Duties
Section 3(a)(3) adds a new section, §2220F, Open Source Software Security Duties to the Homeland Security Act of 2002. Subsection (c) outlines the CISA responsibilities with respect to open-source software. Those responsibilities would include:
Perform outreach and engagement to bolster the security of open-source software,
Support Federal efforts to strengthen the security of open-source software,
Coordinate, as appropriate, with non-Federal entities on efforts to ensure the long-term security of open-source software,
Serve as a public point of contact regarding the security of open-source software for non-Federal entities, including State, local, Tribal, and territorial partners, the private sector, international partners, open-source software organizations, and open-source software developers, and
Support Federal and non-Federal supply chain security efforts by encouraging efforts to bolster open-source security.
Paragraph (c)(2)(A) would require CISA to publicly publish a framework, incorporating government, industry, and open-source software community frameworks and best practices, for assessing the risk of open-source software components, including direct and indirect open source software dependencies. The framework would address:
The security properties of code in a given open-source software component, such as whether the code is written in a memory-safe programming language,
The security practices of development, build, and release processes of a given open-source software component, such as the use of multi-factor authentication by maintainers and cryptographic signing of releases,
The number and severity of publicly known, unpatched vulnerabilities in a given open-source software component,
The breadth of deployment of a given open-source software component,
The level of risk associated with where a given open-source software component is integrated or deployed, such as whether the component operates on a network boundary or in a privileged location, and
The health of the community for a given open-source software component, including, where applicable, the level of current and historical investment and maintenance in the open source software component, such as the number and activity of individual maintainers.
Once the framework is established paragraph (c)(2)(E) would require CISA to conduct a periodic assessment of open-source software components used directly or indirectly by Federal agencies. CISA would be expected to automate the assessment process. The assessment would establish set of ranked lists of the open-source components covering such areas as criticality, level of risk, or usage of the components.
Paragraph (c)(2)(I) would require CISA to conduct a study looking at the potential for conducting similar assessments to those outlined in (D) for critical infrastructure entities. CISA would be authorized to conduct a limited pilot on a voluntary basis for conducting assessments of private sector entities.
Open-Source Software Guidance
Section 5(b) of the bill would require CISA to produce guidance “on the responsibilities of the chief information officer at each covered agency regarding open-source software”. That guidance would address:
How chief information officers should enable, rather than inhibit, the secure usage of open-source software at each covered agency,
Any relevant updates to the Memorandum M–16–21 issued by the Office of Management and Budget on August 8, 2016, entitled, “Federal Source Code Policy: Achieving Efficiency, Transparency, and Innovation through Reusable and Open Source Software”, and
How covered agencies may contribute publicly to open-source software that the covered agency uses, including how chief information officers should encourage those contributions.
The guidance would also address how chief information officers at each covered agency should, considering industry and open-source software community best practices to:
Manage and reduce risks of using open-source software, and
Guide contributing to and releasing open-source software.
Section 5(c) of the bill would require the National Cyber Director, CISA and the Government Services Administration to select agencies to establish a pilot open-source function at the covered agency. That function will:
Support the secure usage of open-source software at the covered agency,
Develop policies and processes for contributions to and releases of open-source software at the covered agency, in consultation, as appropriate, with the Offices of General Counsel and Procurement of the covered agency,
Interface with the open-source software community, and
Manage and reduce risks of consuming open-source software at the covered agency.
Broader Open-Source Responsibilities
Section 5(e) amends 44 USC 3554(b) adding a new paragraph (9) adding to the information security program requirements at federal agencies the requirement to include “plans and procedures to ensure the secure usage and development of software, including open source software.”
Changes from S 4913
While most of the changes from last session’s bill were relatively minor wording changes, there was one significant change in the §2(c)(2)(I) Critical Infrastructure Assessment Study and Pilot. Clause (ii) was rewritten to add a subclause (II) that would terminate the pilot after two years.
Moving Forward
Peters is the Chair of the Senate Homeland Security and Governmental Affairs Committee to which this bill was assigned for consideration. This should ensure that the Committee once again takes up the bill. It will likely pass, as it did last session, with strong bipartisan support. The bill did not make it to the floor of the Senate last session, but that was, at least in part, due to its relatively late introduction. It is unlikely that this legislation would be taken up under regular order due to time and politics constraints. So, it would have to be considered under the unanimous consent process or added to some must pass bill as an amendment. Both options face political constraints that would have nothing to do with the merits or general support of the bill.
Commentary
The unique problem with open-source software is not that it is ‘poorly written' (the multiple vulnerabilities from poor coding practices are found in software from ‘closed sources’ as well as open-sourced software). No, the problem with many of the smaller libraries that are source for so many vulnerabilities, is that there is little support for correcting the problems when they are identified.
What might be more helpful is that if CISA were given the authority to fund internships with open-source creators of selected critical open-source components that have minimal support available. Identifying the critical components will become easier as SBOM requirements become more common but identifying the authors that would be willing to accept government sponsored interns might be a challenge. Oversight of such internships would also be a challenge. But this could provide immediate support for challenged authors, as well as broadening the scope of those familiar with the details of the critical software.