Confusion over how to get started..

[jnach]

[root@bastion ~]# vexctl attest --attach --sign mydata.vex.json cgr.dev/image@sha256:e4cf37d568d195b4..
Error: generating attestation: opening vex data
FATA generating attestation: opening vex data
[root@bastion ~]# vexctl attest --attach --sign mydata.vex.json alpine:latest
Error: generating attestation: opening vex data
FATA generating attestation: opening vex data

Unsure at this point if this is a bug or a misunderstanding in the way generation works.

[root@bastion ~]# vexctl version
 _   _  _____ __   __ _____  _____  _
| | | ||  ___|\ \ / //  __ \|_   _|| |
| | | || |__   \ V / | /  \/  | |  | |
| | | ||  __|  /   \ | |      | |  | |
\ \_/ /| |___ / /^\ \| \__/\  | |  | |____
 \___/ \____/ \/   \/ \____/  \_/  \_____/
vexctl: A tool for working with VEX data

GitVersion:    v0.0.2-32-g417bc2a
GitCommit:     417bc2af1e4e897dc8b88b704f150c9fe84b8c8c
GitTreeState:  clean
BuildDate:     2022-11-28T22:33:47Z
GoVersion:     go1.18.4
Compiler:      gc
Platform:      linux/amd64

Happy to make a more thorough report if this is unexpected. There is no SElinux on this system, the file was created in advance and permissions relaxed, it was ran as root. No joy for working generation.

[puerco]

Thanks for raising the issue @jnach ! Yeah that error points to a problem reading the vex data.

Those command invocations are going to try to attach the attestation to cgr.dev/image and alpine:latest I'm not sure if that was intended or if they are merely examples.

Can you share your vex file to see the format you are using?

Thank you!

[jnach]

That makes a lot of sense.. is that something I need to source from CISA prior? I think I saw the word 'generate' and that's ultimately the source of the confusion. I don't yet have a vex file and need to figure out how to get one (is there a big master one? Is this per container image? I'm very excited at the promise of this and also have a lot of questions, happy to pad a README once past this part)

[puerco]

Ah got it. "generate" there means generating an attestation. Let me make that clearer:

The commands you issued earlier let you transfer VEX data from an existing vex statement, say a CSAF file, to an attestation that is stored with the container images you specified.

A use case would be if you have a product that ships in container images and you need to issue vex data with them. You write a VEX file containing your analysis and you can start to automate attaching the vex data once you build new ones. This solves the problem of discovering vex data for your images.

Can you detail what you are trying to do to see how we can help? :)

[jnach]

I want to compare 3 well known images from scratch, alpine, RH ubi, and node:latest, to demonstrate what to expect as far as results in a very basic supply chain security scenario, and how something like Vex will help reduce the 'noise' factor.

In the 'explain like I'm 3' place I'm coming from, the only thing I know about where to start is CISA is recommending this, and vexctl seems to be the most prominent way to interact with this data, against an SBOM (which I am very familiar with), in SARIF format, which I am also very familiar with. Looking at the documentation, I understand how this JSON patch sorta has to work and why SARIF is an expectation, and have done quite a bit of go programming, all is well.

What I don't know anything about is what an attestation, which you have helped contextualize as something that needs an input and produces an output (makes sense), or an existing vex statement is.

So, I do not have an existing vex statement, and I do not have an existing mydata.vex.json file, which means intuitively sourcing this is what the missing context is. Where does the original *.vex.json file come from? and/or.. what pre-requisites are expected prior to being able to run the example command coming from absolute scratch? This is what I am trying to understand.

[jnach]

It's also possible the expectation is that one creates and brings their own 'vex' file.. but that would be good to communicate too.

I'm working off of this: https://www.chainguard.dev/unchained/putting-vex-to-work

[puerco]

What an attestation does in this context is to say "this vex data applies to this image".

If you think about it, what VEX captures is an expert's assessment of a vulnerability affecting (or not) a product. When generating container images, your builds are going to be released frequently, at a much faster cadence than your VEX analysis. So vexctl lets you read and reuse that analysis, making it discoverable by attaching it to your images as they ship.

For now, the source VEX data is expected to exist already, either in a csaf doc or in a json file. Would it help if the tool helped you create it?

[jnach]

I guess this all boils down to, where does it come from? Do I create it myself or is this something I can find somewhere and follow the tutorial?

[puerco]

Yes you create the file as the maintainer of your project. VEX statements will generally come from the product supplier, that is you if you are the author of the software.

[jnach]

Okay, all makes sense now. Thank you!

[puerco]

Thank you! Let me know any other questions!

[jnach]

Would it be fair to suggest and/or insinuate that this sort of data should come from an investment in a penetration tester and/or otherwise be authoritative from someone who can certify the applicability of an issue being a problem or not? I realize this is a big area, but to trust a self-provisioned system like this, you would need to trust the impact evaluation itself.