DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Software Design and Architecture
  3. Security
  4. These Silent Fixes Are Silent Killers in Open-Source Security

These Silent Fixes Are Silent Killers in Open-Source Security

Learn more about the silent killers in your open-source code.

Laura Paine user avatar by
Laura Paine
·
Dec. 18, 18 · News
Like (1)
Save
Tweet
Share
5.78K Views

Join the DZone community and get the full member experience.

Join For Free

When it comes to open-source software, it’s natural for development and security leaders to want to know that the code they’re using is secure. Historically, they’ve relied on traditional software composition analysis solutions and the National Vulnerability Database to mine for open-source issues. Yet, there is a little-discussed fact that open source begets open source. We know that developers use open source libraries to speed up the development process by adding ready-made functionality to their code. The libraries that they select and use are called direct dependencies, and often times, those direct dependencies have dependencies of their own.

Just like any other piece of software, open source libraries often rely on other open source libraries to achieve the desired functionality and goal. When developers choose an open source library, they may not be aware of the indirect dependencies they are stitching into their software. At Veracode, we’ve seen anywhere from two to more than 10 levels of libraries being called on, one after the other. Once you start assessing each level of the library, the volume of vulnerabilities can skyrocket beyond your team’s ability to manage them.

Using software composition analysis is an amazing first step to solving some of this open-source risk, but what happens when an open source library contributor fixes a security vulnerability and doesn’t tell anyone? Or, what about the time between submission and publication; with an organization like the National Vulnerability Database, is that too long to wait?

A Database Is Only as Good as the Data it Captures

The National Vulnerability Database (NVD), upon which most traditional SCA solutions rely, is a robust and widely-used source of vulnerability data available today, cataloging tens of thousands of vulnerabilities across all application types and open source libraries. While it is no doubt a valuable and necessary library of flaws and fixes, through no fault of its own, the organization is unable to keep pace with the volume of vulnerabilities disclosed and updated on a daily basis. Open source library vulnerabilities get stuck in a logjam behind everything else that is disclosed.

It’s important to note that vulnerabilities only make it into the database if a software developer or independent security research submits them. It’s common for a vulnerability to be fixed, but never disclosed or submitted to the NVD. For example, the Apache Struts Remote Code Execution vulnerability – the same type that led to the Equifax breach in 2017 — was disclosed to the public in August 2018 but was patched in April of that same year.

Four months is plenty of time for malicious actors looking to take advantage of vulnerable software. If they were monitoring the commit logs of the library, they would have been aware of it before organizations could update to the latest version of the component.

Machine Learning and Natural Language Close the Gap

Machine learning technology has the ability to automate the identification of potential security vulnerabilities from commit messages and bug reports. In open-source projects, bugs are typically tracked with issue trackers, and code changes are merged in the form of commits to source control repositories. If an organization is able to monitor all of these repositories, and review each new bug issue and commit message, they could identify potential vulnerabilities. However, there are tens of thousands of open-source repositories, with hundreds of thousands of bug tracking issues and commit messages to comb through, with new ones hitting every day.

Natural language processing and real machine learning can identify potential vulnerabilities in open source libraries with a high level of accuracy. By analyzing the patterns found in past commit messages and bug-tracking issues using machine learning, our model can identify when new commits or bug issues resemble a silent fix of a potential vulnerability. These potential vulnerabilities are then raised to security researchers.

These silent fixes can be a silent killer for your data protection.

Modern Software Composition Analysis Designed for Modern Application Development

We have developed our own database that includes all of the open-source vulnerabilities in the NVD, as well as our own list of vulnerabilities in open source libraries that have not yet been disclosed to the NVD. In many cases, the vulnerabilities we find and record have either not been disclosed yet and are, in the time, between patching and full public disclosure, or in some cases, there was never any intent to disclose the vulnerability and its fix. There is a third category we track, which are “Reserved CVEs.” We take the Reserved CVE IDs from the NVD and then find the vulnerabilities in the public repos, in order to give you a head start on the fix prior to full public disclosure.

To learn more about how to use these silent fixes to your advantage by putting your development team on an even playing field with attackers, download our free white paper.

Open source security Vulnerability Machine learning Library Database Software

Published at DZone with permission of Laura Paine, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Remote Debugging Dangers and Pitfalls
  • Implementing Infinite Scroll in jOOQ
  • Top 5 Node.js REST API Frameworks
  • DevSecOps Benefits and Challenges

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: