What Does the Order Say on Software Supply Chain Security?
The order does several important things related to software supply chain security. It requires the National Institute of Standards and Technology to develop baseline security standards for software used by government agencies (though NIST is looking at whether existing guidance may cover some of the new rules).
Those standards are required to encompass secure software development environments, including such actions as: using administratively separate build environments; auditing trust relationships; establishing multifactor, risk-based authentication and conditional access across the enterprise; documenting and minimizing dependencies on enterprise products that are part of the environments used to develop, build and edit software; employing encryption for data; and monitoring operations and alerts and responding to attempted and actual cyber incidents.
Other controls include “employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at a minimum prior to product, version, or update release,” according to the order. Software companies doing business with the government will also be required to maintain “accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes, and performing audits and enforcement of these controls on a recurring basis.”
RELATED: How can agencies best handle IT supply chain cybersecurity threats?
The order also requires software developers to maintain greater visibility into their software, including a software bill of materials, and make security data publicly available.
Sometime over the summer, the secretary of the Department of Homeland Security, acting through the director of the Cybersecurity and Infrastructure Security Agency and in consultation with the secretary of the Department of Commerce, acting through the director of NIST, will be required to identify and make available to agencies a list of categories of software and software products in use or in the acquisition process that meet the definition of “critical software.”
The government will also then publish guidance outlining security measures for critical software, including applying practices of least privilege, network segmentation and proper configuration.
Within a year, various agencies are required to make a recommendation to the Federal Acquisition Regulatory Council on contract language changes that would require software companies doing business with the government to comply with all of the new rules.
DIVE DEEPER: What role will the new national cyber director play?
How IT Leaders Can make Their Software More Secure
Those rules represent a lot of new mandates for government software suppliers. One could argue that those companies should have known such rules were coming in the wake of the SolarWinds attack and should have been preparing for them. However, it is a lot, and it is also a lot for government IT leaders and their teams to keep track of.
These rules will need to be continuously monitored, and best practices will need be revamped and updated. The issue is that many agencies remain understaffed and under-resourced when it comes to cybersecurity expertise. Agencies need to invest in hiring staff skilled in software development and implementation and those who can monitor software for compliance with security controls.
All of this will take time and funding, and it will require much closer consultation between agencies and their private sector software partners.
Federal IT leaders and their teams need to take this topic seriously and work closely with NIST and CISA on how they can enhance software supply chain security. At the same time, rushing to get to the fire is not always the best answer.
Agencies need to take time to make sure they are properly educating staff about software security and finding ways to communicate better on the topic both internally and externally.
Unfortunately, there is no single repository or forum in which federal agencies and software suppliers can track information on this topic and collaborate openly and securely. As a result, all of the players involved need to stay vigilant and give software supply chain security, and cybersecurity in general, the proper attention and funding it deserves.
Software supply chain issues won’t be addressed in a month or maybe even in a year. Leaders need to set realistic timetables and goals. However, the work needs to start in earnest now, before another attack like the SolarWinds attack washes over the government.
This article is part of FedTech’s CapITal blog series. Please join the discussion on Twitter by using the #FedIT hashtag.
