Request Community Feedback: Jenkins Plugin

554 views
Skip to first unread message

Steve Springett

unread,
Feb 20, 2019, 11:55:25 PM2/20/19
to Dependency Check
Dependency-Check Jenkins Users,

With Dependency-Check v5 (once released) there will be some exciting enhancements, and breaking changes. The Jenkins plugin is built on top of another plugin called analysis-core. Analysis-core is the plugin that does all the visualization, presents graphs, per job results, and optionally breaks builds on warning or failed states (doesn’t really work that well). Analysis-core is also deprecated and we need to get off of it. It also doesn’t support four severity categories and a host of other things we need.

There are two paths forward and this is the reason I’m requesting community feedback

This migration can take a few paths:
  • Migrate from Analysis-core to it’s replacement, Warnings NG. This migration itself has two paths:
    • Create a generic dependency-check parser for WarningsNG and every single WarningsNG installation will have the ability to parse Dependency-Check reports. This is not a security plugin - it will not have Vulnerability Source (NVD, NPM, etc), nor will it have Severity (but will have Priority). Its the exact same view as you’ll find with FindBugs, CheckStyle, PMD, etc. It will also not have a builder - you’ll need to use the Dependency-Check CLI for that. The CLI and the Jenkins builder actually do the same thing and get the same results. So it’s a bit redundant anyway.
    • Rewrite the Dependency-Check plugin for WarningsNG. This will be a lot of work without any known path to success - we will be the first security plugin to be written on top of WarningsNG v3 to the best of my knowledge. We may run into issues and there will likely not be a Jenkins plugin available by the time Dependency-Check v5 is released. Based on my capacity, this likely will not occur until Q3 at the earliest. However, going down this path, we can keep all existing functionality.
  • Rewrite the Dependency-Check plugin based on the Dependency-Track plugin. The Dependency-Track Jenkins plugin isn’t based on a third-party Jenkins plugin. Its simpler, security specific, but doesn’t have all the views that the Dependency-Check plugin does, nor are there plans on doing so. This code can easily be reused and ported to Dependency-Check without much effort. It supports breaking builds or putting them in a warning state, dynamic trends, and dynamic per job findings. Some of the views that this plugin doesn’t have are filtering by CWE, support for viewing only new or fixed issues, and displaying CVE references (although references would be easy to add).

In all cases, existing jobs that are configured with the Dependency-Check publisher to break or put builds in a warning state will be lost. This configuration will need to be redone for every job regardless of the migration approach taken. Historical vulnerability trends (including new/fixed) will also be lost. And finally, once the migration is complete, all prior versions of the Dependency-Check Jenkins plugin (v4.x, v3.x, etc) will no longer be supported.

To compare screenshots between the Dependency-Check, Warnings NG, and Dependency-Track Jenkins plugin, please refer to the following:


This will give you an idea of the graphical views that each plugin has. Dependency-Check has more views - it benefits from this because it doesn’t have a central console containing all the details. Dependency-Track plugin is simpler because it has a web console and notifications on new findings.

So community, please express your thoughts and opinions, especially if you have strong feelings one way or the other. I will likely start working on the migration in the next week or two, so the sooner I get feedback, the better. If you want to forward this email to others in your org to get their feedback, please do so. And finally, if we decide to go down the WarningsNG rewrite path, let me know if you’re interested in volunteering to assist in this effort.



— Steve

Corum, Michael

unread,
Feb 21, 2019, 12:07:45 AM2/21/19
to Steve Springett, Dependency Check

It seems like the options are defined based on the capabilities of other plugins rather than on the needs of the community.  You mentioned that Analysis-core doesn’t support needed features.  Could you list those?

 

After reading in more detail, it seems that option B (2nd sub-bullet) of the Warnings NG route would keep existing functionality (the most important goal).  Since we are dependent on the existing features we would keep using an older version until the re-write was available anyway.  Choosing the other options would likely lead to people cobbling their own plugins anyway since we need the features we currently have and depend on.

 

Michael Corum 

 

From: "dependen...@googlegroups.com" <dependen...@googlegroups.com> on behalf of Steve Springett <st...@springett.us>
Date: Wednesday, February 20, 2019 at 10:55 PM
To: "dependen...@googlegroups.com" <dependen...@googlegroups.com>
Subject: Request Community Feedback: Jenkins Plugin

 

External e-mail. Use caution! / Courriel externe. Faites attention!

--
You received this message because you are subscribed to the Google Groups "Dependency Check" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dependency-che...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Steve Springett

