feat(spec): remove invocate in vuln predicate

[masahiro331]

Ref: #1381

Summar

Many vulnerability scanners are unaware of the type of environment in which they are used.

The consensus in some issues for this spec seemed to be to remove invocation.

• [Help Wanted] Determine attestation format for vuln scans in-toto/attestation#58 (comment)
• Clarifying questions re: cosign vulnerability attestation spec #1381 (comment)

Release Note

• Remove invocation in vuln predicate.

Documentation

Need to fix the sample YAML.
https://docs.sigstore.dev/policy-controller/overview#configuring-policy-at-the-clusterimagepolicy-level

[masahiro331]

@jdolitsky @dlorenc

My apologies to direct PR.

I wish to reopen and finalize the discussion against this specification.

[dlorenc]

@jdolitsky @dlorenc

My apologies to direct PR.

I wish to reopen and finalize the discussion against this specification.

Are you hoping to merge this?

[masahiro331]

@dlorenc

Yes, I hope.

I'm a contributor to Trivy.
It is difficult to meet these specifications when supporting the intoto_attestation format as the output of Trivy's vulnerability detection results.

If supported, it must take environment information as an argument.

As another discussion, there is a question as to which one should be set if the job that runs Trivy is different from the job that runs cosign.

[masahiro331]

Trivy's issue.
aquasecurity/trivy#1646

[masahiro331]

@dlorenc

The discussion on Invocation had stopped, so I reopened via PR.

If possible, we would like to check if it is optional as well as scanner.db.
Currently, there is no specification for invocation, so we don't know if it is required.

[dlorenc]

Cc @puerco can you double check this one?

[puerco]

I don't want to revive what appears to be done discussion just because of it, but I actually think having the parameters of the scan captured in the invocation is useful. They may be optional if needed but their usefulness is there.

I feel there is value in capturing the parameters and environment in a standard way. While the scanning service can expose its inner state in its own output, I think we should capture those flags from outside of the scanner because of a) trust and b) because we cannot guarantee all scanner actually embed the data in their output.

Take for example these two examples. Running Trivy with and without --severity CRITICAL to scan the current alpine image gives me a total of

With --severity CRITICAL: 0 vulnerabilities
Without that same flag: 4 vulnerabilities

Yet, the output of the scan does not capture the runtime configuration, and even if it did, I think it is easier for a system replaying the attestation to read the invocation params and environment from a standard location.

[github-actions]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[github-actions]

This PR was closed because it has been stalled for 10 days with no activity.