Determine attestation format for vuln scans

[dlorenc]

Description

From a slack conversation with @developer-guy @Dentrax and @joshuagl, capturing it here so I don't forget!

We've already discussed support for signing/verifying/storing attestations, using the In-Toto model: https://github.com/in-toto/attestation, and @developer-guy brought up a common use case around storing vulnerability scan reports for an image in the registry.

Storing scans is slightly problematic in that the scan results are timely, a scan with no vulnerabilities a month ago doesn't mean that the image has no know vulnerabilities today. Rather than storing scan results directly, we can convert them into an attestation, by adding a timestamp and a signer.

Rather than saying "this has no vulnerabilties", the statement becomes "this had no vulnerabilities as of $TIME, as seen by $SIGNER". Then the $SIGNER signs this, making it a formal attestation.

Policy engines can then rely on these, and policies can be written in the form of "there must be a clean scan report within the last X days".

I think to implement all of this in cosign, we would do something like:

• define a new provenance predicate either here in cosign or in the in-toto repo to convey a timestamped scan report.
• add some cosign commands:

cosign sign-attestation -f <attestation>
cosign attach attestation -f <attestation> <img>

We can still use all of the KMS/key/ephemeral support for signing - but these are slightly different from the rest of what cosign works with, as the attestation itself is signed, not the OCI image wrapper. The scan report would be generated and timestamped, then cosign would sign the file locally (similar to sign-blob). Then the signed blob can get attached to an image.

Does this all make sense?

[trishankatdatadog]

Does this all make sense?

Yeap, at a cursory read, saying vuln scans have element of time attached to it makes sense

[dlorenc]

Or as Santiago just brilliantly came up with:

cosign attest -f <attestation> <img>

to do the signing, uploading and attaching!

[NitinJain2]

Storing scan results directly in the attestation has some advantages. For example, an important use-case for Binary Authorization customers is allow-listing certain vulnerabilities in the policy. They typically author policies of the form "No critical vulnerabilities allowed, except when the vulnerability is in the following allow-list: [CVE-1111, ..., CVE-9999] ".
Additionally, customers can change their policy between the vulnerability scan and image deployment. For example, their policy initially may be "No vulnerabilities", but they may later change it to "No critical vulnerabilities". Storing scan results directly in an attestation can help with this use-case, without requiring customers to generate a new attestation.

[dlorenc]

Makes sense! Thanks @NitinJain2! Are you aware of any specific vuln scan report formats?

[Dentrax]

Something like Static Analysis Results Interchange Format (SARIF) scan report format?

[dlorenc]

Perfect! Do snyk/trivy etc support that?

[Dentrax]

Not sure about Synk since CLI Reference does not point it out, but Trivy have a template for that. And most of analyzers have a support for SARIF output. (i.e., Kics, Dockle, etc.)

[Dentrax]

I dig into some important tools to check whether they have support. What I have found are the following:

Tool	PATH
Kics	https://github.com/Checkmarx/kics/blob/master/pkg/report/model/sarif.go
Dockle	https://github.com/goodwithtech/dockle/blob/master/pkg/report/sarif.go
Trivy	https://github.com/aquasecurity/trivy/blob/master/pkg/report/template.go
Synk	https://github.com/snyk/snyk/blob/master/src/lib/formatters/sarif-output.ts
Semgrep	https://github.com/returntocorp/semgrep/blob/master/semgrep/semgrep/formatter/sarif.py

I think SARIF is one of the industry standard format for the security scan results. We can start implementing it first. For the next steps, we can easily add support for different type of scan result formats. 🤔

[dlorenc]

Retitling this to settle on an attestation for vulnz!

[Dentrax]

I think @developer-guy we are currently working on predicate spec schemas to propose some spec samples about this:

We can enrich the following structure:

