Add CI-Level trivyignore

[zhijie-yang]

• [x] I have signed the CLA?
• [x] I am following the CONTRIBUTING guidelines

Ping the @canonical/rocks team.

---

Description

This PR adds a CI-level trivyignore to bypass the false positive vulnerability findings for the pebble binary in the bare-based rocks using the feature that trivyignores can be a comma-separated string to contain multiple bypass lists.

Related issues

https://github.com/canonical/chiselled-python/issues/26

[zhijie-yang]

If trivy still gives this "false positive" based on the Go version that pebble is built upon, then we have to wait until pebble is built upon the updated Go versions where this CVE is fixed, or the behaviour of trivy is optimised for vulnerability identification with Go binaries.

[cjdcordeiro]

If trivy still gives this "false positive" based on the Go version that pebble is built upon, then we have to wait until pebble is built upon the updated Go versions where this CVE is fixed, or the behaviour of trivy is optimised for vulnerability identification with Go binaries.

Yes but how would we know? I'm wondering if there is a way for us to be made aware when such whitelisting is not longer necessary.

I'm thinking about this cause I find it dangerous to commit and forget, as tomorrow this CVE might actually be applicable, but we've been ignoring it.

[zhijie-yang]

We can add a job in the continuous testing workflow, to test if we can pass the pipeline without the bypass list, and if this is the case, the workflow can create an issue in OCI-Factory to notice that we can remove the bypass list item.

[cjdcordeiro]

it's an idea to be explored, yes. It should also cover the remaining rocks' trivyignore files. let's add it to the backlog

[zhijie-yang]

We have another approach in #291. I think #291 is a more decent solution for the pebble issue for now.

[cjdcordeiro]

Fully agree! It was indeed already there, we just moved pebble :p

feel free to close this