Add trivyignore file to ignore false positive CVEs in security scan

[dandelany]

Description

This change mitigates certain false positives that appear during the security scan of our aerie-postgres container by ignoring them with a .trivyignore file, used by the trivy action which runs our scans.

Verification

To determine that these CVE's were in fact false positives, I worked with @skovati and we did the following:

• Checked the output from the aerie-postgres Publish workflow, security scan step, and found that the only remaining CVEs are the three in this PR, all associated with version 1.18.2 of gobinary's stdlib package
• On this DockerHub page we confirmed that the only usage of this stdlib package is from gosu, a small utility used to setup the postgres container
• We found this page on the gosu docs which explains how most Go CVEs are false positives for this tool, and how to confirm.
• We weren't able to get the ./govulncheck-with-excludes.sh script provided by this document to work correctly. However we validated a different way, using the regular govulncheck tool which checks specifically which parts of the Go library are being used by a binary:
  • Copied the gosu binary from the postgres machine to local machine with docker cp
  • Ran the regular govulncheck tool against this binary with the command govulncheck -mode=binary gosu
  • This produced only a single applicable CVE: GO-2023-1840 - Unsafe behavior in setuid/setgid binaries in runtime
  • ...and ^this specific CVE is explicitly excluded by the govulncheck-with-excludes script above, which explains in comments why it is a false positive/mitigated risk

Therefore, we believe these other gobinary stdlib CVEs from the security scan are all false positives in our case, and should be excluded from our scans.

Future work

Better process for tracking these down in the future?

[skovati]

Looks good of course besides the .trivyignore path issue

[Mythicaeda]

I took another look at the workflow. It turns out the repo isn't getting checked out at all in the scan subjob, meaning the file is inaccessible. This can be solved by either publishing the trivyignore as an artifact during the containers job and downloading it during the scan job or by checking out the repo at the start of the scan job.

[dandelany]

It turns out the repo isn't getting checked out at all in the scan subjob, meaning the file is inaccessible

Got it - thank you! Fixed. I had assumed that since the job needs: containers which needs: init it would be accessible, but I guess not. Seems to be passing all checks now (finally).

[Mythicaeda]

I had assumed that since the job needs: containers which needs: init it would be accessible, but I guess not.

Yeah, the quick summary on that is that each subjob is executed on a different runner (you can actually occasionally see a waiting for runner message if you watch the later jobs of, for example, the DB Comparison workflow), so the workspace is completely fresh going into each subjob.