Do not run snyk pr comment workflow on forks

[trevorwhitney]

Only run the vulnerability scan jobs on PRs from branches, not on forks.

The other option here would be to change the on to pull_request_target, but I'm not confident we could still run the snyk scan in that case as it relies on secrets.SNYK_TOKEN. This action is more informative anyway, so I'm fine with only running it on branches.

[github-actions]

Trivy scan found the following vulnerabilities:

• HIGH openssl: Incorrect cipher key and IV length processing in libcrypto3 v3.1.2-r0. Fixed in v3.1.4-r0
• HIGH openssl: Generating excessively long X9.42 DH keys or checking excessively long X9.42 DH keys or parameters may be very slow in libcrypto3 v3.1.2-r0. Fixed in v3.1.4-r1
• HIGH openssl: Incorrect cipher key and IV length processing in libssl3 v3.1.2-r0. Fixed in v3.1.4-r0
• HIGH openssl: Generating excessively long X9.42 DH keys or checking excessively long X9.42 DH keys or parameters may be very slow in libssl3 v3.1.2-r0. Fixed in v3.1.4-r1

[MasslessParticle]

Wouldn't this disable security scanning on community-submitted PRs? Is there a way we could do that?

[trevorwhitney]

It's just the scan that produces the comments like the one above. The problem is PRs from forks don't get ${{ secrrets.GITHUB_TOKEN }}, and so they can't comment. We can try changing the trigger to on: pull_request_target, but then we'd have to lose the SNYK_SECRET we're using. Snyk might work without that since I think the secret is only for reporting back up to your project on their SaaS service, so I can try that?

[trevorwhitney]

@MasslessParticle so yeah, snyk needs a security token: https://github.com/grafana/loki/actions/runs/6884061084/job/18725837632?pr=11240.

So our options are:

1. only run this on PRs from branches, not forks
2. change to on: pull_request_target but remove snyk
3. split this up into 2 workflows. change the trivy workflow to on: pull_request_target, and guard the snyk workflow to only run on PRs from branches.

[MasslessParticle]

That makes sense. I think two workflows makes the most sense. I've approved this because it looks good and seems like one of the two needed workflows