HR 3286 Introduce
Open-Source Software Security
Last month, Rep Green (R,TN) introduced HR 3286, 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. The bill is similar to S 917 that was introduced earlier this year.
The Senate bill has been favorably reported by the Senate Homeland Security and Governmental Affairs Committee with an amendment to the language of the bill. HR 3286 incorporates most of the changes adopted by the Committee in the Senate, but there are still differences between the two bills.
Differences
The largest structural difference between the two bills is that two sections have been removed from the Senate language:
Section 2 – Findings, an
Section 5 - Open Source Software Guidance
While §2 laid out the reasons that this legislation is necessary, it’s absence does nothing to diminish the remaining provisions of the bill. Section 5 would have required CISA to produce a guidance document for government CISO’s “on the responsibilities of the chief information officer at each covered agency regarding open-source software”. It’s absence does not stop CISA from producing such guidelines, it merely takes Congress out of the loop on what should be considered in such guidance.
Most of the remaining differences are editorial or stylistic changes that have little to do with the actual provisions of the bill. There is one small revision (the addition of a single word) in the House version that has special significance. In the new §2220F(c)(2)(E)(i) outlining the requirements for CISA’s assessment of open-source software, the House authors added the word ‘each’ in the opening phrase:
“perform an assessment of each open source software component used directly or indirectly by Federal agencies…”
That single word reinforces the requirement for CISA to examine every piece of open-source software currently in use by the federal government. This would probably extend to each of the versions currently in use by agencies, if CISA were interested in, an had the resources for, complying with the intent the legislation.
The final area of significant change is the essentially re-written requirements to report to Congress found in the new §2220F(c)(4). Fortunately, those changes will have little effect on anyone outside of CISA.
Definitions
Section 2(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 a 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.
Moving Forward
Green and all three of his cosponsors are members of the House Homeland Security Committee to which this bill was assigned for consideration. This means that there may be sufficient influence to see the bill considered in Committee. I see nothing in this bill that would engender any organized opposition to the proposed legislation. I suspect that it would see sufficient bipartisan support in Committee to allow it to be considered by the full House under the suspension of the rules process.
Commentary
This bill was assigned to the House Oversight and Accountability Committee for secondary consideration. It is unlikely that the bill will be considered there because of other priorities in this session. Normally, such secondary assignments mean that the (relatively for the bill) minor committee does not bother holding hearings. The two committee Chairs reach an agreement to protect the oversight rights of the secondary committee and that agreement is documented in the primary committee’s report on the bill. It will be interesting to see how the Oversight Committee Chair’s singular focus on the ‘weaponized government’ issue affects his relations with other Chairs and his ability to reach such agreements.