facebook noscript

How to Avoid Using Components with Known Vulnerabilities

November 27, 2018
engineering-default

Imagine that a local library has hired you to help with the development of a web service to expose its library catalog (which, in essence, is an SQL database) on the Internet. Nothing fancy required — a simple REST API will do the job. It shouldn't be too difficult for a seasoned Java developer like yourself, now should it?

weak-link-2-2-2

Giving it some thought, you're most likely not the first to have such a task at hand. You start looking for an existing solution, and, after a short while, you stumble upon Spring Data REST. Studying its documentation confirms your choice; this piece of software turns out to be exactly what you are looking for.

Rolling up your sleeves, you start working on the application, and, thanks to your discovery, finish it in no time. Feeling proud of yourself, you release the app in production. A job well done!

However, in a few weeks' time, your client at the local library calls you to complain about somebody from the outside who managed to drop the database through the application you developed. You scratch your head and wonder: how this could happen?

Apparently, that particular version of Spring Data REST you used has a security vulnerability (namely, CVE-2017-8046) which allowed the attacker to execute arbitrary code on the machine running your app. Now, what if it was, say, a healthcare or financial system instead of a library catalog? The consequences would be potentially far more disastrous.

The worst data breaches impacting customers in recent history have resulted in hundreds of millions of dollars in settlements for the company, such as that of Anthem in 2017. The severity of these breaches and costly payouts that ensued serve as a reminder for companies of all sizes to take cybersecurity issues seriously.

Preventing Security Breaches

Unfortunately, situations like the Anthem breach are not uncommon. With open source software (OSS) on the rise, it’s hard to imagine a modern application that doesn’t contain at least one third-party component. Indeed, OSS makes our daily lives as developers easier, and while a lot of talented folks work on it, most of them simply aren’t security experts. This often leads to a wide variety of vulnerabilities ranging in severity, making software dependencies the largest attack surface. In fact, OWASP, an international non-profit organization dedicated to web application security.

To raise developer awareness and help alleviate the risks, OWASP maintains Dependency-Check – a solution which can be used to identify project dependencies and check them against the National Vulnerability Database (NVD). It then reports any known, publicly disclosed vulnerabilities it finds. The utility can be applied as a Maven plugin, too:

<build>
  <plugins>
    <plugin>
      <groupId>org.owasp</groupId>
      <artifactId>dependency-check-maven</artifactId>
      <version>3.3.2</version>
      <configuration>
        <!-- See CVSS ratings at https://nvd.nist.gov/vuln-metrics/cvss -->
        <failBuildOnCVSS>7</failBuildOnCVSS>
      </configuration>
      <executions>
        <execution>
          <phase>verify</phase>
          <goals>
            <goal>check</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

Having this minimal configuration in the example scenario at the beginning of this article would have failed the project build, most likely preventing the security breach from ever occurring by ensuring you, the developer, take notice of the existing vulnerability and act appropriately (in this case, updating the dependency to its latest version).

Dependency-Check, however, is not the only option available to developers. Alternatively, a service like Snyk can be used. In many ways, it is similar to Dependency-Check, but offers more features and better integration options. For instance, if you’re using GitHub, it can forbid merging a pull request if the changes introduce a new vulnerable dependency. Even more importantly, it suggests a remediation path.

Don't miss the next Developer Office Hours with our CTO

Join Us

Conclusion

Making sure your project has no high-risk vulnerabilities introduced by third-party components is very important and often overlooked by developers. Setting up an automated tool to check dependencies against a vulnerability database goes a long way in preventing security breaches from occurring.

Bohdan Khablenko Bohdan Khablenko

Software Engineer at VGS

Share

You Might also be interested in...

kubernetes

Kubernetes Multi-AZ deployments Using Pod Anti-Affinity

Max Lobur December 4, 2018

engineering-default

Best Practices for Access Credential Rotation at VGS

Yuriy Yunikov November 20, 2018

news-default

VGS Wins SINET 16 Innovator Award

Marshall Jones November 8, 2018