U.S. government seeks open-source software security advice

The Cybersecurity and Infrastructure Security Agency (CISA), the Office of the National Cyber Director (ONCD), the National Science Foundation (NSF), the Defense Advanced Research Projects Agency (DARPA), and the Office of Management and Budget (OMB) are looking for some additional insights into how the U.S. government should prioritize its efforts to secure open-source software.

The agencies have jointly published a request for information (RFI), due by October 9^th, as part of an ongoing effort to improve the security of open-source software that, in one way or another, finds its way into nearly every application.

In theory, at least, the U.S. government should be making available coding and financial resources to the maintainers of open-source software as part of an effort to defend federal agencies that, much like every other enterprise, have become heavily dependent on open-source software. The trouble is that so long as software is written by humans, there is always going to be a potential cybersecurity issue. People make mistakes. At the same time, vulnerabilities in code that are unknown today will most certainly be discovered tomorrow. Few maintainers of open-source software projects have the resources available to create a patch that can then be instantly shared with all the entities using that software.

In fact, in many cases, the maintainers might not even consider proving that patch to be an especially high priority. Unless someone is paying that maintainer to work on that project, it’s often just a labor of love. The maintainers of that software didn’t ask a federal agency or enterprise IT organization to use that software so it’s not necessarily their job to drop everything to create a patch for a zero-day vulnerability.

Arguably, the organizations that are benefiting from using that software should be prepared to make resources available to address such an issue. Those resources can be provided either by the organizations themselves or the vendor that may have provided access to a curated instance of an open-source software package that they commercially support.

Of course, none of that means anything if no one can find where the vulnerable software is running. In the wake of the Log4j zero-day vulnerability, many cybersecurity teams and application developers spent months working together, looking for instances that cybercriminals now had instructions on how to exploit.

Ideally, there should, in the name of national security, be some kind of SWAT team to orchestrate the building of a patch whenever necessary and, just as importantly, provide the expertise needed to discover instances of affected software. The Open Source Security Foundation (OpenSSF) has been working to provide these types of capabilities, but the effort that would be required in the event of another major discovery of a zero-day vulnerability exceeds its available resources.

Government agencies are not known for their agility, so it might be a few months before the advice being sought turns into an actual plan, but cybersecurity professionals should take advantage of a unique opportunity to weigh in on an issue that affects them most. After all, no matter what the root cause of a breach is, the proverbial buck always stops with the cybersecurity team tasked with cleaning up the ensuing cybersecurity mess.