We use cookies to ensure you get the best experience on our website.Read moreRead moreGot it

close
  • Products
    • Products
      • Snyk Open Source (SCA)
        Avoid vulnerable dependencies
      • Snyk Code (SAST)
        Secure your code as it’s written
      • Snyk Container
        Keep your base images secure
      • Snyk Infrastructure as Code
        Fix misconfigurations in the cloud
      • Snyk Cloud
        Build, deploy, and stay secure
    • Solutions
      • Application security
        Build secure, stay secure
      • Software supply chain security
        Mitigate supply chain risk
      • Cloud security
        Build and operate securely
    • Platform
      • What is Snyk?
        Developer-first security in action
      • Developer security platform
        Modern security in a single platform
      • Security intelligence
        Comprehensive vulnerability data
      • License compliance management
        Manage open source usage
  • Resources
    • Using Snyk
      • Documentation
      • Vulnerability intelligence
      • Product training
      • Customer success
      • Support portal & FAQ’s
      • User hub
    • learn & connect
      • Blog
      • Community
      • Events & webinars
      • DevSecOps hub
      • Developer & security resources
    • Listen to the Cloud Security Podcast, powered by Snyk
  • Company
    • About Snyk
    • Customers
    • Partners
    • Newsroom
    • Snyk Impact
    • Contact us
    • Jobs at Snyk We are hiring
  • Pricing
Log inBook a demoSign up
All articles
  • Application Security
  • Cloud Native Security
  • DevSecOps
  • Engineering
  • Partners
  • Snyk Team
  • Show more
    • Vulnerabilities
    • Product
    • Ecosystems
EcosystemsEngineering

Fixing vulnerabilities in Maven projects

Brian VermeerSeptember 14, 2020

Maven is still the most used build system in the Java ecosystem. According to the JVM report 2020, Maven is the number one build tool in the ecosystem with two-thirds of the share. 

Therefore, it is important to now how Maven works. For instance, if you find vulnerabilities in your Maven project using Snyk, how can you fix them?  In this article, I will explain how you can fix vulnerabilities in third-party libraries when using Maven, even if it is not obvious.

Finding vulnerabilities

If you are using Maven building your project and managing your dependencies for your project, there are several ways to scan your projects using Snyk. This is regardless of the actual programming language you use—this can be Java, Kotlin, Scala, Groovy, or any other language that is designed for the Java Virtual Machine (JVM).

Scanning your Maven project for vulnerabilities with Snyk can be done by using

  • Snyk CLI
  • Snyk Github Actions for Maven
  • Snyk Maven Plugin
  • Snyk IDE plugin for Eclipse or IntelliJ IDEA
  • connecting your repository to Snyk

Taking the CLI as our example, Snyk will show you if and how you can fix vulnerabilities by updating the top-level dependencies. However, if there is no improved version of the top-level dependencies, Snyk shows you if there is a newer version of the underlying dependency that fixes the vulnerabilities.

Fixing top-level vulnerabilities 

The easiest way to fix a vulnerability found by Snyk is to change the top level library, if possible. If the library does not have underlying dependencies it is quite obvious that you need to upgrade to a newer version that does not have that particular issue. The same applies when an underlying dependency does have an issue but there is already a newer version of the top-level dependency available that doesn’t have the issue.

There are a few ways to switch the version. First, find out where the version is specified. For top-level dependencies, in most cases, you can find it in one of the following:

  • in a parent pom
  • in a property
  • direct at the dependency level

Parent pom

If the dependency you need to upgrade is defined in a parent pom, first look for a newer version of the parent pom. Take Spring Boot for instance, if there already is a newer version of the parent, consider upgrading to that newer version first and see if that solves the problem. This way you update the whole set of dependencies and, in most cases, they play along better than just upgrading a single dependency. If you cannot switch or change the parent, jump to the direct approach.

<parent>
   <groupId>io.snyk</groupId>
   <artifactId>demo-parent</artifactId>
   <version>1.0.4.RELEASE</version>
</parent>

Properties

If a property is used, update the property first. This can potentially update other dependencies as well, but just as with the parent pom, there is a good reason for this. If libraries are released as a set you know that they work better together if they have the same version.

<properties>
<commons-lang3.version>3.9</commons-lang3.version>
</properties>

Direct

Finally, your dependency is declared in the dependencies part of your maven pom file. Here, you specify the groupId, artifactId, and in many cases the version. If the version is declared here, simply update it. If not, you can add it. 

