CHAOSS Risk Working Group, 3 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: CHAOSS Risk Working Group November 3, 2022

Description

Links to minutes from this meeting are on https://chaoss.community/participate.

A

I'm, not a person in the world. Welcome to the risk working gear meeting uh we forgot to start recording I forgot to start recording. So here we go. um We've been discussing some of the really uh amazing insights that emerged last week when David and Johan and I were in Sweden at a naspocon event and uh I. Think where we are now in the agenda is uh discussing just kind of a if there are I think the to do.

A

I see from last week, which I wasn't here till know to do, is to look at other risk metrics and see where folks think metrics need to be developed, and it seems like a brief overview of the GTI and tooling versus application. Discussions might be helpful, I don't know if Sophia, if you're, comfortable or renisha, if you're comfortable helping us.

B

I certainly can talk about this one.

A

And you were even here so yeah.

B

Yeah, okay, it is not the good tool infrastructure, although that's hilarious, it's the canoe tool chain, infrastructure.

C

That's on my note-taking skills. Thank you. Yeah.

B

You can keep the last word but gnu tool chain. Okay, it's.

A

In the next line.

B

A

B

Probably it's good to make it make it sure.

A

Yeah I would have never.

B

Found it yeah and it okay yeah, and that next line is absolutely wrong. Okay, um we are okay by Tool chain. We mean tools like GCC and I want to make very, very clear. It's important to be clear on this point: okay, the gnu tools are not moving into the LF, so all the tools are, let's see, are not moving into the LF okay.

B

Instead of the um the support um uh LF is uh preparing to uh support.

A

um Four or five telephone games this last two weeks.

B

Yeah um you know uh and heart and on hardening it you know you know. So. Basically, let's say you make a change to GCC. Okay, you are going to propose a change, but you want to now run a whole bunch of tests on a whole bunch of different platforms. Okay, you.

C

B

Sure that works properly and so on, okay, um but basically, and and they also want to make it so that's much harder for attackers to subvert this stuff, okay and so basically,.

A

Is this uh getting into the runtime executables and messing with them or.

B

This source code, no problem- no, this is this, is think, think, build and test. Okay, okay and, by the way, the gnu tools. Folks, typically, don't I mean they don't. Release executables or probably more accurately, to say is that a lot of people are not gonna, just download from the gnu folks and executable. Okay uh generally, the key thing that they release that most people grabs are the source code. Like you want that source code well tested, you want the infrastructure uh hardened against attackers.

A

C

B

And in particular, a lot of them are more used to a mailing list based infrastructure, where you you put post patches and stuff. That's what the limit this Colonel has been doing since the its Inception, and so we already have a you know. We have already got all the infrastructure necessary to support that. So we'll wait a minute. You know why not just reuse that, and the short answer is well. You could but there's some people time, and we need to pay for that people time now. I do want to be clear.

B

um There is they do use. An existing system involves sourceware. Some of the gnu folks are not comfortable with the chain with changing like this sourceware.

B

Oh okay, it's it's an organization.

A

Oh okay, so basically yeah.

B

Yeah, it's another organization that it would be, will that uh some folks would like to be uh move to instead um most of the gnu tool. Actual leaders um would like to use this one that has real funding and so on, but you know what just now you know that there is this thing. uh This thing called GTI and.

B

C

B

We have to be careful here, the tool chain plans to move. Oh man.

B

Yeah, so it's Reviving okay, it provides a more robust and secure infrastructure for these projects. Okay, we are not taking over. uh uh These are not moving from gnu, okay, so.

A

It basically better servers to host stuff on right.

B

Exactly it's like you.

A

B

Know servers to run the tests servers to run builds to run tests that sort of stuff.

A

That makes sense.

B

A

Mean and what about um tooling versus application? Is there a quick summary there because I think I think some of these questions might lead us toward what we want to work on and I know? We talked about maybe two months ago now, um working more closely with the ossf to try to understand how we complement or collaborate with each other and I. Think I was supposed to be there at a meeting and I did I didn't get there I don't know if you remember that David.

