OpenSSF SLSA Biweekly, 18 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SLSA Tooling Meeting (November 18, 2022)

Description

Meeting notes: https://docs.google.com/document/d/15Xp8-0Ff_BPg_LMKr1RIKtwAavXGdrgb1BoX4Cl2bE4/edit#heading=h.yfiy9b23vayj

A

Give it a few minutes for some folks to join and uh feel free to add your attendance to the meeting.

A

A

A

Yeah, we'll give it another couple minutes for some folks to join, and anybody who has joined recently just feel free to put your stuff in the attendance there.

A

All right yeah, we can get started um for folks who are joining now feel free to add your attendance to the meeting and anything that you want to add to the agenda.

B

um As a reminder, this meeting is being recorded, it'll be uploaded to.

A

Youtube, um shortly after and your participation in this meeting is an agreement to abide by the openssf code of conduct.

A

Okay, um so I.

B

Know it's been a quiet few weeks, um uh so let me start off um if anybody is sort of new to this meeting, who wants to introduce themselves feel.

A

Free to um introduce yourself.

C

So hello I'm, a professor at NYU and active in like tag security, uh tough in Porto things like that, uh but haven't been to this meeting yet, although some of you may have seen me other places.

C

Glad to have you foreign.

D

Joined the the bi-weekly call yesterday, uh but this is my first time in this session in particular, so happy to be here.

E

Hi nice to see you again: Matt hi, hi, I'm Trish young I'm used to be Justin student, no I'm, a datadox cutie engineer there I'm going to salsa steering committee like like Michael um and I'm. Looking forward to uh joining these meetings, I I kept missing it on the cncf calendar, so here I'm. Finally, great thanks.

B

Yeah uh just a reminder: this is technically under open. Ssf I know that there's a lot of overlap between all the things and there's 12 million calendars right, which is why, which is why.

A

um Cool all right, so um next up.

B

uh Actually is there anybody else, I think yeah.

F

C

Sorry yep here I'm part of kosari, and this is my first time attending a meeting I'm looking forward to whatever you guys thanks.

A

B

Before we get into um some of the things on the agenda and sorry I'm literally updating the agenda as we go along because there's a couple of things that came up uh yesterday in the in uh salsa meeting. But um before getting into that, um does anybody have any sort of updates from any tools that they're related to or any of the things that we've been um uh that are sort of related to the tooling and and salsa.

B

um Don't wanna uh call on anyone, but I, know Frederick I know that uh I believe the mpm stuff was merged recently risk merged recently. um Do you have some updates on on that yeah.

G

So, as you said, RFC is now merged, so but in practice I would say it doesn't really change much like. Even if the RFC wasn't merged, we were sort of working on the details, so I don't really I'm trying to think like if we can have something to share I, don't really think like the work is continuing to pursue as planned um beyond that. I'm not sure like.

G

There are, of course, like slightly related to this and like work on Sig store, JS and sixth or tough, and things like that that we're doing on a hopefully can share back much more like 60.js still in a good shape, like it's I mean it's by far or it is far from being complete, but it's really in a decent state and the tough work is probably not yet open source, but it will be enough near future like when, when we have a good working condition, there are some issues with uh the Json canonicalization like cjson did confuse a few of the developers because after you cannotilize it it's not actually propagation anymore.

G

So but yeah. We are aware of that, and we had like got good feedback from Josh lock on that, so, but beyond that, I can't think of anything else really interesting to share like. There are still, of course, some open details in terms of when um the salsa predicates are generated like how they will be verified and to what extent and how much will actually be in the hand of hands of the uh Downstream developers compared to how much will npm itself actually try to verify Beyond, just making sure that the cryptographic material adds up.

G

But there are definitely some ideas. I know with who has been on this call before has like a policy thing he's working on as well, which kind of relates to this, but is intended to be more. Let's say built on top of the capabilities that npm itself have.

C

B

That makes sense and yeah I know the cjson stuff is not the um I've run into also some some issues. I mean I I understand the the goal right, uh because we want to make sure that the hash always Remains the Same of of the content of the the Json, and so that there's some way to kind of um do that.

G

Yeah I think parts of what's very confusing is that the cjson spec itself is contradictionary. It says in the human readable text like this will produce perfectly valid Json. But then, when you look at the formal specification, it's obvious that the result will not be Json possible. So it's I think that has led to some confusion.

B

Yeah, that might be worth um bringing back up to actually I'm, not 100 sure who is in charge of cjson.

G