{
  "_type": "https://in-toto.io/Statement/v0.1",
  "subject": [
    {
      "name": "alpine",
      "git_commit": "a1b2c3",
      "digest": {
        "sha256": "c201c331d6142766c866"
      }
    }
  ],
  "predicateType": "cosign.sigstore.dev/sarif/v1",
  "predicate": {
    "timestamp": "1627564731",
    "owner": {
      "name": "<WHO_RAN_THIS_SCAN>"
    },
    "environment": {
      "name": "GitHub",
      "by": "<PIPELINE_ID>",
      "type": "<CI/CD?> (i.e., GitLab Runner)",
      "cluster": "us-east1-a.prod-cluster",
      "namespace": "<namespace>"
    },
    "success": true,
    "scanners": [
      {
        "name": "trivy",
        "version": "0.19.2",
        "db": {
          "name": "trivydb",
          "version": "v1-2021072912"
        },
        "timestamp": "1627564731",
        "result": "<SARIF RESULT HERE?>"
      },
      {
        "name": "dockle",
        "version": "v0.3.15",
        "timestamp": "1627564731",
        "result": "<SARIF RESULT HERE?>"
      }
    ]
  }
}

Wdyt, folks?

[dlorenc]

"signer": {
    "by": "cosign",
    "signature": "SHA-XXX.sig",
    "timestamp": "1627564731"
  },
  "signed": {
    "name": "<PROJECT_NAME>",
    "image": "<IMAGE_REF>",
    "url": "<PATH_TO_PROJECT_URL>"
  },

Hmm - what's this section for? It looks redundant maybe with the rest of the attestation format (where the signature is over the entire statement)

[Dentrax]

Oh yeah! signer seems a bit redundant. Not sure but, I think it's better if signed (or smth like) there since we need to know which project and image is scanned, at the end of day. 🤔 i.e., alpine (registry.foo.com/images/alpine:v0.1)

[dlorenc]

Sorry I think I'm still missing something... Wouldn't the image info for alpine get included in the Subject field of the Statement? It's in the header for all the predicates.

Something like this:

[Dentrax]

I see! I forgot to include subject field. We updated (edited) the aforementioned predicate spec schema!

CC'ing @MarkLodato @joshuagl for the feedback and further ideas about the current structure. 😇

[dlorenc]

Nice! looks great. One nit: I think the predicateType: SARIF part should actually point to some kind of URI. It could point to something like "cosign.sigstore.dev/sarif/v1".

[Dentrax]

The main question is... How should we generate such a big predicate spec in efficient way. Let's assume there's more than 5+ scanner results. Should we need to create something like attestation-generator at the end of the day? Somehow, we have to feed every field that defined in the spec (i.e., passing by flags, a .tpl file, env substitution, etc.). Wdyt @developer-guy?

[developer-guy]

Yeah, sounds cool @Dentrax, that would be great IMHO because people have to create a corresponding attestation spec that fits their needs; if we can develop that kind of tool, we make their life more straightforward to work with attestation specs before signing and verifying them in their CI/CD pipelines.

[dlorenc]

@developer-guy @Dentrax any updates here? Need any help?

[Dentrax]

@developer-guy @Dentrax any updates here? Need any help?

Actually, we still continue to discuss this on in-toto/attestation#58 issue. Any help would be appreciated to decide the final proposal for the spec. 🤗

[Dentrax]

Just found go-sarif project, capturing here so we might use it. 🤷‍♂️

[hectorj2f]

@developer-guy @dlorenc I think this is covered as part of cosign attest .... Please, correct me if i am done.

[developer-guy]

Hello, we (w/@Dentrax) thought that there is a huge potential is lying in here 🤩 So, let's liven it up 🚀

Let's summarize the steps that we'll follow at the beginning to accomplish this:

1. We've defined a spec recently on how people can specify Vulnerability Scan Record, please see for the latest changes, IMHO, it requires more agreement, but at least we can move forward with baby steps.
2. Define Go structs according to the spec we defined.
3. Once the model is ready, we can start uploading this spec into the OCI registry alongside an image with a special suffix like .vuln, with making use of cosign attach vuln.

WDYT?

[dlorenc]

3. Once the model is ready, we can start uploading this spec into the OCI registry alongside an image with a special suffix like .vuln, with making use of cosign attach vuln.

Since it's an Attestation, would we need a separate suffix? I was thinking these could all live in the .att bundles.

Everything else sounds amazing!!!