facebook noscript

How to Avoid Using Components with Known Vulnerabilities

November 27, 2018

How to Avoid Using Components with Known Vulnerabilities

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

Linkedin Icon

You Might Also Be Interested In...

Introducing VGS’s Account Validation
Payments
Introducing VGS’s Account Validation

Learn how VGS Account Validation uses card verification, CVC verification, AVS, and ANI to reduce payment failures and fraud, without exposing sensitive data. See why merchants and enterprise platforms trust VGS for secure payment operations.

May 28, 2026
PSP Vault vs. Independent Token Vault: How Merchants Should Choose
Payments
PSP Vault vs. Independent Token Vault: How Merchants Should Choose

PSP vault or independent token vault? Learn how credential storage impacts payment flexibility, network token portability, multi-processor routing, vendor lock-in, and when merchants should choose a neutral vault to scale globally.

May 27, 2026
VGS is the Universal Translation Layer for Agentic Protocols
Agentic
VGS is the Universal Translation Layer for Agentic Protocols

VGS is the universal translation layer for any agentic protocol. Through tokenization and protocol interoperability, VGS enables agents to communicate securely and seamlessly across any protocol stack.

May 15, 2026