Missing feature when migrating from tfsec

[jrobison-sb]

We have a terraform repository with hundreds or thousands of resources which have already been built prior to using tfsec / trivy. We've been using tfsec successfully for a long time, but eventually we need to migrate to trivy since only trivy will still be under active maintenance. We currently can meet all of the following requirements with the tfsec action:

1. If a PR proposes new code which violates a security rule, the new code should be flagged with a failed PR check and/or a comment in the PR.
2. A PR should never fail a status check because of code that isn't changing in a given PR. For example, if lines 1-100 in a given file already exist and maybe even contain violations of security rules, and someone's PR appends 10 new lines of code to that file (lines 101-111), that PR shouldn't get rejected because of any violation which exists in lines 1-100.
3. We are able to use private repositories with the GitHub Team plan and we aren't forced to upgrade to GitHub Enterprise.

Am I able to meet all those requirements with Trivy currently?

When I try using Trivy as seen in the example in a public repository (which means I have access to GitHub Advanced Security), I'm able to meet requirements 1 and 2. An example PR will fail a status check because of insecure code within that PR (requirement 1) and it doesn't flag any other code which isn't in the PR (requirement 2). But that's a public repository, so it doesn't meet requirement 3.

When I try using Trivy in our real private repository, using the same GitHub Actions configuration which uses aquasecurity/trivy-action@master and github/codeql-action/upload-sarif, then github/codeql-action/upload-sarif isn't able to upload the sarif file because Advanced Security only works if your repository is public or you have GitHub Enterprise. So this doesn't meet requirement 3 either.

I have also tried a workaround like using sarif-to-comment-action, but that will leave a comment on a PR which contains the entire sarif file. That sarif file will contain entries which may or may not have anything to do with the lines being changed in the PR (mostly lines which have nothing to do with the PR). So this doesn't meet requirement 2.

Is there there any way to hit all three requirements with Trivy currently?

Thanks.

[simar7]

Hi, I'm not sure how tfsec action is able to meet requirement 3 as we have no control over it. The Advanced security limitation is enforced by GitHub, not by Trivy. Can you please elaborate?

[jrobison-sb]

@simar7 thanks for taking the time to read this issue.

Both tools (the tfsec github action and also the trivy github action) run a scan and then post the relevant results of the scan to a GitHub API endpoint as a means of presenting the results to the user.

The tfsec action is able to meet requirement 3 because when it presents results to the user, it does so using the GitHub issues API endpoint to leave a comment on a PR. This API endpoint and this means of presenting information to the user works on any GitHub plan (free, paid, pro, team, etc). Or in other words, if the notification to the user looks like this, it works with any type of plan/repository:

The trivy action doesn't meet requirement 3 because when it presents results to the user, it does so by uploading results to the dependency-graph/snapshots API endpoint, and this mechanism of presenting results to the user only works on certain GitHub plans. Or in other words, if the notification looks like this, it only works with certain GitHub plans:

Is there any way to make the trivy action use the issues endpoint to leave plain old PR comments, which would work with all types of GitHub plans?

[simar7]

I see. Thanks for the explanation @jrobison-sb. We built Trivy-action with the snapshots api in mind as we're able to expose the results in a format that it expects. This is important as the snapshots API is also something that the GitHub code scanning can use as input, making Trivy a fully integrated code scanner on GitHub.

At the moment we don't have plans to add support for the issues endpoint as I don't think it aligns well with the intended use of Trivy GitHub Action, which is being a code scanner first and foremost. But we will certainly keep this use case in mind and appreciate you bringing it up.