Dependency Management — 1

Dec 20, 2018 · 3 min read

We want to and are creating fantastic tools that accomplish various tasks, for which our apps no matter their tongue (language c++, JS etc.) or technology use various packages or tools made by other developers from various sources we trust (sometimes arbitrary …simply put dont ) this is very true in case of startups or tight schedule features/products. Maximum priority is given to delivery of the product ( sometimes security ) but we tend to offload securing the dependencies to their sources overlooking the fact that we not only inherit their feature but also their vulnerabilities.

Enter OWASP A9-Using Components with Known Vulnerabilities this is by far the easiest and the most prevalent strategy to exploit application and can be used from simple reconnaissance to a root shell , the end result of using components from third parties that have a established vulnerability in them and there are plenty across every technology in use. A little stat shows most of the breaches are caused because of using components that had a vulnerability in them.

Image for post
Image for post

Exploits are plenty:

We all at this point know about a few breaches over the last year alone.. I am gonna focus strictly on the technical aspects hence no names. A company vulnerable.corp say is a major java-web user and they had a bunch of vulnerable dependencies. A malicious agent lets call her Eve uses various tools to find out they are using Apache struts 2 (finding this is beginner level stuff). Given that mere googling shows a list of vulnerabilities

All that remains is to craft an exploit but Eve is new to java and does not have any clue what a struts is, from the CVE it is clear that this is a mature and old vulnerability Eve seldom needs the knowledge of the internals to craft an exploit. Eve googles or refers to git or Exploits database to fetch a exploit and readme to use it. Eve then uses the exploit with vulnerable.corp to get an Root shell. Voila ! a root shell in under 4 hours of work PWNED!(mostly takes more effort but for a few cases surprisingly lesser depends on the case)

Image for post
Image for post

Protection :

As serious and prevalent as this vulnerability category is its a bit easier to protect against proactively:

  1. Keep all the dependencies updated (duh!)
  2. Before using a dependency check if it has any known vulnerabilities is a good place to start
  3. Keep track or use a tool to keep track of Zero day exploits and take precautions for your product.
  4. Continuously scan your repositories using tools that specialize in this eg. flexera ,, blackduck etc. and fix any find immediately
  5. Spread the knowledge to developers and make a clear process in place for using dependencies.
  6. And finally when in doubt.. always ask the security team.

stay safe ….

will cover more ways to keep track of dependencies through solid CI/CD processes in Dependency management — 2


Software Engineering meets Cybersecurity

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store