IE 11 Not Supported

For optimal browsing, we recommend Chrome, Firefox or Safari browsers.

Growth in Open Source Leaves Government Exposed to Vulnerabilities

The open source community is doing a poor job monitoring its software for security flaws, say experts.

Microsoft’s announcement Monday that it is acquiring massive open source platform GitHub for $7.5 billion is expected to have little impact on reducing the sharp rise in open source vulnerabilities and improving their time to discovery. That’s not good news for governments as they increasingly embrace open source.

“Microsoft’s acquisition will undoubtedly further improve the already good security of the GitHub platform. However, it won’t naturally change — for better or worse — the security of the open source projects itself (that use the platform). This is an area where the community, as a whole, needs to own security, not any corporation,” said Guy Podjarny, CEO of security firm Snyk.
The open source community may not be taking rigorous ownership of its own security, an issue governments need to consider as they pass policies to allow the use of open source technology in their programs, applications and on their websites. 

For example, 44 percent of open source maintainers surveyed acknowledged they never have conducted a security audit of their code, according to a 2017 State of Open Source Security report by Snyk. The report is based on interviews with more than 500 open source maintainers and data Snyk collected from 40,000 open source projects and scanning millions of GitHub repositories and packages on registries.

audit-code-and-security-expertise-graphic.jpg


[Source: Snyk]

Meanwhile, state and local governments are jumping onto open source for its ability to save software development time and overall costs, as well as potentially increase the capabilities and scope of the projects they may want to tackle. New Hampshire in 2012, for example, passed legislation that required state agencies to consider using open source software before purchasing commercially available software. Two years earlier, California officially permitted the use of Open Source Software (OSS) for application or software development, according to Manveer Bola, statewide technology policy chief for the California Department of Technology. 

How Bad is Bad?

Open source vulnerabilities in application libraries have risen sharply since 2012, soaring from less than 100,000 published vulnerabilities to approximately 900,000 in 2017. In Snyk’s test of over 430,000 sites, 77 percent were running at least one library with a known vulnerability, according to the report. 

open-source-vulnerabilities-by-year.jpg
      

[Source: Snyk]

The median time between introducing a vulnerability into an application library and when it is publicly disclosed is 2.53 years, according to the report. 

During that time, cyberattackers can take advantage of the situation and embed their malicious code into the library, gaining entry if a government agency imports that library into the development of an application. For attackers, being baked into the development of an application may be easier access than trying to bust into an application after it has already been created, say security experts.

“We believe hackers will continue to target vulnerable open source components as it requires less efforts and results in more reward for them,” said Rami Sass, CEO of security firm WhiteSource. “This is true for all verticals, including government agencies who are becoming heavily reliant on open source projects. Vulnerabilities found in popular open source projects are a prime suspect as it can 'produce' the highest number of targets.”

discovery-to-fix-chart.jpg
 [Source: Snyk]

Governments Weigh-In On Open Source Security Protections

The city and county of Honolulu primarily develops its own applications using major open source distributions, such as Linux, software development tools from GNU and languages like Node.js, said Mark Wong, CIO of Honolulu.

“Much of the software on repositories like GitHub are from sources we cannot verify, and we aren’t using open source business applications,” he said. “We do trust software from organizations like Google, Apache, Linux Foundation, MongoDB, Python, and OpenSSL. While there certainly are vulnerabilities with packages from these organizations, known vulnerabilities are reported directly to us in a timely fashion, and we don’t have to rely on release notes.”

Wong’s team regularly checks the releases on about 100 open source packages used in the city’s software development and that only one of these packages, protobuf, is from GitHub. With protobuf, Wong noted the GitHub page is linked directly from Google’s developer site and if Google can trust protobuf hosted on GitHub than he can too. As for Microsoft’s acquisition of GitHub, Wong does not believe it will “significantly impact the security of the site one way or another.”

The state of California has not discovered malicious code purposely built into open source code at its own department level, according to Bola. 

Each department is responsible for ensuring the open source software they use is compliant with software management licensing and security practices listed in the State Administrative Manual and Statewide Information Management Manual, which calls for system development life cycle and system developer testing, both of which touch on secure coding practices, he added. 

“We also know that several departments have additional departmentwide policies which cover secure code development,” said Bola. “As such, since it is state policy, we are hoping all entities are ensuring that open source code acquired from any library is tested and approved prior to incorporating into their applications.”

Getting the Word Out

Although cyberattackers have always exploited open source vulnerabilities, in the past 18 months they have ramped up the speed in reacting to public information on open source vulnerabilities, according to Sass. 

tell-users-chart.jpg


 [Source: Snyk]

Government agencies can take three steps to improve their open source security posture. One is to automate the open source management process, as well as listen to the open source community when it shares information to quickly remediate the vulnerability, he said.

However, “the problem is that most software teams are not able to learn from issues reported and fixed by the community as the information is spread across many repositories and websites across the Web, and most sources are not indexed properly,” explained Sass.

Sass suggests using software composition analysis tools for real-time security notifications and quality issues. And lastly, he advises raising the awareness of software engineers that they are the ones who will need to weigh the risks of using open source software before porting it over.

Honolulu, meanwhile, relies on a vulnerability monitoring service and its partnerships with agencies like the Department of Homeland Security for timely notifications. When a release note mentions a vulnerability, a patch has usually been developed, according to Wong. As a result, it’s faster for Honolulu’s IT team to compile things like OpenSSL from the authoritative source because the IT team can deploy an updated SSL release in less than 30 minutes after a vulnerability is noticed.

“This is one of the strongest arguments for building from source,” said Wong. “Having said that, if you don’t understand the code well enough to fix it, maybe you should think twice about using it.”