I I don't know, but at least Yorkshire kind of immediately identified this as the root cause and pointed to the spec and some other related uh issues in I. Think it's in Python, tough.

H

E

Sorry, just to just to I think you know, a few of us here are python tough Folks at least Justin Sebastian and myself. Maybe we can help with this um sorry. Can you give a specific example of how cjson makes it um in validation? Do you mean like the new line escapes and public keys.

G

Yeah I think at least new lines. That's the thing.

H

I, remember: I, can't remember I.

G

Can't remember if it was only for the public keys but yeah. Definitely that's the thing that broke some things. Gotcha.

E

um Is there anything that we can help with maybe clarify things in the spec.

G

I think I mean I. I can't remember the details. I can probably dig it up, but Joshua linked to an issue in in Python tough that pretty much was running into the same issue, so I've yeah. If it's maybe maybe it's if it's clear in let's say the top specification that when you're looking at I don't know the cjson spec, because I think cjson is not related to tough at all. It's just.

D

G

Shows and canonicalization formats so just be aware that the spec might be hard to read.

E

Okay, I'll I'll create a an issue in the spec thanks. Thank.

G

H

B

um So uh is there anybody else, who's been working on um any salsa, tooling, um whether it's something that is uh well yeah? Has anybody been working on any sort of salsa, tooling or related to salsa, tooling, um uh that that they want to bring up as a as an update.

C

A

B

So next up, um one of the things on the agenda which was um brought up uh yesterday, was um the desire to have um a verifier and I know. We have a verifier but to make sure um the verifier that we have for um salsa specification.

A

um Hold on, let me bring this up.

A

I mean that's the link to this.

A

There is this tool and I'll post it here, as well as in the meeting notes in a second.

B

um But one of the ideas was, we want to make sure you know, as um we are uh pushing for 1.0, we want to make sure we have some set of tools. Libraries, services Etc- that can verify um salsa, attestations and I- think that, just to be clear, I think that there's there's stages to this right, um because I think there's some confusion yesterday, uh like some of it is just literally uh because this is actually a common issue.

B

Among some of the um s-bomb stuff today is a lot of folks are actually not generating um s-bombs that are valid to the specs. So it's not even just about verifying like hey, is this signed by the right parties is, um is the build content like? Is the content inside there correct and could I like generate a new build out of this sort of thing? It's beyond that? It's more of like?

B

Does it even match the spec at all, um which is which is a fairly common question, especially as we sort of drive to 1.0 making sure that different tools can verify sorry different tools, support the different specs is going to be important, and today um we don't really have like a like a salsa generator, slash, verifier Library um for any sort of uh major language outside of.

B

If you look at some of the salsa verifier stuff, it uses the in Toto libraries and then add some stuff that it just looks for salsa on top of it. But what would be nice is to be able to sort of say hey if we have something like a Json schema or whatever, as the canonical representation of uh uh salsa 1.0 spec, we want to be able to go back to it and say: okay, great um everything should be able to. You know uh like python.

B

Javascript uh uh go whatever should all be able to point to that schema as the thing to then sort of use to, as as a verification uh used for sort of um I, don't want to say verification, maybe that's a bad term validation that making sure that it's actually valid salsa.

B

um Does that make sense to folks.

F

B

Yep so stage one is uh ensuring that the content of the salsa attestation actually complies with a specification of the.

A

Predicate definition.

A

Of the predicate.

H

So so it's basically a schema validation right this, whatever yep is not the content inside these schema. We are not validating the content.

B

Yeah, at least uh not not yet um that's I think like what I would say is like stage. One right um is just essentially doing that, because that that sort of thing is is complicated, because we already sort of discovered early on a bunch of bugs, for example, in tecton chains that we had to fix um where tecton chains was I.

B

Think one of the fields was supposed to be a URI, and it was just a plain text so stuff like that was um just needs to kind of be sorted out, because uh we're already seeing this in, like the s-bomb world, a lot um uh we're seeing this a lot in the s-bomb world where, like something generates an attestation as it generates an s-bomb, that's like 90, valid and certain languages or sorry, not certain language, but certain implementations, I should say of of that.

B

Can read it no problem um because they're a little bit less rigorous. But, for example, um a lot of the other ones like especially those in in more stricter languages like rust, tend to sort of complain, because it's like hey, yes, you're 90, compliant with um the s-bomb spec, but actually the s-bomb spec says you need to have a shot. One hash, not just you know you can't replace shot one with shot. 256 you need to. It could only be complementary.

B

So there's things in the s-bomb specs that kind of talk about that sort of thing and there's stuff. That's going to be also in the small suspects that talk about that sort of thing and we've been seeing um a lot of that kind of uh get really complicated. So it would be really great to be able to say point to something whether it's the Json schema, whether it's a queue definition, whether it's some other sort of way of defining.

B

um You know something. That's like even something like protobots. If you could include some additional data types in the protobuf or something like that, some way of just sort of being able to say yes, this field must be a URI, and uh this field must be um a string of length.

B

You know 20 or whatever it is, and that you can, then you know you could then just sort of take that schema and plug it into whatever language you want, and you automatically get that validation piece so that you don't have to worry about the different Implement, because we're seeing this a lot in a lot of the tooling is we're. Seeing you know somebody there. You know somebody puts in most of the salsa stuff, but forgets one thing or another, and so people will say hey. It verifies in the go implementation, but not the rust.

B

One and part of that is like oh well, the go one ignores errors, the rough one doesn't and you're like okay, great you know, so it becomes this. This big mess, yeah.

B

um And then stage two, as some folks were saying, um sounds like it might be something along the lines uh is um verifying signatures on the um salsa attestation uh on you know um envelope.

B

So you know most most of it. Right now is um obviously using dizzy, um but uh the the basic idea, I think that some folks have said is like hey great. um We want to be able to to go in and say, um let's verify uh the actual signatures and that's kind of what the verifier is doing as well. Right now, there's also um and I.

B

Don't know if this is, you know once again I'm just kind of rattling out what were sort of the thoughts in my head, um but some folks have also said: okay cool now, one of the other things is like. Maybe this is stage three or maybe this is stage two I, don't know which one we want to kind of call this, but um is uh actually you know, is um inspecting the uh inspecting the values in or expecting the content.

A

B

The salsa attestation so like actually looking.

A

That was, you know the does the Uso give me one. Second, foreign.

B

So, like stage three is potentially something like um actually inspecting the content, so looking at the actual values of inside of the like the key values inside of um the predicate and actually saying yes, this matches some sort of policy like yes, this. We only allow these build type Uris for our policy cool, um oh I, just realized some folks have their hands up uh Frederick.

G

Yeah, just one minor comment like wouldn't: we want to switch stage one and stage two, so we only parse it and verify the schema after we have verified the signature like let's say there could be an attack against the parser and we don't wanna, potentially parse untrusted data.

B

uh Yes, so maybe maybe this is um I agree that uh so so maybe it's better to kind of say, like Priority One, might be something like just verifying that the content is correctly, because that's just gonna be the easiest thing that that we we can do right where, where that's going to be something that's sort of different from necessarily just the trust element, because some of the stuff is just going to be hey, um people are going to be using some of the verifier stuff to help um I, don't uh I'm gonna, say like I'm going to use this word, but I don't actually mean it in the way I'm going to say it like be able to certify the tools to say: are you actually generating balance?

B

Salsa um or you know? Can you check that you're actually validating uh valid salsa, so I agree that that probably makes sense to to switch um I was just kind of talking about it more from the perspective of um maybe even a prioritization like yeah like Step One is. We should probably make sure that it is 100 valid. It's also, and then step two is, let's you know make sure that the signature stuff is is all implemented in that we're.

B

You know able to use six store and whatever other major signing mechanisms we might be using and then and so on, um cool uh tree shock.

E

Yeah, that's a that's. A good comment about the um parsing untrusted payloads um I. Think that's partly the problem that DC was designed to solve for uh yeah with things like canonicalization, the canonicalization Json uh can only Collide whatever you get the idea, but the problem with C Json is you have to parse it first just to be able to verify the signature, whereas with Dizzy.

E

You don't have to do that so that that should go a long way and then you can once the signature is legit, then you have a lot more assurance that okay, I can at least begin to parse. This signed payload, um the question I had for you Michael is: um where does the policy come from.

E

Sorry didn't mean to catch you off guard.

E

Oh, oh Michael, sorry I had a question for you. Where does the policy come from? Is there like a prescribed from it? uh Maybe I missed something no hold on.

B

So I I apologize I, just something just happened and my headphones just died on me. Like uh so I, don't know, I didn't catch. The last maybe 15 seconds of what you said. Gotcha.

E

uh Can you can you hear me now? Yes, yes, yeah, it's great great great great, um so the question I had for you is: um where does the policy come from? Is there like a a a a separate salsa uh uh uh thing that I might have missed.

B

