You are here

You are here

Will GitHub's dependency graph move the needle on app sec?

John P. Mello Jr. Freelance writer

Software developers are depending more and more on third-party code, or dependencies, when forging their applications. Rather than reinvent the wheel for tasks such as logging and authentication, developers often deploy open-source code. That can can create security problems for software writers, as the recent mammoth breach at credit services company Equifax illustrated.

The Equifax breach, which compromised sensitive information about roughly 143 million Americans, resulted from the use of a vulnerable Apache Struts component. The vulnerability had been discovered and patched by the Apache community, but Equifax's coders hadn't gotten around to upgrading the component.

Those kinds of missteps, and the wide use of dependencies, make dependencies a huge target for attackers, said Tim Jarrett, senior director of product marketing for Veracode. "It's easier to break into an application using a published vulnerability in a widely used component than to have to create a new way to exploit a vulnerability that only exists in one application," he said. "An application could have no weaknesses in its own code yet still be successfully attacked through a vulnerable dependency."

To make matters worse, the libraries that make up dependencies can do anything that the application using them can do. "Given the number of libraries used in the average application, the frequency of these vulnerabilities and the severity of these vulnerabilities, the situation is concerning," said Jeff Williams, CTO and co-founder of Contrast Security.

Recognizing the threat that dependencies pose to applications, GitHub has introduced a new tool, the dependency graph, that leverages GitHub's enormous collection of open-source data to help developers better manage dependencies. Developers working on GitHub can access the dependency graph from within their repositories and see all packages and applications to which they're connected, as well as those that are connected to them.

Will the dependency graph move the needle on application security?

Where GitHub got it right

Currently, the dependency graph supports only Ruby and JavaScript, with Python support on the way. "That will limit it, since a lot of applications are being developed in Java and .Net, and that's where a lot of third-party components are written," said Ken Prole, chief technology officer for Code Dx.

In addition to tracking dependencies, GitHub promises to add security alerts to the dependency graph. Through the tool, developers will be able to track when dependencies are associated with publicly known security vulnerabilities. They'll be notified when a vulnerability is detected and, in some cases, receive suggestions for security fixes from the GitHub community.

The dependency graph can be a valuable tool for addressing vulnerabilities found in nested dependencies. "In most cases, it's not a simple matter to understand the vulnerabilities that affect your application, since your application is dependent on hundreds of packages, which in turn use hundreds of packages, and so on," explained Manisha Sahasrabudhe, co-founder and vice president of product management at Shippable.

For example, imagine your application is dependent on packages A and B, which in turn depend on C and D, which depend on E and F. If a vulnerability is discovered in E, you probably wouldn't know it affects your application and would likely ignore it. "GitHub's dependency graph will help solve this problem by showing you all your nested dependencies and sending alerts when a vulnerability is discovered and a patch is available for all of them," Sahasrabudhe said.

The dependency graph can also help organizations move security closer to the beginning of the software development lifecycle. "As part of DevOps, there's this concept of shifting security left," explained Liz Rice, technology evangelist for Aqua.

"If you can push security as far as you can toward developers, it's a good thing, because you can catch problems earlier. Dependency graph can shift security very far left."
Liz Rice

"Tools such as dependency graph can help eliminate many app risks before they are put in production, with the net impact of reducing the application's attack surface," added Alok Shukla, senior director for product management at Imperva.

John Morello, CTO of Twistlock, cited a number of additional benefits of shifting security left. "Vulnerabilities discovered in development pose lower risk, are easier and faster to fix, and are much less costly to remediate than those found after deployment," he said.

"GitHub's dependency graph is a good addition to a developer's toolbox to help them find these problems as part of their normal workflows."
John Morello

Awareness doesn't equate to action

Developers are aware of the risks third-party components pose to their applications, but many do nothing about them. A new survey of 300 CTOs, CIOs, and developers by NodeSource, a Node.js company, and Sqreen, a maker of SaaS security monitoring and protection software, said as much. In taht study, 40% of developers said third-party modules posed the greatest risk to application security. But 40% of coders also admitted to not checking for third-party vulnerabilities in their own apps.

