#Supply chain security, SBOM, etc.
narrow dust
Works for me! 😂
I’d love to get a playlist or just chat. I’m fairly booked up tomorrow, but Friday is wide open for me
mortal shore
I am biased but believe CUE is the perfect language for modeling your dependency graph
narrow dust
I’ll admit I haven’t spent enough time with CUE to say if it would or wouldn’t 😆 It’s on my bucket list of things to explore. Fortunately, we kicked off our pilot for our platform here on campus, so I finally have a little time to breathe and do some exploration.
mortal shore
We could di an exploration session together if you’d like
I’m curious about this whole SBOM business. We could try mocking up your ideal SBOM in Cue
narrow dust
I’d like that! And I can show you a little bit of what I’m doing with my experiments. It’s still very rough right now, but can show the idea of what I’m thinking about.
marsh hound
@narrow dust let’s aim for Friday then
Also one note, the SBOM itself is meant to be static but feeds into dynamic systems
narrow dust
@marsh hound Sounds good! I’m EDT and open all day. And yeah… get that about the SBOM. Is there a doc on the structure/format I can look over before we chat? Quick Google searches haven’t given me any standard definition (if one even exists)
narrow dust
Fantastic! I’ll take a look at those 👍
marsh hound
@narrow dust I’m still building this: https://docs.google.com/presentation/d/14t_B2VrKqLDHZ6pPV7siSowRoAR7ZeRanbnxBOnrIBs/edit
marsh hound
@narrow dust my kubecon keynote was just posted recently
It’s more generic because it’s aimed at a very broad audience
But it says the main topics
marsh hound
@mortal shore @narrow dust I have calls today from 11:00-11:30 and 12:30-1:30 all pt
Free at all other times
Let me know what works for you both
mortal shore
Can’t today, sorry. Too much going on. You can start without me I can join the fun next week 🙂
marsh hound
Not a problem
I have ideas for cue
I want to run them past you later on if you have time
Also, do you know if there is an xml parser for cue?
Would be useful to have a way to map values in an xml doc to cue
mortal shore
Excellent question. I don’t know but maybe @hybrid gull and @vivid nymph do
marsh hound
Maybe I should just go grab an xml to json tool and call it a day 😉
SBOM formats tend to be xml
hybrid gull
@marsh hound There isn't currently one, as far as I'm aware. I know it's been discussed to some degree.
mortal shore
Maybe I should just go grab an xml to json tool and call it a day 😉
Then you can wrap that tool in a Dagger action that runs it in a container and exposes a Cue interface for it
marsh hound
That’s what I was thinking 🙂
Verify the signature, import, expose as a cue interface
Then I can start integrating other tools like matching to CVE databases, license enforcement, vex
mortal shore
import “universe.dagger.io/xml”
mydata: { hello: “world” }
myxml: xml.Encode(mydata)
mydata2: xml.Decode(myxml)
(with auto-calling containers in that path as needed 🙂
marsh hound
Is that real or a possible future?
mortal shore
Real
Sorry
that package does not exist
But you can write it with today’s version of Dagger
marsh hound
That makes sense
mortal shore
I’m guessing it’s 30 lines of Cue max
marsh hound
Once encapsulated then it goes everywhere 😄
Would you be comfortable with this being contributed to dagger?
mortal shore
Yes definitely. First step would be an external package
marsh hound
imo this is something that everyone should have access to
mortal shore
What, the xml package?
marsh hound
Supply chain provenance work
Could start with xml 😉
Also ok with it being an external package if that’s a better approach
Eg extract and expose SPDX or CycloneDX into cue as an interface
narrow dust
Watched the keynote. nicely done @marsh hound ! We can loop back sometime early next week. My Monday and Tuesday are fairly flexible right now. I'll do some reading on SPDX and CycloneDX in the meantime
mortal shore
I’m very excited that this conversation is happending, and that I get a chance to follow & participate 🙂 Thanks guys
narrow dust
Alrighty... I have a fairly good feel for the formats. Is there any discussion on methods to associate/attach a SBOM to a container image/manifest/layer/something?
marsh hound
there is some work done in the k8s community around SPDX
there's also several language specific tools coming up
right now, the NTIA is running SBOM plug fests for both producers and consumers
we'll see what tooling is available and the maturity
narrow dust
Gotcha. I found a Node one for CycloneDX and have played with it. Pretty straight forward and easy to use. Haven't looked in the SPDX space quite yet. Just thinking about if there are ways to associate a SBOM to a built container image, where a build pipeline produces an image, the SBOM, but then someway to connect the two (if I publish the image, how can someone find the SBOM?).
This project looks pretty nice too... https://github.com/anchore/syft
marsh hound
so something like syft i think are ok for post-release analysis, but ideally the SBOM is created at build time in the CI/CD env
that way we can correlate the source materials to the resulting artifacts
i do like syft, but am concerned people will select tools like this and declare victory rather than look deeper
narrow dust
Makes sense. Almost thinking of making a small PoC of a build pipeline that creates an image, maybe uses syft (for now) to create the SBOM for the new image, and then publish it... somewhere. Is there any guidance on where the SBOMs should be distributed? As an OCI artifact? Baked into the image itself?
mortal shore
So if, for example, I used the Cue package alpha.dagger.io/alpine to assemble my Alpine base images, would it be useful if that package automatically produced the corresponding SBOM content? (alpine version, list of installed packages etc).
Then I could use Cue to aggregate such content from the various actions in my DAG, to produce the final SBOM
narrow dust
That would be pretty slick and would help solve the problem of knowing what’s on the SBOM for multi-stage builds too
mortal shore
SPDX seems very.. file oriented ?
marsh hound
they both are, and that needs to change
i have something brewing which is going to look at contents and track through a compiler pass
changes to gcc and llvm which can give provenance to intermediate objects
even then, i don't think it goes far enough
long term goal should be: someone copies something from stack overflow that has a vulnerability. we discover the vulnerability, how do we trace everywhere that code was used?
mortal shore
is this possible without changing the formats? They seem pretty entrenched
marsh hound
it is, and i have some compiler devs who have indicated that they want to implement something towards this
three of us: me, a top eng from cisco, and another from microsoft got together and created a receipting system which can be used to help track these types of systems
have you met Aeva?
narrow dust
I have not. Sounds like a pretty interesting idea.
marsh hound
the format is super simple, doesn't actually include the content
its a receipt system
for how sboms will be distributed, that's an open issue
there is something proposed to go into OCI from Microsoft
In short they want to provide the ability to store and send metadata
part of the problem is the metadata may be different for different orgs
e.g. i may have a repeatable build, compile it, upload it... ends up with the same content hash as another org
so the sbom itself, the provider metadata may be different despite the artifact being bit by bit the same
or someone may need to update it to fix a metadata error
ideally SBOMs are signed at a point in time
i've been pushing to get a pointer to the previous SBOM
pair it with sigstore, ensures the artifact can't be modified without someone noticing it even if keys are compromised later on
marsh hound
An article I wrote up on generating an SBOM with cyclonedx
@mortal shore @narrow dust ^^
I'm going to analyze the contents later
marsh hound
analysis is at https://zt.dev/posts/analysis-cyclonedx-gomod-sbom/
here's the sbom i generated for the main branch on dagger/dagger using this tool: https://gist.github.com/fkautz/12b90167d34e4367151440f9b3f34b9d
this one contains all the hashes for every file
so it's quite large, ends up with 2.1M xml file
marsh hound