B

Truly I'm still trying to remember what you're we're talking about here.

B

Are we are you talking about the meeting last week with the dashboard? No.

A

I was talking more like a few months ago. We talked about like what is risk and what is ossf and I actually went to the ossf meetings for a spell at uh OSS Summit North America, um like we use in auger, we use the scorecard it's one of the metrics. That auger provides because it's useful and it's there.

B

um Yeah right and by the way, uh sonotype did recent analysis and found that scorecard was helpful and some of them in particular, were really helpful at predicting, where vulnerabilities were likely to be found.

A

What is sanitary I should probably know.

B

That certain types of the uh Supply uh software component analysis um I mean they do various things, but um they they uh sell SCA tools and services and they also produce an annual report on open source software. Supply chains.

A

B

A

B

The link and post to it post is.

A

This similar to the set, what the census did it one one point in time or is there still a sentence, a census.

B

uh Okay census used several SCA suppliers as their data sources for their data analysis. um Sonotype was not one of those data sources, there's a whole bunch of sea companies.

A

The critique, I suppose they're the kind of it's a critique, but um the focus is on packages in the application, not necessarily whether or not they're used in the package in the application right, so that what.

B

A

B

A

B

Here: okay, I'm still trying to understand the context you're saying.

A

Yeah I wasn't here so I totally view.

C

In Stockholm, uh we were just talking about in our current knowledge of what we can see in dependency, analysis tools or dependency like anytime, you say, pull all the packages that are used in your system um and sort of commenting on where, where we see gaps or where we expect there to be gaps just as a way to see to discuss, how do we improve what data we can gather in these in these sorts of things? But we didn't really have any solutions coming out of it.

C

We were just sort of talking in general about where we would like to see more information, um and so here it was on context of what's in use, as well as what you might be using with it, which isn't necessarily captured in that dependency chain.

B

um Stop stop right. There stop right there, because you're using words, but I want to understand what you mean by those words, because I can't understand everything else that follows if I don't understand on the application versus the tools that are used. What do you mean by tools.

C

uh This was Kate's point, so she might have had something more specific, but I was.

B

Okay, she's, probably talking all right all right, I've talked to Kate many times, they're, probably talking about the what is running used at runtime versus the tools used in say, uh build time or test time. Yeah.

A

That's I thought we were talking about. I thought it had something to do with that, just because yeah yeah, but I wasn't here so I, don't know.

C

Yeah, because that does sound but like more accurate, and it also, we had all these conversations earlier when we were looking at our dependency metrics, initially that we were trying to make that distinction explicitly, because this could be capturing two sets of information.

B

Right: okay, uh around the uh run time, dependencies of an application versus the two, uh the tools that are that are used, otherwise uh an EG to build or test it or test or distribute it.

B

Okay, uh I think State restated that way see now. If, if that's what you mean, I totally understand what you mean now I think that's fair, although there is work going on right now to extend there's nothing that prevents um you know s-bombs from including that information that said, I I think the expectation I, don't think this is it's wrong to have done it that way, I think it's quite reasonable.

B

Let's start by focusing on the code that's running on your system, uh because, while it's true that compilers, for example, can insert uh vulnerabilities unintentionally or intentionally in stuff, they generate um to A first order. Those are less common than the just I've got a dependency I'm, calling it directly and it has a vulnerability. So um it's absolutely true that people are working on this there's already some support now that I think there will be more later, but I think it's rightly that's a second order effect.

B

Once you have gotten your runtime dependency down, because if you don't have that, why are you bothered with the other stuff.

C

um The last point was I shouldn't be under this bullet because it was separate entirely as well. The system's the analysis, too,.

B

um Maybe we just pull that out a shift app yeah.

A

C

C

um Eddie here was more again like she's thinking about system safety like ISO standards, uh in terms of whether or not the physical hardware and specs are up to par um and whether or not that information is being captured.