No, no I think the the idea here is um so the salsa verifier that folks are looking at and so there's a bunch of different discussion about what what this might end up. Looking like, um uh and you know what the actual policy might be and if there's going to be using like a policy engine or whatever, but I, think the some of the content is just like. Could you use um uh something like a Json path like things to just sort of say great?

B

um Does this match like I'm, expecting um stuff to look like this uh inside of the um you know inside the Atta station, and so it could just be something as simple as, like uh you know, a yaml file with some elements in it or you know that that sort of I think a little bit. um You know much more up for discussion, but yeah, that's one of the things that that we're like looking at and and but this is more of right now, at least like conceptually.

B

It's like hey, we do want to eventually have some sort of mechanism, and- and this is something that this is part of stuff like um the policy. Like uh a combination of like tooling and libraries right because we might want to include the ability to sort of say, hey here- is a way to apply policies to it6 right.

E

um Yeah just to clarify just to follow up on that um and then I'll yield to Aaron. um Wasn't there some work that Mark and friends were doing to try to prescribe more formally a policy.

B

That I'm not sure um they maybe um I, know that there there there's some discussion about um post 1.0 the semantics around some of these things of saying, like hey great now that we have 1.0, how should people be interpreting or not interpreting? How should people be using the different um pieces of content inside of the attestation?

B

So this might be something like hey. Your build config should be thought of. As you know, the inputs to the build or whatever you know, your build script or whatever, and so it should be thought of like that. So if you have a policy around build config, that's how it should be interpreted, um and then you know certain metadata about timestamps should be like. Oh, this is the timestamp of when the build was recorded to have started and the timestamp of when the build was. You know, found to have uh stopped that sort of thing.

I

Eric I was just gonna Circle back and kind of comment on the conversation around. um You know this idea of the the metadata verifier tool that we're talking about sounds like we're going to build it from the ground up right and um my opinion. From like a phase. One versus phase two perspective is, um you know, I think phase.

I

One should honestly be a schema validator, it's not as valuable from a security perspective for the end user, but it actually is valuable from a utility perspective, for you know the ecosystem of Builders and the ecosystem of consumers right to make sure that these things are actually being generated from these tools and Builders the right way.

I

um You know Frederick I, think you made the point to like. Maybe we should prioritize validating the authenticity of the of the thing first, but I think from a utility perspective and kind of like offering this for like value to the community from a valuable perspective rather than a security perspective, I I, promote kind of what Mike has been talking about for validating schema. First, it has like a first win, I'd say, but I think it's still really valid right to to make sure it is authentic. Of course, please.

B

Yeah, no yeah, I, agree and I just to be clear, I think it's it's less about the um right like if you're talking about it conceptually imagine you had a 100 finished product. It probably would look something like um you know. First, you check the signature. Then you verify that it's actually valid schema right um and then well actually you'd probably first check like. Is it a valid envelope? Then you check the signature.

B

Then you check the uh the the if the content's valid- and this is to be clear- this is stuff that we're actually currently doing in stuff like walk um already the the thing that I think we want to be able to do, though, is we would much rather have some of this be included in libraries and other tooling so that we can call out to that other tooling and as opposed to like one of the things that we're seeing a lot of is and I know that this is kind of um uh you know par for the course a little bit with go is that it's so easy to sort of re-implement stuff and go?

B

Is that everybody just sort of as opposed to writing a lot of the shared libraries they just sort of say great yeah I'll just write a quick.

B

You know, you know 50 line thing that just kind of will parse through my pieces that I need the problem that we're sort of seeing, especially in the s-bomb space, and starting to see a little bit with the salsa spaces as folks, if folks are not using some of the existing sort of libraries um out there and they sort of just build out their own thing and they just sort of say, yep, I'm expecting to see Json or I. You know I use the The Dizzy stuff and then I get a base64 encoded content I.

B

You know then um turn it into Json, and then uh uh you know pull it into my local thing and I just have some structs for what I the content that I want. What ends up? What we're seeing is some people are already building out policy and doing certain things against salsa attestation that aren't actually valid salsa. They just look like velots, also so that as soon as another, as soon as they start to push it to another tool, that tool like will complain and they go wait. A second.

B

This tool doesn't complain and I know that that's more of a community problem, but it would be great to sort of say you know: hey. There is this salsa verifier, um which just to be clear, I, think most of this content should go into the salsa verifier, and maybe we might want to abstract the salsa verifier into um a library plus the tool, but the salsa verifier.

B