unread,
Feb 21, 2019, 1:02:34 AM2/21/19
to Dependency Check
Great question. Analysis core is deprecated and no longer supported. We are currently on our own and it has many known issues which will not be fixed.

  • It doesn’t properly (or consistently) work with putting builds into a failure or warning state
  • There are several pipeline issues with the publisher
  • It relies on an older version of Jenkins (1.65 or something). Forward compatibility will eventually become an issue
  • The migration to CVSSv2 to CVSSv3 will add “Critical” as a severity. Analysis core only supports three levels and cannot be changed. I talked to the author of WarningsNG (before it was released) and suggested he add Critical. Have not confirmed if this is done.

All of the above issues would be resolved with the 2nd sub-bullet of WarningsNG (the rewrite/migration) as well as porting Dependency-Track plugin over to Dependency-Check. In both cases, the resulting UI would be more modern as well as dynamic vs the old-school static presentation we have today.

The biggest “existing functionality” is the builder, which would be easy to migrate to the WarningsNG version or to a new Dependency-Check plugin based  on the Dependency-Track plugin. I’m not a fan of the builder, I personally don’t use it, but if it’s something the community truly relies on, then we should migrate it over to the new version.

The per-job findings (views) will be the biggest and most noticable difference.  So I’m trying to gauge how important some of these UI things are and determine if their usefulness warrants delaying a release by 6 months or more. I’m also trying to get feedback on which specific UI views are important and see if there’s a way to quickly get a minimal-viable release of v5 and build in some of the more important UI elements over the course of several 5.x point releases. The minimal-viable approach would provide more freedom to do new things and not have the lock-in we have today.

In other words, there will be a rewrite. Do we want to rewrite everything with all the same features/functionality we have today plus add all the great things v5 will bring us, or do we want to take a minimal-viable (1.0) approach to the rewrite and potentially increase functionality over time. 


— Steve

Mark Prins

unread,
Feb 21, 2019, 6:25:34 AM2/21/19
to dependen...@googlegroups.com
I don't much care for breaking the build functionality, all my current
setups use a Jenkins pipeline with a Maven run of dependency-check or
dependency-check-maven:aggregate and I only use the jenkins plugin
(dependencyCheckPublisher) for the reporting (eg trends and details)

Mark

Steve Springett

unread,
Mar 24, 2019, 9:15:03 PM3/24/19
to Dependency Check
Since there was only two responses over the past month without any details on what specific features or views the community desires, I will be choosing option B, porting the Dependency-Track plugin to Dependency-Check and not migrating from analysis-core to warnings-ng. Given that Dependency-Check 5.0 is nearing completion, I will attempt to have the Jenkins plugin ready in time.

I do not use gitflow, so expect the master branch to be unusable until 5.0 of the Jenkins plugin is ready. 

If the community desires additional views or features in analysis-core that will not be present in 5.0, the project accepts pull requests. 

PM

unread,
Jun 10, 2019, 2:20:43 PM6/10/19
to Dependency Check
Hi Steve,

Thanks for all your work on dependency check maven plugin. We updated our plugin to recent version 5.0.0 and don't seem to be getting CVSS scores for the vulnerabilities reported. I see that in your comment you mentioned that adding CVSS score would not be difficult. I was wondering if you have a plan to add that and release a patch sometime soon.

Thanks again.

Steve Springett

unread,
Jun 10, 2019, 4:08:34 PM6/10/19
to Dependency Check
Maven plugin? Sorry, I don’t think I’ve contributed all that much to the Maven plugin - only bits and pieces here and there.

The Jenkins plugin, yes, done a lot with that. If you’re using Dependency-Check maven plugin v5 and using it with the current version of the Jenkins plugin (v4.x), it likely will not work, or work really poorly.

The XML schema between versions 1.x and 4.x didn’t change all that much - only minor things here and there. Major changes to the XML schema were introduced in Dependency-Check v5. So the Jenkins plugin v4.x and lower will not be able to properly read XML reports from Dependency-Check v5.

V5 of the Jenkins plugin will also not be able to read reports generated from previous versions of Dependency-Check. It’s not backward compatible, and like Dependency-Check v5 itself, has breaking changes.

V5 of the Jenkins plugin normalizes severity to Critical, High, Medium, Low, and Unassigned and will no longer focus on CVSS scores. Findings from Retire.js often do not include CVSS scores and NPM removed all CVSS scores from their API shortly after they acquired NSP. For findings that do have CVSS scores, CVSSv2 and CVSSv3 scores will be displayed in the UI, just not in a sortable way.



— Steve
--

You received this message because you are subscribed to the Google Groups "Dependency Check" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dependency-che...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages