Updated Dependency check version in docker image.

[bobthesecurityguy]

Also adds GPG signature verification of the releases and updates the dependencies to keep it from failing if it encounters a DLL file in the scanned repo.

[omerlh]

Can you please provide a link to a docs specifing this key?

[bobthesecurityguy]

As you may have noticed, the project documentation is fairly light, especially surrounding the installation process and the publishing of pre-compiled binaries on Bintray. (I added the comment with the link to the main Bintray downloads page because it took me a while to figure out the right URL myself.) The best that I can do for you here is to explain how I got to the key.
As noted in a comment in the commit, the the files are published on the Dependency Check Bintray site and include a .zip.asc file there, which is a detached signature for the .zip. There appears to be no officially published documentation about how that signature is generated, except for a single issue on the Dependency Check Issue tracker about adding signatures to the published binaries. Here, Jeremy Long, the same username and avatar as the one publishing the builds on Bintray, says on 2018/06/01 that he is planning to start signing releases. If we look at the user's Bintray profile, we see that they have a link to their GPG key there. So I took that key, parsed its fingerprint and plugged in a call to gpg --recv-keys in the format that we've been using throughout the rest of the file.

[omerlh]

Isn't that fragile? maybe worth not using a signature until they official support it?

[bobthesecurityguy]

In general, I think I understand where you are coming from. However, I think that in this case, it is likely fine. (I acknowledge, though, that I don't get the final say here, so if I fail to convince you, just let me know and that part can be removed so that we can get the rest taken care of.)

Characterizing this as not officially supported assumes that there is some standard of official support that we can expect the developer to adhere to. Certainly it would be helpful if the published installation instructions mentioned this topic and provided the key with an assertion that future releases would be signed as such. However, given the overall sparse project documentation, I don't know that the omission of such a line implies a lack of support.

What I do know, is that since the issue tracker comment linked in my previous comment, all 9 releases (starting with 3.3.0 on 2018/07/22) have been signed with signatures published to Bintray. Also, the developer has stated, in said linked comment, that this is an issue that is important to him. Therefore I would consider it fairly likely that this is planned to continue.

Given this information, I believe that validating the signature for this package is reasonable, despite the lack of proper documentation on the process from the official project pages. The potential impact to Glue here is very minimal. You are downloading pinned versions of Dependency Check in this Dockerfile. So even if the next release isn't signed, your builds don't break until you change this file to point to that release package (at which point, if you were confident that the unsigned release was actually valid, you could also choose to disable the signature check).

[omerlh]

I'm more worried from a security point of view, but I see you're point. Let me ping them on the slack channel and see if someone can chime-in and shade some light here.

[bobthesecurityguy]

Not sure if this will help alleviate your concerns here, but this PR was just merged into the Dependency Check repository to update the project documentation to mention the cryptographic signing of packages. Conveniently, it recommends the exact commands we're using here. 😄
The actual documentation pages don't reflect the PR yet, but will when they are next deployed.

[stevespringett]

Dependency-Check project documentation is here: https://jeremylong.github.io/DependencyCheck/

However, we do not document the signing process. For that, you'll need to ping @jeremylong

[omerlh]

Ok, I also noticed the PR was merged, which is a good sign :)
Can you please create one layer instead of multiple? e.g. run all the commands is a single RUN directive? It helps keep the image somewhat smaller...

[bobthesecurityguy]

@omerlh Just an update that those have been moved into a single layer. Also the documentation is live on the dependency-check site now.

[omerlh]

Just add a step that cleans up the zip files after downloading them?

[bobthesecurityguy]

.zip and .zip.asc files are now removed after download.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.