C

I think again, like we were kind of running the gamut more here in a way that I think, if we do, we could always get broader, as the group and I think if we want to focus ourselves a bit I, I kind of like the last thing that we were talking about um in the sense of actually we'll connect you to the first thing that didn't make the recording, but in collaboration with the risk working group in the openssf. That's thinking about this dashboard, this particular group.

C

If we want to focus on metrics that can be best applied in that context, then I think we've finally evolved to need a risk metrics model because I, like I, don't know I'm interpreting, metrics models appropriately here, but I.

A

Feel, like that's.

C

That's what we need is a set of metrics that has a well-rounded view of risk as we see it and whether or not that's what ends up going to the dashboard another story, but at least what provide a starting point or a point of discussion. I think David, I love that you raised this point last time. It's much easier to react to something than it is to create something organically with a group of people.

C

So I could see this group in a position to create something to react to um in terms of set selecting the number of metrics I. Think we have some to work with already, but I know we're like. Basically almost that time here, I'm going to be to our next meeting.

A

I believe I believe a few minutes early, so.

C

And basically figure out where our gaps are so that we can I I feel like given the timing of of the the working group and open ssf, it would be appropriate to have something to share with them say in a week a couple weeks or so I feel.

B

Like they wanted, if, if if this, if this group could actually move that quickly to create a starting, a starting set of here's, a proposed set I mean if you, if you go, look I actually created and I, you should have already gotten a copy of it, but a um you know some ideas for the dashboard, some metrics and so on, uh but it was basically hey: hey, let's come up with a list of plausible metrics, let's winnow it down quickly come up with something and iterate I I do think it'd be awesome to have something more principled, but I.

B

I think that the dashboard thing is going to be one of those things where uh Implement best you can and then, if we can in a shorter term and then, if we can make it uh more principled, focused on broader issues based on feedback. That would be awesome. Well,.

A

And I think I think if we start with just a like, I can run OSS scorecard against a bunch of stuff and sure we could just start by looking at what that is. And then we can look at some of our Libya metrics manifest. But.

B

I think I mean it's scorecard, they already know that's already in there, I know about that's best practices. They already know about the badge they already know about that yeah uh I did mention lib years and also chaos, but you know if there's other things and ways we can figure things out. That'd be great.

A

Yeah I think I think there are, and um maybe that that should be our. We should be looking at okay, they're supposed to have scorecard plus what would produce a useful risk. Metrics model and that's metrics model has really become David. The word that we use for dashboards. So if you imagine that every use case may have its own dashboard, so you end up with infinite dashboards.

A

The metric model is a way of saying here are some metrics that we would put together and show to you this way such that you can get an understanding of the question about General level of risk for the projects of your portfolio.

B

Brother, what is the status of Libya is that now an official cast metric.

A

Yeah, it's a published. It's a published metric auger calculates it. um We haven't um it's it's uh figuring out how to promote that part of it.

A

I guess is uh part of where we're going we're very close to a hosted version of auger. That will make that a lot easier um and there's also a hosted um I think this may have come up in the community meeting Sophia the compass dashboard, that's being developed in um by Getty that will work on any open source project. Have you heard of this.

C

Things open so don't know what the current state is, but I did know that they were trying to implement most like as many of our metrics as possible. That's kind of what it sounded like.

A

Yeah, what they're really doing are they're implementing the metrics models that have been defined so far, so it's a way different ways of baking, the metrics that we have together and I think I. Think looking at that and looking at some of uh that will be an interesting discussion um for sure um and I apologize. I I did put these down as our things to talk about next time, which I think will be pretty exciting and worthwhile. Okay, I do have to take off myself, so our choices, I.

B

Understand rush rush project, so thank you all.

A

Right I will call. Let me do a close then and uh wish you all farewell see you in two weeks thanks. Everyone I'll probably see some of you next week.

B