The Ponemon Institute’s 2018 study of enterprise security and vulnerability found that 57 percent of the organizations queried claimed a data breach had occurred in the past two years because of their failure to apply an available patch they didn’t know about. Even worse, another 34 percent said they knew they were vulnerable and that a patch was available—but they didn’t apply it.

As it turns out, it appears that business enterprises are not the only ones remiss. From all accounts, the U.S. government has its own patch management issues. The continued presence of open-source software in the public sector plays a significant role here, as does the fact that numerous governmental agencies at all levels are hamstrung by legacy IT infrastructure.

The vulnerability time-bomb

According to NextGov, it usually takes about three days for word of a software program’s significant flaws to reach the community of malicious online actors—and for those hackers to figure out how to take advantage of these vulnerabilities.

For a government agency, three days isn’t much time, considering the red tape and bureaucracy that lies between knowledge and action. The reality is, if agency security staffs aren’t working fast enough in their search to find and quarantine or eradicate the flaw, chances are high that the bad guys can do some damage.

Security holes in government departments

Worse, it turns out that federal agencies—including the Departments of Defense, Treasury, and Justice, as well as the Nuclear Regulatory Commission and the Office of Personnel Management—are aware, at least to some extent, of existing security flaws.

Scorecards mandated by the Federal IT Acquisition Reform Act indicating agencies’ levels of cybersecurity and general tech capabilities have shown dismal grades in recent years: Most agencies scored F, F+ or D for multiple metrics on their two 2018 evaluations. The DoD, whose responsibilities include handling some of the most sensitive information in the whole government ecosystem, fares particularly poorly in such assessments, as its own Inspector General’s office confirmed in a December 2018 report.

Bob Metzger, an attorney with the government cybersecurity-focused law firm RJO, said in an interview with NextGov that patch management is a specific part of this problem. Agencies don’t necessarily have any clear process for assessing and patching software. Furthermore, department officials’ knowledge gaps regarding their own technology effectively handicaps any patch management measures they do have.

“I would be very surprised if even a small percentage of federal agencies today had a usable inventory of the open-source components in the software that they rely upon for their critical agency functions,” Metzger explained.

Dealing with open-source concerns

In other words, programs built with at least some open-source components—whether based in long-established languages such as Java or newer code such as Python—are everywhere in the global IT ecosystem, including the U.S. government. It’s unrealistic for any such agency—or, for that matter, any private-sector organization—to completely eradicate the use of such code. It is equally impossible, of course, to ignore the security risks it can pose.

According to Sonatype’s 2019 State of the Software Supply Chain report, 25 percent of all public- and private-sector developers said they underwent a breach caused by flaws in open-source components during 2018. The study also found that such breaches rose in frequency by 75 percent between 2014 and 2018.

What this all points to is simple: Any government agency or business looking to establish reasonable control over risk associated with open-source software and code must set up a patch management strategy immediately. It should include update support, not only for standards such as Microsoft Windows and Apple iOS, but also platforms from third-party software vendors and open-source developers—everything from Chrome, Linux, Java, and Python to individual programs such as Firefox, VLC, Adobe Flash and many more.