Updater for java/jdk vulnerabilities

[suneel putta]

Hello Team,

We have been using clair actively for couple of months now.Since most of our microservices are java based, I wonder if we can configure clair so that updater starts harvesting java/jdk vulnerabilities.

If its doable then can you please let me know where do I configure it, right now we are using Clair4 in our k8s environment in combo mode.

Thanks and Regards

--

--Suneel

[Hank Donnay]

Hello,

On Fri, Jul 16, 2021 at 12:05:23PM +0530, suneel putta wrote:
>We have been using clair actively for couple of months now.Since most of
>our microservices are java based, I wonder if we can configure clair so
>that updater starts harvesting java/jdk vulnerabilities.

In Clair's terminology, an "updater" provides vulnerability data to
match against. A "scanner" examines layers for various interesting
features.

There's already a jar scanner that runs by default. There isn't,
however, an updater that pulling in some vulnerability database for
java projects. So, the first step would be finding such a data source
(under a suitable license) and then building an updater to pull that
data into Clair.

--
hank

[Paul Aldridge]

Hey Hank,

Sorry to dig up an old thread, but this was interesting as I was having a look at what support clair had for java as I’d seen it mentioned in the code. Could you help me understand what the jar scanner achieves without an updater for java?


Looking at this issue where the java scanner was introduced (https://github.com/quay/claircore/issues/236), I think it is saying that it relies on a remote matching source that isn’t included in clair as default, or written to the database. But I wanted to check my understanding of that was correct, and if anything is done with the data from the scanner without this. Thanks!

Paul

[Hank Donnay]

On Tue, Dec 14, 2021 at 02:46:04AM -0800, Paul Aldridge wrote:
>Sorry to dig up an old thread, but this was interesting as I was having a
>look at what support clair had for java as I’d seen it mentioned in the
>code. Could you help me understand what the jar scanner achieves without an
>updater for java?

Yeah, without a matcher-updater pair, the individual feature scanners
don't do a ton. Their results are just passed to the client.

>Looking at this issue where the java scanner was introduced
>(https://github.com/quay/claircore/issues/236), I think it is saying that
>it relies on a remote matching source that isn’t included in clair as
>default, or written to the database. But I wanted to check my understanding
>of that was correct, and if anything is done with the data from the scanner
>without this. Thanks!

The CRDA matcher was updated and re-added to the defaults, so there's a
matcher as of now. It's a "remote matcher", so there are a host of
caveats with it, but it does work.

A normal updater would be preferable, but we haven't found a database
with suitable usage terms.

--
hank

[Paul Aldridge]

Thanks Hank, really appreicate you explaining! I will try to have a read into the code for the remote matchers and CRDA when I can, forgive my ignorance for now. Will the CRDA matcher you mentioned be working as default then? i.e. we'd be finding and reporting java vulnerabilities. Or does it require additional configuration?

[Hank Donnay]

On Tue, Dec 21, 2021 at 01:41:22AM -0800, Paul Aldridge wrote:
>Thanks Hank, really appreicate you explaining! I will try to have a read
>into the code for the remote matchers and CRDA when I can, forgive my
>ignorance for now. Will the CRDA matcher you mentioned be working as
>default then? i.e. we'd be finding and reporting java vulnerabilities. Or
>does it require additional configuration?

Yeah, it's enabled by default. An API key can be requested and
configured to get a better rate limit, rather than the community bucket.
That's linked here: https://github.com/quay/clair/blob/main/Documentation/concepts/matching.md#remote-matching

--
hank