OWASP dependency check maven plugin (was: Does Drill Use Apache Struts)

[Vlad Rozov <vr...@apache.org>]

What the community thinks about implementing OWASP dependency check 
maven plugin that will be disabled by default and enabled in Travis-ci 
and/or Jenkins builds? It has an ability to fail build depending on the 
level of CVE present in the project dependencies.

The topic is probably more suitable for the dev@drill list, so moved it 
there.

Thank you,

Vlad

On 9/8/17 09:27, Bob Rudis wrote:
> (This is primarily for John, but may be of use to a broader set of folks)
>
> OWASP's straightforward-yet-uncreatively-named "DependencyCheck" tool
> <https://github.com/jeremylong/DependencyCheck> may be worth looking
> into. I haven't had to run it in a while (thankfully I work in R most
> of the time now ;-) but it should help diagnose project dependencies
> that have vulnerabilities. It takes a wee-bit to get it up and running
> (not much, tho) but once you do it shld be able to churn out anything
> that's remotely bad dep-wise.
>
> There are likely some OWASPians who wld be willing to help get run on
> Drill source, too.
>
> On Fri, Sep 8, 2017 at 11:49 AM, John Omernik <jo...@omernik.com> wrote:
>> That's a great idea Bob.
>>
>> The difficult thing is a review may find what's vulnerable and known about
>> at the time of a the assessment, but when new vulnerabilities are released
>> especially in libraries that may or may not be known to be a part of core
>> projects, it can be harder to see the impact of those vulnerabilities.  I
>> will keep checking the poms of things I use (thanks Bob for the pointer
>> there, I am not a Java person, but it's seems reasonable to use that as the
>> starting point).  Also, it's good to raise awareness on all of these points
>> in general so I always appreciate lively discussions :)
>>
>>
>>
>> On Fri, Sep 8, 2017 at 10:42 AM, Bob Rudis <bo...@rud.is> wrote:
>>
>>> I personally haven't had the cycles to do a thorough appsec review of
>>> the main web interface, the REST interface, access controls or
>>> encryption tools, but I also only run Drill on private AWS instances
>>> or on personal servers / systems, so it hasn't been a huge priority
>>> for me.
>>>
>>> I would encourage the Drill team to apply for a CII grant
>>> <https://www.coreinfrastructure.org/>. CII has funded security audits
>>> of OpenSSL and other OSS software and I believe Drill would be a great
>>> candidate, especially since it's designed to provide access to diverse
>>> data stores (i.e. breach Drill and you get to everything behind it).
>>>
>>> MapR or Dremio could likely help speed up said grant application since
>>> they are commercial entities with ties to the OSS side of Drill.
>>>
>>> On Fri, Sep 8, 2017 at 11:28 AM, Saurabh Mahapatra
>>> <sa...@gmail.com> wrote:
>>>> Thanks John, all. I think this discussion thread is important. As a
>>> community member, I learn so much by reading these threads.
>>>> Since you work in cyber security research, are there specific things we
>>> should think about from a security standpoint for Drill?
>>>> I know that we have a REST API and I am sure there are web apps being
>>> built around it. Are there vulnerabilities that we need to be aware of? How
>>> can we advise users about this?
>>>> Thoughts?
>>>>
>>>> Best,
>>>> Saurabh
>>>>
>>>> Sent from my iPhone
>>>>
>>>>
>>>>
>>>>> On Sep 8, 2017, at 7:41 AM, John Omernik <jo...@omernik.com> wrote:
>>>>>
>>>>> Also, thank you for the pointer to the pom.xml
>>>>>
>>>>>> On Fri, Sep 8, 2017 at 9:41 AM, John Omernik <jo...@omernik.com> wrote:
>>>>>>
>>>>>> So, I thought I was clear that it was unverified, but I also I am in
>>> cyber
>>>>>> security research, and this is what is being discussed in closed
>>> circles. I
>>>>>> agree, it may not be just struts, it's not spreading rumors to say,
>>> this
>>>>>> struts vulnerability is serious, and it's something that should be
>>>>>> considered in a massive breech like this. Also, as with most security
>>>>>> incidents, it is likely only a part of the story. It could be SQLi and
>>> it
>>>>>> could be Struts and it could be both or neither. To imply it was
>>> unrelated
>>>>>> SQLi is just as presumptuous as saying it was struts. Some folks are
>>>>>> talking about attackers using Struts to get to a zone where SQLi was
>>>>>> possible.  I will be clear(er): I have not verified that Equifax is
>>> wholly
>>>>>> struts, or even related to Struts, but my fear right now is focused on
>>> open
>>>>>> source projects that may use Struts and I think this is legitimate.
>>> Putting
>>>>>> it into context, I want to learn more how to ensure vulnerabilities in
>>> one
>>>>>> project/library are handled from a cascading point of view.
>>>>>>
>>>>>> John
>>>>>>
>>>>>>> On Fri, Sep 8, 2017 at 9:15 AM, Bob Rudis <bo...@rud.is> wrote:
>>>>>>>
>>>>>>> Equifax was likely unrelated SQL injection. Don't spread rumors.
>>>>>>>
>>>>>>> Struts had yet-another-remote exploit (three of 'em, actually).
>>>>>>>
>>>>>>> I do this for a living (cybersecurity research).
>>>>>>>
>>>>>>> Drill is not impacted which can be verified by looking at dependencies
>>>>>>> in https://github.com/apache/drill/blob/master/pom.xml
>>>>>>>
>>>>>>>> On Fri, Sep 8, 2017 at 10:12 AM, John Omernik <jo...@omernik.com>
>>> wrote:
>>>>>>>> Rumors are pointing to it being related to the Equifax breech (no
>>>>>>>> confirmation from me on that, just seeing it referenced as a
>>>>>>> possibility)
>>>>>>>> http://thehackernews.com/2017/09/apache-struts-vulnerability.html
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Sep 8, 2017 at 9:07 AM, Ted Dunning <te...@gmail.com>
>>>>>>> wrote:
>>>>>>>>> Almost certainly not.
>>>>>>>>>
>>>>>>>>> What issues are you referring to? I don't follow struts.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sep 8, 2017 16:00, "John Omernik" <jo...@omernik.com> wrote:
>>>>>>>>>
>>>>>>>>> Hey all, given the recent issues related to Struts, can we confirm
>>> that
>>>>>>>>> Drill doesn't use this Apache component for anything? I am not good
>>>>>>> enough
>>>>>>>>> at code reviews to see what may be used.
>>>>>>>>>
>>>>>>>>> John
>>>>>>>>>
>>>>>>