um If I can scroll back up here, um that's Linked In the document and I'll just put it in the chat just so that folks can click on it. This salsa verifier, is you know it's. You know, CLI, there's a bunch of stuff in here. There's there's a bunch of um you know stuff in here. uh For actually you know verifying different elements. Yeah yeah um I think you know for for folks who are building their own tools.

B

It'd be great to be able to say: hey great I can include the library pieces of this into my tool, so I don't have to call out to the CLI, um but you know having a lot of this in here would be be really great separately. One of the things I was talked about yesterday in um in the the conversation was um in the salsa comfort in the salsa meeting was uh Laurent say said.

B

uh It might also make sense to run something like this for a while as like, and uh as a public API kind of thing.

A

B

Foreign or because a lot of people, you know as as something that somebody can just sort of say: hey um I'm gonna, send this over to to some. You know to some API so that folks don't have to run it themselves, uh I'm a little ambivalent on on one way or the other I'm sure it comes with its own pros and cons, because now you're trusting some third-party service to essentially verify that um but yeah, that's kind of where, where we landed with that um and I'm trying to think. If there is.

A

Was there anything else from like a stage? Four at this point, I, don't think so.

B

um I think that was kind of the the main stuff was just you know, um verifying signature, verifying um that it actually matches the spec and then saying hey. Can you uh validate the content um against some sort of policy.

B

um Any other thoughts questions um about any of that foreign.

A

A

So, um and let me.

J

B

Oops um one of the other topics, I think uh that's going to be coming up based on some of the salsa conformance work is um what sorts of Builders actually conform to the salsa specification, um especially as we're driving towards 1.0.

B

um Some of this is going to start becoming uh a bit higher priority, because a lot of folks are obviously you know. They're uh there's a lot of confusion about like whether or not certain types of builds might meet certain types of salsa specifications.

B

um There's going to be uh for folks who, who aren't familiar with the salsa conformist work, most likely there's going to be um so there's going to be a conformance program that most folks can self-certify.

B

But it comes with. You know some requirements right where you are essentially asserting that you're following certain rules- um and you know if you're found to not be following those rules- you'll be asked not to say you're complying to salsa and the reason being is you know, obviously, with the open, ssf and Linux Foundation? Is they don't want? Just everybody Under the Sun saying yep I'm salsa level?

B

You know 12 right because that sort of dilutes the brand and then and and makes it sort of worthless um at the same time they don't want to sort of enforce that.

B

You know every single person needs to go and work with some uh audit firm or some security firm to sort of verify that they're actually um following all the salsa rules right, you know for certain companies that might make sense- and you know especially folks who might say: hey yeah we've been certified by some big security vendor or audit firm and yes, they've sort of verified that we're doing everything. Salsa, 3 and yeah yeah, that's great, but there might be some self-certification there and most likely there's going to be self-certification.

B

Oh so there should be certification on or self-certification on a couple of different things.

B

um One of those things might be the actual Builders themselves so that the you know open source Builders like, for example, tecton and Fresca, and Jenkins and circle CI and GitHub actions and whatever might all be able to come in and say, okay great, we are doing you know we can release a document that says we are doing these things and based on that, you can go and say great I. You know that sounds good to me and yes, you're complying, but you know um as an end user, I I trust that or whatever.

B

um So that's that's one of the things that that's coming down uh the line and it's something that we probably wanna look at, especially as um some folks have sort of brought up like there's been some challenges with certain build systems and hitting some of the higher level salsa stuff. At least out of the box right like because, like you know, one of the big ones is like Jenkins is relatively open out of the box.

B

You can do a lot of things and add a lot of plugins um to then make it easier to comply with salsa, but um I. Think there's going to be some discussion about hey could could we, you know, write up something if somebody is a you know, is doing a lot of stuff with let's say Jenkins right now. Could they write some something up to say: hey here's, how we're currently trying to hit all the salsa requirements via something like Jenkins.

B

um Some of the other ones might be a little bit easier because they're kind of like locked down by default and stuff, like that, you know or stuff- that's like more declarative, like tecton and whatever, um but that's just something to to kind of um think through and does it do? Does anybody have any thoughts on sort of that like Builder certification um process or anything like that.

F

Yeah we were working on a solution um that kind of it's more of a Management console, but allow you to pull in you know, create a end.

H

F

Type of solution and discuss, um you know, run the attestation through the existing. um You know provenance, Checkers and things like that and looking at where the gaps were to get. You know level one through four.

F