"A lot of times, components have vulnerabilities in them, and developers aren't kept aware of them," said Code Dx's Prole. "They'll pull in a dependency and just forget about it. They never go back to see if there have been any issues with it."

"Developers have so many demands on them to get releases out, they don't have time to think about checking vulnerabilities in dependencies."
Ken Prole

Even conscientious developers can be challenged by dependency problems. Not only do developers need to stay up to date on the components they're using, but in many cases those components have subcomponents with dependencies of their own.

According to GitHub, 75% of software projects on its platform use dependencies—and more than half of those use more than 10 dependencies.

Custom code concerns

While a powerful future may be in store for the dependency graph, at present its usefulness remains limited. "It's a great tool that will help a lot of developers," Contrast Security's Williams acknowledged, "but the dependency graph only points out vulnerabilities. It doesn't fix them. It's a smoke alarm, not a fire extinguisher."

And although in some cases you can simply replace vulnerable dependencies with updated versions, more often other aspects of the library have changed. That means developers must change the application, which means retesting and redeploying it—which is a significant amount of work.

Williams' company, which studied dependency use in thousands of applications, discovered that 89% of dependency code is never invoked by an application. "It's essentially dead code," he said. "If known vulnerabilities are in the unused library code, then organizations can spend a lot of time fixing imaginary security problems."

The overwhelming number of vulnerabilities "are in the custom code of an application," he said. "Organizations should not simply secure their components and forget about their custom code, because that is where they are most vulnerable."

The dependency graph's beneficiaries: Containers and AI

Container security could also benefit potentially from GitHub's tool. For example, a future version of the dependency graph could check container images for vulnerabilities. "We recommend setting up deployment pipelines to rebuild Docker images whenever any of the underlying images change," Shippable's Sahasrabudhe explained.

"Dependency graph could ensure that application Docker images are always updated when a dependency is patched due to a vulnerability. Such a tool will lead to more transparency about what is included in each Docker image, which will help container adoption."
Manisha Sahasrabudhe

As the dependency graph evolves, its utility could be enhanced with the use of artificial intelligence. With AI, dependencies and vulnerabilities could be identified, for instance, but so could whether an application actually uses a dependency or even if it uses vulnerable code within a dependency.

"I can imagine an AI system which can walk through the dependency graph of your application, find information about vulnerabilities that could affect you, and intelligently determine the vulnerabilities that need to be addressed immediately," Sahasrabudhe said. "As your application evolves, this system would adapt accordingly and notify you daily about the actions you need to take to keep your application secure."

Next steps: Work to be done

Tracking software dependencies and understanding known security vulnerabilities in consumed dependencies definitely helped address security assurance risk.  "We have observed continued growth in the use open source dependencies and ensuring the security of systems should include both in-house developed code and the dependencies which are consumed," said Alex Hoole, manager of Software Security Research at Micro Focus.

However, when GitHub's security alerts become available as a feature, developers will potentially have to refactor their code to integrate patched versions of the affected dependencies. The refactored code will still need to be evaluated for vulnerabilities potentially introduced by the refactoring process itself. 

And if you are relying on security notifications to know when to patch your dependencies, you should also know the process that leads to the notifications. 

Hoole suggests you ask some specific questions, such as the following:

  • How many of our dependencies have disclosed vulnerabilities (CVEs) and why? 
  • Have all dependencies been analyzed for security assurance? 
  • When new vulnerability types are discovered how long does it take for dependencies to be assessed for potential risk?
  • Do all identified vulnerabilities lead to a disclosed CVE?
  • Can the combination of dependencies introduce a vulnerability?

"Ultimately, we are moving in a positive direction but there is a lot of work left to do.”
—Alex Hoole

Keep learning

Read more articles about: SecurityApplication Security