Give your security updater priority

Give your security updater priority

Mar 27, 2022

Up until last week I was facing a curious issue on one of my old projects: https://github.com/jesperancinha/jeorg-java-ee-7-test-drives. In this project, I am using the following library javax.mvc:javax.mvc-api. On this project I am using both Dependabot and Snyk. Both of them update dependencies on their own criteria. Dependabot seemed to detect version 1.0.0 as the most recent version and Snyk would detect 1.0-pr. Dependabot would open PR's like this one https://github.com/jesperancinha/jeorg-java-ee-7-test-drives/pull/148, whilst Snyk would open PR's like this one https://github.com/jesperancinha/jeorg-java-ee-7-test-drives/pull/153. On an hilarious turn of events they kept on happily interchanging these dependencies like there was no tomorrow. This, of course until I finally noticed the gag. Looking at the maven dependencies we see that on one hand, there aren't that many versions of this library and on the other that the reasons pointed out by Snyk aren't specific and only seem to refer to a simple version update because it's almost always better to have the latest version. We can and we should give our security updater the highest priority, but like all things in life, even the security updater might not be entirely correct. Long story short, what I wanted, was to make sure that version 1.0.0, which is the latest, to be considered for the updates.

In maven we can see some other versions https://mvnrepository.com/artifact/javax.mvc/javax.mvc-api. In order for Snyk and Dependabot to work together, though, I had to realise one thing before-hand. If the security update says that version 1.0-pr is the latest and thus, the safest, we have to go with that. We rely on our security updater to make our applications secure. For this, I had to make the following configuration for this project in the .github/dependabot.yml file from the root:

version: 2
updates:
  - package-ecosystem: "maven"
    directory: "/"
    schedule:
      interval: "daily"
    ignore:
      - dependency-name: "javax:javaee-api"
      - dependency-name: "javax.mvc:javax.mvc-api"
        versions:
           - "1.0-pfd"
           - "1.0.0"
           - "1.0.0-RC1"

The first dependency is there to make sure that my javaee-api dependency never gets updated. This is specific because the project is fully dedicated to the old JEE7 framework. Not very popular these days, but I keep doing maintenance about it. Anyways, the point is that I do not want the framework library to be updated. In the next dependency I specify to dependabot not to consider versions that are out of the acceptance range. For all these three, I found issues: 1.0-pfd, 1.0.0 and 1.0.0-RC1. In this way Dependabot is forced to only accept 1.0-pr dependency.

This was the way I found to solve an inconsistency between Dependabot en Snyk. It is the first time I ever saw this, but I'm sure it won't be the last.


Some mistakes also happen when using tools like Renovate. On one of my projects, https://bitbucket.org/jesperancinha/international-airports-service-root/src/master/, Renovate detected, wrongly, that this very popular library Commons IO had been updated with version 20030203.000550. Because I normally trust these bots, I didn't think that much about accepting this PR. As a result, the build was broken! The way update Bots work, is still pretty much a blackbox to me. I think of them, currently at least as, automated updaters that mostly do a good job. Mostly... In this case, not really. In this case though, and fortunately, Renovate also has a nice way to deal with this. We can configure this in the renovate.json file located at the root:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "repositories": ["jesperancinha/international-airports-service-root"],
  "platform": "bitbucket",
  "extends": ["docker:disable"],
  "username": "jesperancinha",
  "packageRules": [
    {
      "matchPackageNames": ["commons-io:commons-io"],
      "allowedVersions": "!/20030203.000550$/"
    }
  ]
}

What I'm telling Renovate to do here, just simply to ignore the unwanted version.


I hope that with the above, I was able to help you dealing with dependency issues related to automated bot updates should you find any. Security bot updates should always have priority. The reason why I haven't opened an issue with Snyk yet, is because they have already a lot of issues opened to them in github and the snyk wizard apparently doesn't support maven projects yet. On the first illustrated case, I'm also talking about a already fairly outdated library. There is no telling if this would happen in modern libraries and to be honest I never had any issue with any of my other projects I have using only recent libraries and so this could be just one of those non-issues. But hey, I was able to reproduce something different and that is what I wanted to share.

Enjoy this post?

Buy João Esperancinha a coffee

More from João Esperancinha