um Some of the discussion points you know we've had are: how do you do this with multiple different tools to handle these different ways? The plugins, as you mentioned, is one conversation Point, um but you know going for each phase of salsa and having to do multiple scans to determine. Are you still compliant?

F

um You know the code signing aspect of it for one for one thing right, you know, have you signed it? Have you checked it again? You know. Are the repository aspects correct. You know all of the various different uh stage. Stages of the salsa components at each stage in the sdlc is something that we're we're still trying to kind of ideate solutions around and I.

F

Don't think you can do it simply with just the single um cicd component because of all of the plugins and as you start to think about different things like vulnerability versus configuration, checks versus other aspects, you, you know, it really becomes a third-party tool that either needs to be injected to to look for specific components or more of a to an overarching kind of tool that allows you to plug in your CI CD into it and manage this process, for you is kind of the direction we were thinking um it just I can't see uh a universal way to do all four stages in Jenkins, for example, um you know it might be more possible in some of the more proprietary ones if they dedicate the the time and effort to it.

F

um But in you know the more open source uh type of tooling um I. Don't know that that's enough of a focus yet from a lot of the communities, so it definitely needs to be, but it becomes that kind of broad conversation of. Should it be more of a facade, Management console that does this and can be flexible enough to incorporate different CI CDs.

F

um You know that'd be something I bring to the community, you know, is it? Is it worth the effort to start a project that builds something like this in the community?

F

um uh I I think it is, but in that becomes a conversation, for you know, who'd be interested in working on that type of project because it would be you know, starting off with something like a Jenkins, and then you know bringing in tecton and tecton chains and- and uh you know bringing in you know all the others.

F

You know the the git lab Ci's, the the Travis CIS and, and you know XY, you know one to n other components as time goes by, but uh that's kind of the the high level ideation and discussions we've been having on this topic.

A

B

Cool yeah yeah no definitely agree with you. uh There Eric, especially on that one point um you had about like it's more than just the the CI tool right, because you know you need to include you know, scanners and whatever else and I, think one of the things that has been um sort of brought up. uh You know previously as some and this might be something that the the this team maybe wants to kind of discuss. A little bit is like what is the responsibility of the.

B

um There is um I'm gonna, say: there's, there's, there's like probably a set of tools right that that help here and then there's also a set of elements regarding how your your flow goes right.

B

You know whether you know your CI um pipeline works right, whether it's encoded in tecton or in in a total layout or whatever I think that there is like there's things here, where you kind of come in and say, there's certain elements of the Builder right, and so, let's just say for the sake of um argument here, like you're, using build packs, hey, there's certain things, build packs can do um for you, but it doesn't like build packs itself, doesn't um provide any guarantees.

B

As far as like the orchestration of the pipeline, you know so how it got there right, you know. So it doesn't. You know, build packs itself, doesn't really have mechanisms to say, hey.

A

B

Isolated environment run. um You know this scan, let's say right, but you know Jenkins or uh tecton or whatever you know. Github actions has that sort of ability to say, hey run, you know, run build packs Follow by run this scan um and then uh each of the. So so that's like two elements and then um the other element is the actual sort of pipeline itself right, so something like in total, layouts or or tecton or Jenkins file. You want to make sure that those things are structured such that you you are enforced.

B

You know you're forced to run the right things um to hit the right right stuff right because, um depending on the different CI tools, you know um if you do not use like if your GitHub actions or whatever do not use the um the salsa, you know generator, then you're not generating salsa provenance, and so what what sorts of things can you do to essentially enforce? That is also important. Well,.

F

Yeah and I'd take that a step further to say that there needs to be. You know how Jenkins will provide you, uh some limited type of reporting on the fact that you've run certain jobs and everything else. You need to have some sort of metrics and and Reporting structure. That shows you know that you've actually attained. You know this project is actually validated for uh salsa level, one and level two. What have you um and a history of that right? So it was, it was compliant. Now it's not um on a given given time frame.

F

um You know that that type of and at what stage is you know potentially, like uh you know it passes, you know the first. You know five uh bullets of salsa, but the next you know several. You know it doesn't. So we know provenance wise based on that and where the gaps are, you know what what are you missing to be fully salsa compliant um yeah? Those are the types of things down the road that definitely need to be included.

F

um So the projects can you know it's a kind of a question now as to how valid badges are, and things like that. You know some people think they are I, think they're, very valuable, but I think you know if you can provide hey. You know my project is, you know, salsa level. Three compliance is a badge or something on your your project, because it's run through all of these. These Gates, um when you know somebody goes to pull down your binary.

