Suppression not working

639 views
Skip to first unread message

tinius.alex...@gmail.com

unread,
Mar 16, 2014, 5:00:16 AM3/16/14
to dependen...@googlegroups.com
I'm executing the following: "C:\dependency-check-1.1.3-release\bin\dependency-check.bat" --app "REPLACETHIS" --format "ALL" --out "C:\BuildAgent\work\6c1e7ceb21a93a4f\Artifacts\OWASP Dependency Check" --scan "C:\BuildAgent\work\6c1e7ceb21a93a4f" --suppression "C:\BuildAgent\work\6c1e7ceb21a93a4f\dependency-check-suppressions.xml"

The report includes all the vulnerabilities I have intended to suppress. It looks like the suppression file is not taken into account at all. This is my suppression file: http://pastie.org/private/w3lwfza4gynflcgboptxa

I have double checked the existence of the file, and the correct location appears in the verbose log.

Any ideas?


Jeremy Long

unread,
Mar 16, 2014, 6:59:57 AM3/16/14
to tinius.alex...@gmail.com, dependen...@googlegroups.com
Well that is a little embarrassing...  I introduced a small bug that pretty much disabled the suppression analyzers (unless you specified it as a URL e.g. file://path/to/suppression.xml). I've added additional test cases to ensure this doesn't happen again. Sorry for any inconvenience and as an FYI, due to a handful of small bugs/enhancements I will likely be releasing 1.1.4 soon.

Also, I would highly recommend suppression the CPE instead of the individual CVEs. The mapping between CPE->CVE is strong and I don't see that introducing false positives (but it may introduce a vulnerability that you or your organization doesn't care about so the functionality to suppress them was added). However, the mapping of File->CPE can produce false positives and it is generally pretty easy to figure out that the CPE is wrong.

Best Regards,

Jeremy


--
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.

tinius.alex...@gmail.com

unread,
Mar 16, 2014, 7:43:15 AM3/16/14
to dependen...@googlegroups.com, tinius.alex...@gmail.com
Quick and helpful reply as always.

When I get this working well, I will post an article on my blog showing how to integrate this tool into one's build process in TeamCity.

Thanks!

tinius.alex...@gmail.com

unread,
Mar 16, 2014, 8:25:07 AM3/16/14
to dependen...@googlegroups.com, tinius.alex...@gmail.com
If other people are trying to get this to work in 1.1.3, using this value did it for me:
file:///C:/BuildAgent/work/6c1e7ceb21a93a4f/dependency-check-suppressions.xml

Zierer, Thomas

unread,
Mar 17, 2014, 5:05:42 AM3/17/14
to dependen...@googlegroups.com

Jeremy,

 

specifying the suppressions file with http:// works perfectly. This makes it much more useable to us!

 

Thanks

Tom

Sergey Shekyan

unread,
Mar 25, 2014, 8:50:29 PM3/25/14
to dependen...@googlegroups.com, tinius.alex...@gmail.com
Using file:///absolute_path/suppression.xml doesn't help on OSX with Ant :( 

Jeremy Long

unread,
Mar 26, 2014, 6:20:17 AM3/26/14
to Sergey Shekyan, dependen...@googlegroups.com, tinius.alex...@gmail.com
I apologize about this - this is a known bug that has been fixed in the current snapshot. The release has been delayed due to global travel and other life events.

However, on OSX wouldn't it be    file://absolute_path/suppression.xml
(note one less slash in the file protocol - I could be completely mistaken regarding this though)

--jeremy

Jeremy Long

unread,
Mar 26, 2014, 7:02:40 AM3/26/14
to Sergey Shekyan, dependen...@googlegroups.com, tinius.alex...@gmail.com
so...  please ignore anything I ever say about how things work on a mac ;)

I'll see if I can get one of the other devs that are working on the project to figure out why the file:// protocol might not be working there.

--Jeremy

colezlaw

unread,
Mar 27, 2014, 7:15:38 AM3/27/14
to dependen...@googlegroups.com, Sergey Shekyan, tinius.alex...@gmail.com
I'm working on it. Initial testing is not good, but suppression.file is getting set properly according to the log, and if it works from the CLI, then I'm puzzled as to what might be going on here.

Jeremy - if it works on Linux, there shouldn't be anything peculiar about how it works on a Mac except that in some instances the filesystem can act like it's case-insensitive.

colezlaw

unread,
Mar 27, 2014, 9:34:50 AM3/27/14
to dependen...@googlegroups.com, Sergey Shekyan, tinius.alex...@gmail.com
Then again, it seems to be working fine, now. I was previously just checking the size of the report since the CPE I was suppressing produced a large number of findings and so I expected the report size to be much smaller, but it was actually larger. 

Unfortunately, as was mentioned, in version 1.1.13, you still have to specify the file:// scheme, and then file:// is the scheme and then it actually requires the URL to be hierarchical, not relative, so if the file was in /Users/colezlaw/suppressions.xml, the suppressionFile would need to be file:///Users/colezlaw/suppressions.xml (there are three /'s after : in file:). 

Sergey Shekyan

unread,
Mar 29, 2014, 11:27:24 AM3/29/14
to dependen...@googlegroups.com
Jeremy, using absolute URL with file scheme worked. My little expirience with java and ant added up: didn't know that ant converts paths in variables to relative ones.

Jeremy Long

unread,
Mar 29, 2014, 12:19:26 PM3/29/14
to Sergey Shekyan, dependen...@googlegroups.com
Okay thanks. I just wanted to make sure there wasn't a bug that needed be fixed. Glad things are working now and I hope you find the tool useful.

--Jeremy


On Sat, Mar 29, 2014 at 11:27 AM, Sergey Shekyan <she...@gmail.com> wrote:
Jeremy, using absolute URL with file scheme worked. My little expirience with java and ant added up: didn't know that ant converts paths in variables to relative ones.
Reply all
Reply to author
Forward
0 new messages