feat: load rego embedded libs by default

[chen-keinan]

Signed-off-by: chenk [email protected]
Close: #925

[simar7]

hi @chen-keinan - we're trying to bring back policy fetching into trivy if a new bundle is found upstream. This is so that we can decouple trivy releases from policy updates.

tldr: Currently this behaviour doesn't allow trivy to download a bundle (with both policies and libraries in it) as libraries are unconditionally embedded into the trivy binary, causing rego namespace collisions. Bundle will include both policies and libraries. Context is here: d128e52#r86794387

I understand you had made this change to solve https://github.com/aquasecurity/defsec/issues/925 - is it possible we (for the users of trivy operator) can provide the libraries in another way? Maybe they could be stored as configmaps within the operator deployment charts? Just a thought.

Ideally, it'd be best to keep policies and libraries together behind the same flag. In other words, if loadEmbedded { should gate both the policies and libraries as decoupling the two introduces situations where you can have potentially have a mismatch (old libraries, new policies) or rego namespace collisions (this scenario).

Thoughts?

[simar7]

cc @liamg @itaysk

[simar7]

Created #1012 to address this.

[chen-keinan]

hi @chen-keinan - we're trying to bring back policy fetching into trivy if a new bundle is found upstream. This is so that we can decouple trivy releases from policy updates.

tldr: Currently this behaviour doesn't allow trivy to download a bundle (with both policies and libraries in it) as libraries are unconditionally embedded into the trivy binary, causing rego namespace collisions. Bundle will include both policies and libraries. Context is here: d128e52#r86794387

I understand you had made this change to solve #925 - is it possible we (for the users of trivy operator) can provide the libraries in another way? Maybe they could be stored as configmaps within the operator deployment charts? Just a thought.

Ideally, it'd be best to keep policies and libraries together behind the same flag. In other words, if loadEmbedded { should gate both the policies and libraries as decoupling the two introduces situations where you can have potentially have a mismatch (old libraries, new policies) or rego namespace collisions (this scenario).

Thoughts?

sure , lets discuss the options

[simar7]

hi @chen-keinan - we're trying to bring back policy fetching into trivy if a new bundle is found upstream. This is so that we can decouple trivy releases from policy updates.
tldr: Currently this behaviour doesn't allow trivy to download a bundle (with both policies and libraries in it) as libraries are unconditionally embedded into the trivy binary, causing rego namespace collisions. Bundle will include both policies and libraries. Context is here: d128e52#r86794387
I understand you had made this change to solve #925 - is it possible we (for the users of trivy operator) can provide the libraries in another way? Maybe they could be stored as configmaps within the operator deployment charts? Just a thought.
Ideally, it'd be best to keep policies and libraries together behind the same flag. In other words, if loadEmbedded { should gate both the policies and libraries as decoupling the two introduces situations where you can have potentially have a mismatch (old libraries, new policies) or rego namespace collisions (this scenario).
Thoughts?

sure , lets discuss the options

Previously, in the case of Trivy for using custom policies the users have to supply their own libraries in case they need them. Having said that, maybe we can instead create a reference deployment in Trivy Operator (example helm chart, for instance) that includes some scaffolding to help them do so?

Long term, decoupling policies from Trivy binary helps us as policies get updated often compared to Trivy itself. This is the same model that Trivy DB follows for updating vulnerability definitions.

What do you think? Maybe we can jump on a call and sort it out.

[chen-keinan]

What do you think? Maybe we can jump on a call and sort it out.

@simar7 sure I'll be happy to have a call to discuss it