Back in 2016, the White House officially promoted open source software in the federal government and beyond. The Office of Management and Budget (OMB) issued memorandum M-16-21 then, which required that all federal agencies open all new custom code for reuse by all other agencies and release 20% or more of any new custom code as free and open source.
Things have changed, but not the importance of open source software in government and critical infrastructure.
It is risk tolerance, which is never high in government, that has diminished greatly.
At the same time, open source software is increasingly associated with risk, if only because it has become so successful. It’s a huge attack surface in the middle of a seemingly permanent and escalating cyberwar, a cold war that never ended, or what is more commonly seen now as fifth-generation warfare.
It’s logical for government to step in to try to reduce that risk. Since the Apache Log4j/Log4shell vulnerability (Base CVSS score of 10) became public in December 2021, those big wheels have started to turn.
“There was a pretty big government response”
A critical vulnerability in the widely used Java logging tool (Log4j, specifically a Log4j 2 dependency, Log4shell) turned out to have been exploitable for about a decade, giving potential attackers “easy access to internal networks,” according to The Guardian. (It even touched WordPress, through Openverse, but was quickly handled as Chloe Bringmann later reported.)
Often described as the most serious vulnerability in a decade (if not all time), the US government response it motivated was recently summarized in The Washington Post. The Cybersecurity and Infrastructure Security Agency (CISA) led that response and will be leading new initiatives regarding open source in the near future.
Initially, “CISA briefed industry leaders, issued an emergency order for federal agencies to patch the issue and jointly published an alert with the FBI, National Security Agency and governments around the world.”
After that, all attention turned to future risk mitigation.
Like CISA in the US, the Canadian Centre for Cyber Security already distributes a vague and clumsy “WordPress security advisory” from time to time. Expect it to improve — there’s a lot of money and jobs for it in the federal pipeline.
Who shows up when decisions are being made?
In January this year, the Federal Trade Commission (FTC) warned companies to remediate the Log4shell flaw or face potential legal action. And the White House brought in leaders from major tech companies to discuss what might be done about widely used and under-maintained open source software. Only three organizations represented open source at that meeting, including the Open Source Security Foundation, a project of the Linux Foundation.
WordPress was not publicly represented in these proceedings or any that have followed. In January, Lesley Sim and others in the WordPress community asked, “Who represents our open source commons?” And the question keeps coming up. 🦗
Tech Security Experts and Foreign Policy Interests Converge on Software Supply Chains
The Senate Homeland Security and Governmental Affairs Committee held a hearing on Log4Shell and open source security in February. The speakers involved, the discussion that took place, and subsequent legislative development indicate federal funding and involvement in open source is coming. It’s just a matter of when and how much. GovTech did a nice summary of the event, but there are some things on the speakers’ prepared statements worth singling out. The Q&A is also worth watching.
David Nalley, Apache Software Foundation
David Nalley, President of the Apache Software Foundation, was the first to speak. The words “non-profit,” “charity,” and “contributors” figured early and prominently in Nalley’s brief statement. (Later “free riders” came up in the Q&A.) He emphasized a need for government investment in software supply chain security and the problem of getting updates out to vulnerable systems.
Brad Arkin, Cisco Systems
Brad Arkin, Senior Vice President, Chief Security and Trust Officer for Cisco Systems, also emphasized the need to be able to see the maintenance status of all software in use and make rapid upgrades — without overly focusing on Log4shell or regarding open source as being especially risky. Architecting systems with the “necessary separation inside” them to limit any damage and “providing transparency about
software components … through a software bill of materials (SBOM)” capped off his recommendations.
A “software bill of materials” (SBOM) has emerged as a key building block in software security and software supply chain risk management. An SBOM is a nested inventory, a list of ingredients that make up software components. The SBOM work has advanced since 2018 as a collaborative community effort, driven by National Telecommunications and Information Administration’s (NTIA) multistakeholder process.
CISA <https://www.cisa.gov/sbom>
Jen Miller-Osborn, Palo Alto Networks
Jen Miller-Osborn, Deputy Director of Threat Intelligence at Palo Alto Networks, went into greater technical detail with similar recommendations for containment, SBOMS, zero trust network architecture, etc. One item of note to software engineering teams stressed the value of Development Security Operations (DevSecOps):
Impressive work is already being done in this arena, but the community would be
<https://www.hsgac.senate.gov/imo/media/doc/Testimony-Miller-Osborn-2022-02-08.pdf>
well-served by increasing adoption of existing development tools to control access to open source components. These tools can scan all of the open source packages for both integrity and security before they are approved and allowed for engineering teams to use in products. Our recently released State of Cloud Security Report 2022, which surveyed over 3,000 IT professionals, found that organizations with tightly integrated DevSecOps principles were more than seven times likely to have strong or very strong security posture. They were also more than nine times more likely to have low levels of security friction.
Trey Herr, The Atlantic Council
Dr. Trey Herr, Director of the Cyber Statecraft Initiative at the Atlantic Council, was the last to speak. An academic and lobbyist, he was the only member of the panel not from the tech industry. Notably, the Atlantic Council promotes Atlanticism and has historic ties to NATO as an advocate for NATO interests. Dr. Herr took a slightly more alarmist view of open source as especially risk-prone. In his very goal-oriented, politically savvy statements, he called for DHS through CISA to fund and directly involve itself in the open source community:
This office should further encourage collaboration among the United States and allies in supporting the security of open source projects identified as critical by the office and act as a community liaison/security evangelist for the open-source community across the federal government.
<https://www.hsgac.senate.gov/imo/media/doc/Testimony-Herr-2022-02-08.pdf>
Further, “Open-source security should be part of mainstream supply chain security policymaking, and this office would be charged with supporting those efforts while acting as the single point of contact for external stakeholders.”
Deep Pockets Ready to Spend
Herr also pointed to:
…a proposed amendment to HR 4521, the America COMPETES Act of 2022, that would authorize the creation of a set of Critical Technology Security Centers inside of DHS [through CISA], including one focused specifically on open-source security.
<https://www.hsgac.senate.gov/imo/media/doc/Testimony-Herr-2022-02-08.pdf>
He then urged the Senators present to support this legislation “when it reaches the Senate, with the understanding that a substantial portion of moneys appropriated for these centers, on the order of $20 to $30 million a year, is dedicated to this open-source mission.”
In subsequent years, Herr predicted hundreds of millions would be spent on open source security by the federal government — all with the goal of:
…focusing on secure developer tools and “foundational” infrastructure for the open-source ecosystem, to incentivize rebuilding codebases in memory-safe languages, to support audits and volunteer labor to identify and patch vulnerabilities, and to support efforts to drive security talent into this space and towards the most impactful libraries and packages in open source.
In May, a second Open Source Software Security Summit was held in Washington, DC when “the Linux Foundation and OpenSSF gathered a cross-section of open source developer and commercial ecosystem representatives along with leaders and experts from key U.S. federal agencies.” Their goal was to build a mobilization plan — “a consensus on high-impact actions to take to improve the resiliency and security of open source software.” They came up with 10 areas of focus to improve OSS security and called for immediate funding from the tech industry in the ballpark of USD 150 million.
The Securing Open Source Software Act
In late September, Senators Gary Peters (D-Mich.) and Republican Rob Portman (R-Ohio) introduced legislation that directs CISA to:
- “Hire open-source experts.”
- “Publish a framework on open-source code risk” within a year and then regularly “perform an assessment of open-source code components that federal agencies commonly use.”
- Study, within two years, whether their risk assessment framework “could be used in critical infrastructure outside the government and potentially work with one or more critical infrastructure sectors to voluntarily test the idea.”
The Washington Post noted, “Other agencies would have roles as well, such as the Office of Management and Budget publishing guidance to federal chief information officers on the secure use of open-source software.”
Open Source Software as Public Infrastructure
Trey Herr was very positive about the Peters-Portman Act, saying:
“This important legislation will, for the first time ever, codify open source software as public infrastructure. If signed into law, it would serve as a historic step for wider federal support for the health and security of open source software.
While it may not be possible to rush through Congress before it’s out of session this year, it seems very likely the Act will drive greater self-regulation in open source — and bring in new government requirements to comply with. Parallel developments are happening in Europe where investment in open source as a public good has advocates arguing it leads to nearly a hundredfold return. Opportunities will surely emerge from new sources of funding and jobs for open source, but national and regional geopolitics may complicate the nature of contribution within truly global and international projects.
