Display vulnerabilities for returned dependencies

[shaikhu]

Firstly wanted to say thank you for developing such an amazing tool!

I started to look into issue #22 and this draft PR demonstrates a possible implementation. Any thoughts/ideas/feedback would be most welcome.

The OSS Index Rest API provides two endpoints for accessing a component report (listing known vulnerabilities). Sadly both endpoints involve rate limiting (I don't know the figures off the top of my head) but the authorized endpoint provides a higher limit. You can register and use an email and api token to authenticate each request. See instructions.

1. The rest endpoint uses a Package Url to identify a dependency. This is the specification and this is Java implementation I used.
2. This PR uses the unauthorized endpoint (and quickly ran into issues with rate limiting). I like the discussion of having a default configuration where oss index credentials could be stored.
3. Example displaying cve ids (didn't make sense to show the "description" as I believe this is intended for html output)
   
4. Example displaying reference links (unfortunately the links are quite long)
   
5. Example when searching for dependency leads to a direct match
   

Do you already have a solution in mind? Any preference for how vulnerabilities should be displayed?

[mthmulders]

Thanks for your great initiative and your kind words, @shaikhu. I'm going to have a proper look at your code soon(ish). In the meantime, I'll think of whether the 'default configuration' idea (#187) should be implemented first, so this feature could be built on top of it. I think making it possible to specify API credentials will greatly enhance the usability of this feature!

[mthmulders]

As far as the output goes, may I ask for the following?

1. I would prefer if MCS would not print all CVE's in a list of search results. I would prefer if the "Vulnerabilities" column was summarised, for example, "3 high, 1 medium, 5 low". Something like this (fake data):

  Coordinates                                                    Last updated                 Vulnerabilities
  ===========                                                    ============                 ===============
  com.luhuiguo.netty:netty-handler:4.1.63.GM                     24 Feb 2022 at 15:26 (CET)   -
  io.netty:netty-handler:5.0.0.Alpha2                            03 Mar 2015 at 17:10 (CET)   1 high
  org.jboss.errai.io.netty:netty-handler:4.0.0.Alpha1.errai.r1   23 Feb 2012 at 06:53 (CET)   3 medium, 1 low
  io.netty.contrib:netty-handler-proxy:5.0.0.Alpha2              30 Sep 2022 at 08:28 (CEST)  5 medium
  io.netty:netty5-handler:5.0.0.Alpha5                           28 Sep 2022 at 16:09 (CEST)  - 
  io.netty:netty-handler-proxy:5.0.0.Alpha2                      03 Mar 2015 at 17:15 (CET)   2 high, 4 low
  io.netty:netty-handler-ssl-ocsp:4.1.97.Final                   23 Aug 2023 at 11:04 (CEST)  -

2. For the detailed output (only one artifact result, printed as XML/Groovy/...), I would prefer to see all the vulnerabilities, each on one line. It would be great if they were sorted by priority, then by age, and could include a link to a detail page. Something like this (again, with fake data):

  <dependency>
      <groupId>io.netty</groupId>
      <artifactId>netty-handler</artifactId>
      <version>5.0.0.Alpha2</version>
  </dependency>

  Vulnerabilities:
  CVE-2023-xxxx (High) - https://ossindex.sonatype.org/component/.........
  CVE-2023-xxxx (Medium) - https://ossindex.sonatype.org/component/.........
  CVE-2023-xxxx (Medium) - https://ossindex.sonatype.org/component/.........
  CVE-2023-xxxx (Low) - https://ossindex.sonatype.org/component/.........

[shaikhu]

As far as the output goes, may I ask for the following?

Great suggestions @mthmulders! For the severity text I used the following reference on the NVD website. I think this is consistent with with OSS index reports vuls.

1. I would prefer if MCS would not print all CVE's in a list of search results. I would prefer if the "Vulnerabilities" column was summarised, for example, "3 high, 1 medium, 5 low". Something like this (fake data):

See f11e909 and screen grab below

2. For the detailed output (only one artifact result, printed as XML/Groovy/...), I would prefer to see all the vulnerabilities, each on one line. It would be great if they were sorted by priority, then by age, and could include a link to a detail page. Something like this (again, with fake data):

See 35e5ffb and screen grab below

[mthmulders]

Thanks @shaikhu for the screen grabs and all your efforts so far! Really appreciate it!

I'm finalising a mechanism to let users pass JVM system properties through a configuration file (#255), would that be a suitable way to pass the credentials for that Sonatype API you're using?

[shaikhu]

Thanks @shaikhu for the screen grabs and all your efforts so far! Really appreciate it!

I'm finalising a mechanism to let users pass JVM system properties through a configuration file (#255), would that be a suitable way to pass the credentials for that Sonatype API you're using?

Look great @mthmulders! See 7dbcf1b and ed9001c. Also worth mentioning

1. Because we are using JVM system props, to test I had pass the properties using -D e.g. -Dossindex.uername=xxx -Dossindex.password=xxx
2. There is a bug which prevented me using PasswordAuthenticator. Instead I had to manually add the http auhtorization header as a work-a-round.

[mthmulders]

I'd love to have this contribution in MCS, @shaikhu. If you're OK with that, let's remove the 'draft' status and I'll go through the code.

A word of warning: I might be picky. This is absolutely not to disappoint you or mock you, it's because I'd love the code to flourish and be maintainable by myself (and possibly others).

[mthmulders]

I've run some manual tests and found a few issues. Could you please look into them?

[mthmulders]

I had an email with a question about artifacts without reported vulnerabilities, but I can't find it back here. Anyway,

• for the tabular output, I'd say "empty is just fine" (as it currently is).
• for the single output, maybe it's better to print "none reported" to make it explicit that we did query, but found none.

[shaikhu]

I had an email with a question about artifacts without reported vulnerabilities, but I can't find it back here. Anyway,

That was me sorry!

• for the tabular output, I'd say "empty is just fine" (as it currently is).

I deleted the question/comment and updated to print "-" with 639b16f. Happy to change back to empty space if you prefer.

• for the single output, maybe it's better to print "none reported" to make it explicit that we did query, but found none.

agreed. a20c616

[mthmulders]

I think all is fine now!

[mthmulders]

@all-contributors please add @shaikhu for code.

[allcontributors]

@mthmulders

I've put up a pull request to add @shaikhu! 🎉