I’ve begun work on a new SonarQube plugin for reading in a Dependency-Check report file.
Dependency-Check is an OWASP project that identifies third party components and determines if they have known vulnerabilities in the National Vulnerability Database.
Dependency-Check is available as a CLI, Ant plugin, Maven plugin and Jenkins plugin. The addition of a Sonar plugin will provide increased visibility into the use of components with known vulnerabilities.
I’m basing the Sonar Dependency-Check plugin off the latest version of the Sonar Fortify plugin. As this is my first attempt at a SonarQube plugin, any advise or pointers is much appreciated.
Please have a look to this documentation:
Here is also a code example:
On 4 January 2015 at 22:00, Steve Springett <[hidden email]> wrote:
Basically you have to declare a new rule (see interface RulesDefinition) and a sensor that injects issues on project itself (see Sensor and Issuable).
Hi Steve,Thanks in advance for this contribution. This plugin would be very valuable for the platform.
On 4 January 2015 at 22:00, Steve Springett <[hidden email]> wrote:
this sounds very promising.
looking forward to test it.
> Iâve begun work on a new SonarQube plugin for reading in a
> Dependency-Check report file.Â
> Dependency-Check is an OWASP project that identifies third party
> components and determines if they have known vulnerabilities in the
> National Vulnerability Database.Â
> Dependency-Check is available as a CLI, Ant plugin, Maven plugin and
> Jenkins plugin. The addition of a Sonar plugin will provide increased
> visibility into the use of components with known vulnerabilities.
> Iâm basing the Sonar Dependency-Check plugin off the latest version of
> the Sonar Fortify plugin. As this is my first attempt at a SonarQube
> plugin, any advise or pointers is much appreciated.Â
Chief Technical Officer
Fluidtime Data Services GmbH
Neubaugasse 12-14/25, 1070 Vienna, Austria
Tel +43 (0)1 5860 180
Mob +43 (0)660 425 80 20
Fax +43 (0)1 5860 180 - 1
To unsubscribe from this list, please visit:
Hi Steve and Simon,
As valuable as this OWASP Dependency Check is (and it is valuable), I think this would be a mistake to try integrating this tool into SonarQube. You would have asked the question 5 years ago I would have said the opposite because at that time everyone was considering SonarQube as a kind of super dashboard to aggregate any kind of quality/reliability/security data relating to development projects. So data coming from the the build server, the ticket engine, the dependencies, etc ...
But progressively, things have changed and the SonarQube ecosystem have evolved and keep on evolving to cover well ONE thing: the tracking of maintainability, reliability and security issues contained in the source files.
That's why for instance we're working so hard to match our coding rules with the MITRE CWE referential. With OWASP Dependency Check, we're covering another valuable, complementary but different domain: the tracking of all binary dependencies that contain some known security vulnerabilities (listed in the MITRE CVE referential).
Obviously this is possible to inject this kind of security vulnerabilities into SonarQube but the API, the back-end and the UI are not designed to work well with those issues. For instance, you'll have to associate all those issues to the projects whereas perhaps you'd like to associate them directly to some dependencies. Perhaps you'd like to quickly see the most critical dependencies that are used in your portfolio of projects and starting from them to see which projects are using those dependencies, ...
My 2 cents: I would not initiate this integration effort.
On Mon, Jan 5, 2015 at 9:06 AM, Simon Brandhof <[hidden email]> wrote:
I completely agree. SonarQube should not be the super dashboard that measures and aggregates every aspect of a project. And I honestly don’t know what the integration will look like yet. It’s quite possible that because the plugin is attempting to do something that Sonar doesn’t excel at, that the results may be less than ideal. I won’t know until I dive further. However, I think this specific type of issue (vulnerabilities in third party components) is extremely valuable to Sonar and to the developers who add dependencies to code.
Often times, developers add a dependency to a pom file (or build.xml, etc) without any regard for whether it’s the latest version of that dependency. Or what other dependencies they’re also pulling in as a result. A single code change to a pom can pull in all sorts of vulnerabilities that can put the application they’re developing at risk.
A study conducted by Aspect Security in 2012 revealed that 26% of all requests to Maven Central were for components that had known vulnerabilities.
Three years later, we haven’t gotten any better as an industry. Visibility is key. I created the Jenkins plugin that allows build engineers to fail the build should a new vulnerability be detected. The addition of a Sonar plugin will extend that visibility even further.
This is a classification of vulnerability that shouldn’t exist. Hopefully with additional visibility and awareness campaigns that are being conducted by commercial and open source groups alike, we can greatly reduce the likelihood of these types of issues.
On January 15, 2015 at 9:12:38 AM, Freddy Mallet ([hidden email]) wrote:
I know this is resurrecting this thread, but I have another perspective on this.
> As valuable as this OWASP Dependency Check is (and it is valuable), I think this would be a mistake
> to try integrating this tool into SonarQube.
> But progressively, things have changed and the SonarQube ecosystem have evolved and
> keep on evolving to cover well ONE thing: the tracking of maintainability, reliability and
> security issues contained in the source files.
To me, this is a technical debt issue. If a project gets too far behind in updating its libraries it becomes difficult to manage the knowledge required for a software developer to maintain the software. For example, we use an old version of GWT and new developers to my team who typically use more modern versions of GWT are severely constrained in their solutions. When you have a spread of versions across different assets, it becomes hard for any developer to know what capabilities are present in any one asset.
As more granular approaches (microservices) become a more common approach, there will only be more and more of this as an issue.
Personally, I don't care too much if there are security issues in the libraries, I just care that my organisation has too large a range of versions being included in the various components of our system.
Technically, I'm thinking of using the OWASP dependency check as a proxy for a more general dependency upgrading task. This way it saves me from writing something myself.
I can even conceive of some kind of technical debt metric (in dollar terms) that would add to the overall tech-debt load, depending on how many versions my asset was behind.
I’m coming at this from purely a security perspective, vulnerabilities (usually technical defects) being a subset of quality.
But you’re correct. This is a huge technical debt issue. Often times, developers will add a component to an application, write tests, etc, and as long as it keeps working, there’s little reason (in their minds) to change it. Over time, as architectures and technologies change, it can lead to massive undertakings just to upgrade an existing component. I’ve seen teams struggle with upgrading embedded Jetty servers, Hibernate, Struts, SpringFramework, etc, simply because they were massively out of date.
I’m a core contributor to this project. There’s an enhancement request floating out there that may be of interest to you. It will flag ‘old’ components. ‘Old’ being user definable, but I think it may help with the larger technical debt issue you’re trying to identify and reduce.
I’m hoping that someone on the core team or in the appsec community can implement this feature.
On May 20, 2015 at 10:16:14 PM, deniskrizanovic ([hidden email]) wrote:
FYI - There's another somewhat related discussion thread open right now: http://sonarqube.15.x6.nabble.com/Is-there-a-way-to-create-a-rule-to-flag-usage-of-a-prohibited-Maven-component-dependency-tt5032593.html#a5033121
Spoiler: It's a request to be able to create rules to flag certain specific library (or just one version of a library) dependencies that have known issues.
On Thu, May 21, 2015 at 12:16 PM, Steve Springett <[hidden email]> wrote:
|Free forum by Nabble||Edit this page|