Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add SBOM in sync-request metadata #43

Merged
merged 1 commit into from
Jan 29, 2024

Conversation

felipecruz91
Copy link
Contributor

This PR extends the sync-request metadata to include the new SBOM field. The Scout CLI will use this field when evaluating a policy locally to send the SBOM to the policy skill. The policy skill will consume it to build the mocks locally.

This is piece of work is part of https://www.notion.so/dockerinc/Local-evaluation-Add-support-for-local-attestations-containerd-5a692d03dda94fd1970565113f1c7127?pvs=4.

Copy link
Contributor

@rnorton5432 rnorton5432 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is duplicating some work that's already been done, unless I'm missing something about how the local evaluation with containerd will work. If it's still being run from scout-cli, I don't think this is needed.

"olympos.io/encoding/edn"
)

func BuildLocalEvalMocks(sb *types.SBOM) map[edn.Keyword]edn.RawMessage {
Copy link
Contributor

@rnorton5432 rnorton5432 Jan 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is already handled in this package here, do we specifically need to pass the sbom from the cli tool to the evaluator?

Fwiw, scout-cli-plugin also already does this mock, which takes precedence in go-skill if passed (so if the fields need to be expanded we can update scout-cli-plugin once instead of updating this repo and all policy repos).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we would like to use the existing SBOM struct as a standardised API for synchronous policy evaluation.

That struct encapsulates basically all the useful information that we have about a given image, so we can make changes to policies and introduce new policies without needing to rely on any CLI changes to pass new data.

It also gives us a way of getting local attestations (with the help of containerd) into policy evaluation.

Copy link
Contributor

@rnorton5432 rnorton5432 Jan 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I see the idea now. And now that I think about it, I agree it's the right move as well.

Two follow-up thoughts then:

  • This won't be a "legacy" thing if it's how we're planning to do local eval in the long-run, so let's not put it in the legacy package.
  • Let's try to remove the corresponding mocking logic from go-skill and scout-cli-plugin as we are given opportunities to, so that we don't end up holding onto them for some cross-project version combinations.
    • The packages query mock in this repo will need to remain to support old CLI versions.
    • The user query mock in this repo is released and used by non-root-user-skill, so we'll need to hold onto it for a while as well.
    • The packages mock in scout-cli-plugin that I linked above is not used by any released skills, to my knowledge. Once this PR is merged, I'll make sure policy-vulnerabilities is updated to use the SBOM version, and the mock is removed.

@felipecruz91 felipecruz91 merged commit faa37b7 into main Jan 29, 2024
2 checks passed
@felipecruz91 felipecruz91 deleted the feature/sbom-sync-request branch January 29, 2024 10:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants