Patch delays create a ‘window of opportunity’ for observant attackers
Security bugs in open source packages can take a long time to be fixed, are often bundled with non-security and breaking changes, and can go unnoticed to client projects, a study by researchers at North Carolina State University shows.
The study, which was conducted on thousands of free and open source packages across seven ecosystems, highlights some of the shortcomings in the security practices of the open source software community.
Late, opaque, and breaking security updates
The researchers used the Snyk and NVD vulnerability databases to track 4,377 security advisories and the changes made to their corresponding repositories in platforms such as NPM, PIP, and NuGet.
The study focused on the delay between developing the security fix and releasing it on the repository, the documentation of the fix in the repository, the size and characteristics of security releases, and the time it takes for an advisory to be published on Snyk or NVD.
The researchers found that the median security release comes within four days of the corresponding fix. But in some cases, security releases are delayed up to 20 days. “Such a delay creates a window of opportunity for the observant attackers, who will be informed of the vulnerability when a fix is still not available to the client projects,” the researchers warn.
While most open source packages documented their security fixes, only 39% explicitly mentioned the security implications of the fixes. “The lack of proper documentation may result in client projects remaining unaware of the available security fixes,” the researchers write.
RECOMMENDED Poisoned pipelines: Security researcher explores attack methods in CI environments
In some cases, the researchers found, maintainers bundle security fixes with unrelated functional changes, which can lead to backward incompatibility and implementation complications for client projects.
“Our analysis suggests that open source packages do not follow the recommendation of issuing separate releases for security fixes,” the researchers write.
Finally, the researchers observed that sometimes, there is a considerable lag between a security release on the repository and an advisory publication in a vulnerability database. This can result in client projects receiving delayed notification of the vulnerabilities.
“Such a delay further expands the window of opportunity for the attackers… as client projects may still remain unaware of the known vulnerabilities and the available security releases,” the researchers write.
New approach needed
To improve the security of open source software, the researchers recommend that package maintainers keep security fixes private until their release. Sometimes, commit messages regarding security issues are publicly available and easy to spot even before the fix is released, which can lead to the discovery of the unpatched bug by unwanted parties.
The researchers suggest that project maintainers create a private fork for the security release and only make it publicly visible at the time of the next release.
Read more of the latest infosec research news from around the world
The researchers also recommend using labels, metadata, and headers to mark security releases. This will make it easier for client projects and users of the package to spot security releases even if there’s a lag until the advisory is published on a vulnerability database.
“A standardized process would make package managers identify security releases automatically and notify the client projects during the clients’ next developmental builds,” they said.
The study also suggests the establishment of metrics to measure the conformity of open source packages to security practices. On the one hand, this will help client projects have better visibility into the reliability of their dependencies, and on the other hand, it will encourage package maintainers to adopt sound security practices.
“The reliance on open source packages in modern software development makes the client projects’ security health to be directly correlated with the security health of their dependency packages. Therefore, projects should select dependencies keeping a package’s security practices in mind,” the researchers write.
YOU MIGHT ALSO LIKE New tool can uncover redacted, pixelated text to reveal sensitive data