F

um That's that's to me. That's a pretty good indicator that your your project is secure. So you know some things to think about. You know it's, but I definitely think that we have to talk more about. You know the the metrics and the observability of this process too. Not just you know becoming capable, but how do we prove that? And how do we show over time that it's uh it's remains compliant all.

B

Right, yep, uh parth.

J

Yes, um so what I think what I was trying to say? What I want to say is in the certification process. It seems like it would need to be a continual process right. It's not like a wad off kind of thing, depending on the build system right.

J

If, if it's something that people can you know if it's based off multiple components and if someone goes in and changes something right that the whole certification kind of goes away right, so it seems like it needs to be some kind of an automated way of continuously validating that it's in the right step and I. Think that's what Eric is kind of referring to, but I'm just wondering if it's, if that's even possible, with so many components out there and such so yeah.

B

So this was something that's also been discussed. A little bit with the conformance program is like, like certain things might be able to say, hey look we're gonna, you know like yes, somebody could be messing with the the pipeline right after we got the certification, but um if you are continuing to do some of this, like if you're, let's say once every three months, six months a year or whatever it might get caught, and then also from the policy standpoint of the organization- that's consuming it, they might want.

B

You know more or less of these things they might want um increased sort of verifications and then the other thing right is the idea at least behind some of it, at least for organizations right like folks who I want to say.

B

Is it's not just an open source project that, like hey Mike, you know made a little, you know toy project and he added some salsa to it um and you know said yep, everything's, good and then changed stuff and never updated it again, like I, think that sort of thing is very much going to be dependent on the organization consuming it to say: hey I, you know, maybe I, don't trust a a project that is just run by a single person, um but certain other organizations who have a lot to lose whether it's money, reputation whatever um you know.

B

If it turns out a third-party audit firm, does come in and say: hey you're. You know a lot of this stuff should show up um and also if it turns out you're lying. um A lot of your customers are probably going to sue. So I think that kind of thing is is also I think uh a risk there, which is why I think a lot of folks are when it comes to some of this self-certification.

B

A lot of those things can and I think have been seen to be sort of uh legally actionable um if it turns out like yeah I, certified this thing and then immediately changed it afterwards, but I think it's going to be that balance and then, especially in the open source space.

B

um I think we're gonna have to see uh you know. Perhaps larger organizations like your Microsoft yeah. You know your Googles and and red hats and vmware's or whatever to sort of say: hey we, you know we looked at this open source tool and we've looked at what they've been doing and you know we've looked at their self-certification and sort of revalidated it and we think yeah seems to be the right sort of thing. um I think that's going to be an another way. They might go about that.

J

J

B

Any other thoughts about like Builders and certifications and and whatnot and I know like um I, know. Fresca is working a lot a lot on this in the open source space right. This is I think to go back to what Eric was talking about. Is you know? Fresca is trying to be that opinionated set of Tools Plus the pipelines themselves to try and say hey in order to actually comply with a high level of salsa. You don't get to Define your own pipeline that lets you ignore these things.

B

um We we are essentially saying your pipeline is actually constrained to run certain sorts of actions, um and uh you know with that. Comes you know a lot of folks. Probably don't want to use that because they say hey. We want to run our own custom thing. Okay, great, but I.

B

Think Fresca is trying to kind of do that sort of thing and I think we're trying to look at like how easy is that to certify and I think that there's some stuff there um and if folks are interested, you know we're obviously looking for more contributors on that one. It's an open, ssf project, um uh but um anyone else have any other thoughts on that. Otherwise we can kind of go on to the next quick sort of topic which is sort of related to the past two ones.

A

B

Right um so one of the other things um which is related to the two previous ones a little bit, um which is uh this idea that Santiago um from uh in Toto uh and Purdue University um had brought up. Is this idea of a predicate dictionary?

B

um So if this is for going back a little bit um so salsa is for folks who aren't super familiar with in Toto is uh salsa attestations um the predicate format, which is the Json format right that is being heavily recommended for use for salsa. You don't actually have to use it to be compliant with salsa, but you know pretty much. Everybody is using anybody. Who's using salsa is more or less using the the in total predicate format.

B

um There's some talk about uh perhaps building some tooling, a library to sort of help with the mapping between um salsa or not just salsa, but we'll use salsa as an example, but salsa and other um predicate formats, uh mapping to internal data models or mapping to an ontology and then to it an internal data model which would allow for a lot of tools to just ingest from the predicate dictionary and be able to automatically at least get some ability to sort of parse through the um parse through an assault attestation.

