[wildfly-dev] Implementing enforce-victims-rule in wildfly builds

[Vaclav Tunka]

Actually David's team have developed two integration points for the 
tool. One is a Python CLI and the other one is a maven plugin. The maven 
plugin has better integration, but requires POM modifications. The 
Python CLI couldn't use all of the Victims database backend features, so 
it's functionality is more limited compared to the maven plugin. That is 
why I thought maven plugin in upstream might be a good choice.

However I would propose to create a dedicated maven profile, so wildfly 
developers are not burdened by constantly having to run the victims plugin.

Dedicated Jenkins job is definitely a good choice either running the 
specified maven profile using the maven plugin, or waiting for the 
updated python CLI to run it.

Also after IRC discussion with Cheng I would be for adding some white 
list / exclusion list capability for the tool.

Cheers,
Vaclav

On 05/29/2013 04:56 AM, Cheng Fang wrote:
> Security vulnerability is s specialized area, and I would avoid
> incurring this overhead on every build run by every developer.  To
> incorporate the victim scanning into upstream project, I would suggest
> having a dedicated Jenkins job, or adding this capability into existing
> Jenkins job.
>
> I tried it on jberet project by adding the plugin to the top-level pom.
> For every sub-module, it tries to get the updates from the central
> server, which lasts a couple seconds each time, and this can add up to
> significant delay:
>
> [INFO] Retrieving updates from http://www.victi.ms/service/...
>
> The possible false negatives (as David mentioned in his original email)
> can also complicate otherwise successful builds.  The following error
> message might have been caused by gaps in the database, though it's not
> clear which dependency it is complaining about.
>
> [WARNING] Rule 0: com.redhat.victims.VictimsRule failed with message:
> Could not determine vulnerabilities for hash:
> 8edd1a0bf70467791ec883b7452c21333e829ab714c83090f8328d8205f159f2669772dd66db01af60debd40402e994be7b08527e8f90211425567b52e6b9472
>
> Cheng
>
> On 5/27/13 10:16 AM, Vaclav Tunka wrote:
>> Hi,
>>
>> I think it is a good idea implementing this upstream in wildfly, as this
>> tool requires POM modifications. This tool would help us tracking
>> security vulnerabilities proactively rather than retroactively both in
>> wildfly and Enterprise Platforms.
>>
>> Are you OK with that?
>>
>> Cheers,
>> Vaclav
>>
>> On 05/27/2013 07:03 AM, David Jorm wrote:
>>> Hi All
>>>
>>> First I should introduce myself for those who don't know me, as I have not participated in wildfly dev discussions before. I am a security response engineer working for Red Hat, handling security patches for the commercial JBoss products. Recently some colleagues and I have been working on a tool called 'victims'. The victims tool aims to provide a canonical database of known-vulnerable JAR files, along with tools that allow developers and system administrator to determine whether their projects and systems contain any known-vulnerable JARs. The project's about page contains a more detailed explanation:
>>>
>>> http://www.victi.ms/about.html
>>>
>>> enforce-victims-rule is a maven plugin that walks the dependency tree at build time, and uses the victims database to check whether a project is including any known-vulnerable JARs as dependencies. The plugin is available on maven central:
>>>
>>> http://search.maven.org/#artifactdetails|com.redhat.victims|enforce-victims-rule|1.2|jar
>>>
>>> Please see the README.md and sample app here for configuration details:
>>>
>>> https://github.com/victims/victims-enforcer
>>>
>>> I think there would be great value in incorporating this plugin into the wildfly POM(s). It can catch security flaws at build time, eliminating the need for much more work to ship patches for flaws later down the line. It is also designed such that it should not trigger any false positives. There will be false negatives where there are gaps in the database.
>>>
>>> What do people think? Is this something you'd consider implementing?
>>>
>>> Thanks
>>>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>