Note that this is the lowest level of declaring the dependency version and will override all the other ways of setting the version.

<dependency>
  <groupId>org.eclipse.collections</groupId>
  <artifactId>eclipse-collections</artifactId>
  <version>10.4.0</version>
</dependency>

Fixing underlying dependencies

Let’s say there is not yet a newer version of your top-level dependency available but one of the underlying dependencies has an issue you need to fix. The CLI already notified you that there is a newer version of that underlying dependency available that fixes the problem. 

Bill of Materials

Many frameworks are using a Bill of Materials (BOM) to manage underlying dependencies. A BOM is a special kind of POM that is used to control the versions of a project’s dependencies and provide a central place to define and update those versions. 

When an underlying dependency needs to be replaced in a framework like Spring Boot, take a look if this dependency is part of BOM. If so, check if there already is a newer version of that specific BOM and update the version. In Spring Boot and many other well-known frameworks, the versions of the BOM are specified as a property. You can override the property in your own Maven POM file by adding a property.

In the example below I override the BOM for Jackson in my Spring Boot project:

<properties>
    <jackson.version>2.10.2.20200130</jackson.version>
</properties>

Dependency management

In a Maven POM, it is possible to exclude and include specific underlying dependencies when declaring a top-level dependency. However, this can be problematic when two libraries share the same underlying dependency. A best practice in Maven is to bundle these declarations in the dependency management section. This section allows project authors to directly specify the versions of artifacts to be used when they are encountered in transitive dependencies. In addition to the example below, the documentation clearly explains how dependencyManagement should be used:

<dependencyManagement>
   <dependencies>
       <dependency>
           <groupId>org.yaml</groupId>
           <artifactId>snakeyaml</artifactId>
           <version>1.26</version>
       </dependency>
   </dependencies>
</dependencyManagement>

Conclusion

As you can see, there are several ways to mitigate security issues in open source dependencies for a Maven-based project. Even when there is no direct fix by updating a top-level dependency you are able to filter out an underlying transitive dependency and switch to the newer available version. Snyk open source scanning provides you with information on what version you need to upgrade. This article shows you how you can configure it properly in your Maven project.

Discuss this blog on Discord

Join the DevSecOps Community on Discord to discuss this topic and more with other security-focused practitioners.

Go to Discord
Footer Wave Top
Patch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo Segment
Develop Fast.
Stay Secure.
Snyk|Open Source Security Platform
Sign up for freeBook a demo

Product

  • Developers & DevOps
  • Vulnerability database
  • API status
  • Pricing
  • Test with GitHub
  • IDE plugins
  • What is Snyk?

Resources

  • Snyk Learn
  • Blog
  • Security fundamentals
  • Resources for security leaders
  • Documentation
  • Snyk API
  • Disclosed vulnerabilities
  • Open Source Advisor
  • FAQs
  • Website scanner
  • Japanese site
  • Audit services
  • Web stories

Company

  • About
  • Snyk Impact
  • Customers
  • Jobs at Snyk
  • Snyk for government
  • Legal terms
  • Privacy
  • Press kit
  • Events
  • Security and trust
  • Do not sell my personal information

Connect

  • Book a demo
  • Contact us
  • Support
  • Report a new vuln

Security

  • JavaScript Security
  • Container Security
  • Kubernetes Security
  • Application Security
  • Open Source Security
  • Cloud Security
  • Secure SDLC
  • Cloud Native Security
  • Secure coding
  • Python Code Examples
  • JavaScript Code Examples
Snyk|Open Source Security Platform

Snyk is a developer security platform. Integrating directly into development tools, workflows, and automation pipelines, Snyk makes it easy for teams to find, prioritize, and fix security vulnerabilities in code, dependencies, containers, and infrastructure as code. Supported by industry-leading application and security intelligence, Snyk puts security expertise in any developer's toolkit.

Resources

  • Snyk Learn
  • Blog
  • Security fundamentals
  • Resources for security leaders
  • Documentation
  • Snyk API
  • Disclosed vulnerabilities
  • Open Source Advisor
  • FAQs
  • Website scanner
  • Japanese site
  • Audit services
  • Web stories

Track our development

© 2022 Snyk Limited
Registered in England and Wales
Company number: 09677925
Registered address: Highlands House, Basingstoke Road, Spencers Wood, Reading, Berkshire, RG7 1NT.
Footer Wave Bottom