B

It might not be able to get all the semantic information that you might want, but in the very least, could do stuff like verification. So the idea would be something like just thinking about.

B

This is conceptually you have a um a set of Json schemas or a set of queue, definitions or some sort of way of saying hey I have this is this is how um this is some sort of schema, and then you might have one or more mappings to either a data model or to an ontology um that you know says: like hash equals checksum in this data model or hash equals. You know, and that could be itself another schema, something that is not like code per se.

B

It's just something like a Json document, an XML document, some sort of parsable thing um which would allow different. You know different tools to be able to just say great I can just include a new.

B

um You know with a new version, a new minor revision that doesn't really modify um how the the um how the attestation should be interpreted. More of just like some clarifications or some extra elements here and there you can have ways to say great this like we, we now support. You know some new hashing format, okay, cool that that just sort of maps into this internally um into some internal data model or into some other ontology. So that's just something else.

B

That's that's being discussed as a way to kind of make it easier for folks to adopt um adopt this.

B

Thoughts um is this: does it sound something that is interesting to folks um or anything like that.

J

Yeah I think this would be great um having this, you know, being being some kind of language agnostic type that we can use to. um You know validate and do enforcement of the schema and so forth. I think I think be very, very useful.

J

I mean I did want to hear your concerns. um You know if you have time but like in terms of the Proto buff I, think maybe that might be a good good thing to discuss the actual format, type and stuff.

B

Oh yeah, yeah I think um when it comes to the serialization I think it doesn't matter um like for me whether it's Json protobuf, whatever I, think the thing that a lot of folks have can or might I myself have concerns with.

B

Is um you want to have uh more information about the actual schema right because, like protobufs has um fairly gen, you know has whatever a dozen or so types um you know in 32, in 64 or whatever uh stuff like that, um but it doesn't have stuff, and it has stuff I think also like time stamps, but it doesn't have, for example, um things like URI validation right. You probably want to be able to say this should be a valid URI um in certain contexts.

B

You might say: oh, this should be a name, that's no longer than you know, 64 characters or whatever right, um and it's the sort of thing that that uh kind of goes beyond what the protobuf can do. It's stuff that, like I, know, Json schema, can sort of do in with some things and I know.

B

That's something that Q Lang is able to do as well, and so I think that sort of thing is is kind of what we're sort of looking at, as as a way of of sort of um you know, then being able to say, I predicate you know any sort of in Toto predicate could be. You know, okay, cool. This is the URI. This is like, for example, this might be even another subtype right, you know right. People have talked about okay cool.

B

Could we have something like subject inside of in Toto, be a type itself, and then you can say: okay, great or or something like name plus hash is some sort of type or whatever, and then you can then inject that in other places, so that you know the way that it gets. Parsed automatically gets parsed the same way, instead of having to kind of duplicate a lot of that work all over the place. Yeah.

J

I think that's happening with the the digest set. I think that's part of the subject. Something happening there, a bunch of times so yeah foreign.

J

B

In the works and and I think that the idea here is just to also make it very easy for, like even some of the tools to not have to really update their code. In order to like you, don't have to download a new version of the code in order to um figure out the schema like because.

H

One of the reasons.

B

Right in Toto, um in Toto, attestations and all those things are Uris. Eventually they should be actually resolvable um so that you could go back and and actually pull down the definition from the URI and then from there. You should be able to say: okay, great I can pull this down, and if you had something like a predicate dictionary, okay check the predicate dictionary or have different predicates registered with your dictionary or whatever, and that should have some sort of mapping mechanism to your internal data model or preferably one day. You know and I know.

B

This is kind of I know this is a pipe dream, but you could have something where it's you know it maps to an ontology, and then you could have that two-way sync, where you can say great I can now convert. If I have enough information in salsa I can convert salsa to an s-bomb and an s-bomb to some of the elements that I need for salsa or whatever.

D

B

um Any final thoughts uh about this or any other topic, anything that folks wanted to bring up for next week, any demos or anything like that.

B

Cool, uh if not, everybody can take back two minutes and and please put stuff on the agenda for uh next week. Oh actually, no sorry uh probably cancel next week since it's the day after the U.S Thanksgiving holiday and a lot of folks usually have off yeah.

B

So um I'll I'll get back to you uh about whether or not it's canceled I'll see if there's still interest from folks, um but yeah cool uh talk to everybody uh uh soon. Thanks.