OpenSSF Vulnerability Disclosures WG, 15 Mar 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: OpenSSF Vulnerability Disclosures SIG Autofix (March 15, 2023)

Description

Meeting minutes: https://docs.google.com/document/d/1mZEi6EvbH2mvn-gHOUIaysAjHlwJXjJdJ7gMlelSkVU/edit#heading=h.u5im5d90xac4

Repo: https://github.com/ossf/wg-vulnerability-disclosures

A

I can hear you.

B

um This is my first time attending so.

A

C

B

All hey John, how you doing I'm.

C

Doing well, how are you.

B

I'm doing all right long time, no see yeah.

D

All right, let me ping and.

D

See if we have anybody doing any RSVP, then.

E

D

Ar should be here, Chrome should be here Josh, you should be here, I, don't know if anybody be joining us so.

C

Oh there's Matt hi Matt.

F

D

Give it a couple more minutes.

D

Although how are you doing.

A

Well, how are you oh.

C

I haven't chatted.

A

C

A while it's been yeah.

A

C

C

All right, let me ping manoir and see if he's going to be joining.

D

D

C

Snack Channel I have.

D

Too many slide channels. This is ridiculous.

D

C

No I heard there's a saying that uh on the internet, nobody knows if you're, a dog or not.

G

So that's hopefully that's not the case here. I.

D

Know right um all right.

G

Just near just near dogs, yes,.

D

D

D

uh All right, so let me pull up the meeting notes and create an area for us to communicate.

D

um It is today's date is the 15th.

C

um So the meeting notes are linked in the.

D

um Are linked in the.

C

The invite, if you could uh ungray your name, if you are here that.

D

Would be um very helpful.

C

I can also post a link into the zoom chat.

C

um So I spoke to um I spoke to Brian bellendorf about the calendar topic and the current best practice for managing calendar invites from the open. Ssf is to copy the or have the openness as a calendar, and then uh on all of the calendar invites you can do a drop down and then there's a copy button and that will copy the calendar invite to your own calendar.

C

And so that's the best way to uh manage invites because the open ssf doesn't want uh the project maintain or the project leads and the and the or the the to manage calendar invites and there's no great way for people to opt into the calendar invites themselves um by like an email group or something like that. So best.

E

C

um Go to the working group calendar select the calendar, invite and copy the uh reoccurring event onto your calendar. If you would like to attend in the future,.

D

um Perfect, um so that's that um out of the way.

C

um Let's do intros, um there are some new faces here, um so let's just go around and introduce ourselves. I'll start thanks. Jonathan, let you um I am the uh a senior software security researcher for Linux Foundation under project Alpha Omega, which is under open source security. Foundation um I'm uh known, are the work that I've been doing over the past.

C

Several years is automating fixing vulnerabilities at scale across open source, um using tools like modern, and you know Bots that I've written to just you know, bulk, generate pull requests and so I've been part of the vulnerability disclosures working group and decided to break this topic out into an independent Discussion.

E

C

um uh To pull in people who wanted to engage in this topic in this work so want to go next.

B

I guess I'll volunteer as tribute in the solo. You want to go. First, go.

A

B

um Hi everybody I'm Josh, Beeker I'm, a research analyst for cloud security, Alliance, so non-profit and I help with the Global Security database project, um so yeah trying to help out where I can.

A

I'm gonna go next I'm co-founder at the Modern, the uh the company behind opener, right, refactoring engine and recipes working with a lot of vendors working with Jonathan light show. Thank you, Jonathan for your contributions um with security recipes and around um control flow in the data flow really enjoy working with you push the boundaries of so many things. I really enjoy working with you.

G

So I'll I'm uh Jordan purple I'm from uh I'm, currently a director of vulnerability research at a startup security, startup based in Israel called Brazilian.

G

uh We do uh management based on runtime analysis, so we prioritize vulnerability based on the fact that there are, they have active code, that's loaded to memory and we do a bunch of other stuff. uh It's also involved in several other open ssf working groups, as well as the sister, mainly the Vex working group when I when I find the time I try to pop in to a few others around s-bomb.

G

um That's basically, it.

F

All right, I can't get my video working uh there's a browser but uh I'm Matt, Smith I'm working at Google right now, um I'm in the Google Cloud section, but um I'm really interested in the um you know over the the overlay between open source- and you know what cloud customers need. So essentially you know that most of the dependencies are open source. So how do we um you know? How do we understand how to fix open source and bring it to the cloud customers?

F

I have a bunch of colleagues that are more in the open source side, though this is my second meeting I just joined, but uh thanks for interest.

B

You're on mute by the way.

C

Okay, what did I was the last thing that was heard for me.

B

D

Oh great um so.

C

uh um Looking for someone can, uh does anybody want to describe the for the meeting notes.

C

All right, I'll take care of that um opens. Are there any opens? Any any open discussion points that people want to discuss uh before we dive into anything else or any questions, concerns ideas.

C

Perfect okay, so um there is a uh specification that um I will open up or I'll, send a link.

D

C

This is a document that I am looking to send to.

D

Is that the same document.

C

D

It's a different document so.

C

This is the specification um defining. What is a uh the proposed idea is defining an open source security, Foundation compliant automated vulnerability fix campaign. So it's at a high level. It's a it's a document that states. If you follow these sets of rules, you can throw the open source security, Foundation name on your campaign, and uh you know it it will. It will have.

C

um uh Hopefully it will mean that your campaign is um following the best practices in that that the open source security Foundation is defined around around this topic, so I've I've had it get reviewed from people from like Kate Catlin who's, uh the PM for github's uh security, uh Xavier who's, the head of the GitHub security lab um I've, run it by a couple. Other people there's some open topics um uh and open questions that exist within this document um that we uh want to discuss.

C

um The first primary open question in this document is um about under part, section three um vulnerability messaging.

C

um There was a topic of whether or not um uh we should support some sort of opt-out mechanism, for this so should should we um should should automated pull request. Generation campaigns be required to support an opt-out mechanism.

C

um Xavier uh argues that yes, um Brian put up a couple of possible answers if we do support an opt-out at uh uh an opt-out.

C

um Yes, but opting out doesn't mean PR not said it means PR as a public ID like so the diff will be public by default, um and then the other option is yes, which means the project is skipped entirely, um and then we we publish that list. You can always publish that list of pros of projects who have opted out um on a public website, or something like that. Does anybody here have any opinions on this topic.

B

I guess just chiming in as a Dev um having an opt-out would definitely be mandatory in my opinion, because otherwise you're going to piss people off.

E

B

So, as far as what that looks, like um probably just skipping the PRS or some other mechanism where they don't really have to deal with it, but.

D

B

At the same time, I don't know because what you do, then, if they have open vulnerabilities and there's no PR to fix it, do you just disclose it and not have the pr be generated or I, don't know if there's a good answer to that.

C

That's that you.

A

Know right is there any progress on private PRS.

C

That, yes, there is uh GitHub is going to be publishing that API Kate said in uh let's see, um features like in a private vulnerability. Disclosure uh currently does not have an API. She responded on March 9th that um this will be coming out in two weeks, but.

E

C

Azavia responded: this would also require this feature to be opt out instead of opt-in, So, currently enabling private vulnerability disclosure is an opt-in functionality on a repository. It's not it's not opt out. So almost all repositories across GitHub. Don't have this feature enabled.

E

C

Everybody aware of what GitHub private disclosure is.

F

um I could use a primer, okay.

C

um Get up so so are you familiar with GitHub security, advisories, ghsas.

C

Sorry I can't hear.

F

You Matt sorry yep I can yeah.

C

Okay, so GitHub security advisor is the way so when you're disclosing a vulnerability, the current flow is you ask a maintainer hey? Can you open a GitHub security advisory? They say: yes, they open the advisory, they invite you to it. You have the discussion there. The problem with that is that there's this lead time where you have to ask the maintainer to open a GHSA to let you report the vulnerability to them and so current. So the current model is like two stages right.

C

The goal of this new feature that get announced back in November is- or this new feature they announced- is the ability for main security researchers to report security vulnerabilities to projects um proactively. So there's a a under the security tab. You can select I want to disclose a vulnerability and that'll immediately create the private Channel you can discuss things in GitHub is not open this up publicly um for uh or it's it's an it's an opt-in feature that you can enable on a repository.

C

The reason that they make this opt-in is because they don't want to create a pro maintainers already have enough spam coming into them that they don't want to create another Channel or maintainers can get spanned, but in a place that GitHub can't um monitor right.

C

Does that make sense.

F

Yeah, so it sounds like the the regular flow is. You have to ask each time to open up a private Communication channel, and this would allow a maintainer to opt in so that they can skip that step in the future.

C

um Right so researchers can report directly, yes, they're. Also. um The other problem is that GitHub security, advisories ghsas when you're interacting with them. They previously have not had an Epi.

C

um That's uh so there's been no public GitHub API. For them you, the only way to interact them with them, is by the UI.

C

um So if you're trying to do automated pull request generation and automated security fixing at scale, um you can't you can't privately disclose those vulnerabilities right.

C

Right um so GitHub is adding support for an API for opening phase or opening private disclosure channels, and also interacting with ghsas via GitHub, um the uh so that that is coming, hopefully within the next two three weeks. So we should see that the outstanding problem is, if um so, maintain or opts out. The way that I've been handling opt out to this point is I. I will screen share um I've been doing this, so I have.

C

C

So in my campaigns that I've been running I have this.

C

Full request message: this is the pull request. Message, opt out.

G

If you'd like to opt out a future, automated.

C

Vulnerability security fixes please consider adding a file called GH or dot pH or sorry dot, GitHub, ghrobots.txt, I'm sure repository with the following line um for many years. No repository did this, um but more recently, uh some projects like the Apache software Foundation, um has done this, and the Jenkins team um did this at a at the top level in their dot. Github repository um uh I wasn't really necessarily considering that one, the Jenkins case, but the Apache software foundation in a couple of their Apache Commons libraries has done this.

C

So this is the kind of um standard that I was proposing um that we, you know if we were to do an opt-out mechanism. This would be the opt-out mechanism or there's another standard. That's um Luigi is working on a project that is like some Json file. You drop in your GitHub repository that defines a bunch of characteristics about it. Like is this project alive? Is it dead? Do you accept? You know, contributions, yada yada, um and so this could be another optional field in that standard as well.

C

um I would need to talk to Luigi more, but so there is there's mechanisms that we could support for opt out, but the question is for an open and source security, Foundation compliant automated vulnerability, fixed campaign.

C

Do we want to support, opt out and and Josh you you're arguing that? Yes, we should, um because otherwise you're going to piss off maintainers.

C

um Is it a global opt-out or is it an opt-out or a specific actor right? Is it I, don't want anything or do I only want.

E

B

Because yeah, like thinking about it from the perspective of like hey.

E

B

Have this Ruby Library I'm, maintaining um it could be that you find a particular actor, is not up to the Quality that you want, or maybe you tend to handle the patches for those directly rather than through whatever automation they have set up.

E

B

Because otherwise, if it's just a blanket turn, everything off I, don't know that it would get the job done, but and I guess the other side of that is. If you make it per project, then it's also well. If they have like 20 different things, they have to opt out of that might also piss them off. So um granular.

C

But also like the air is a granularity, but also an option to disable for all.

B

Yeah, if that wouldn't be too much trouble, um I think that would be nice from the maintainer perspective. Yeah.

D

Where's my mouse.

B

Because, for example in when you originally asked this I thought you were talking about like per like user account or per project, but, for example, you might want to on one project turn everything off, but another one just turn one or two things off or keep them all on.

D

C

uh Okay, so this will be actually, this will be, HP opt out.

C

um So we'll add I will add a section for opt out, defining what opt out means and how that works. um Denver. Is there anybody else who has a Counterpoint or counter argument to whether or not they should opt out or support for opting out.

F

E

Sounds it sounds.

F

Like to me, they would have legitimacy and be more like mailing lists versus spam, um but I just I, don't think I understand what would be the Dynamics between if you wanted, only um certain campaigns or certain submitters to do it. um Yeah so I think exploring the granularity and like what do some. What do package maintainers want? It's interesting.

D

C

The Counterpoint that I have to not supporting opt out is these are the I. The goal of any of these campaigns should be at at worst, a security hardening and at best fixing a valid security vulnerability right.

C

So, given that these projects are not just about the maintainer's perspective, but about all their Downstream consumers right, it's about the security of not just the project, but also the downstream consumers.

C

Do we want are we are like if they're, if they're repository, accepts contributions and hasn't been archived, do you want to support the ability for maintainers to drop Josh? You got a hand up.

B

Yeah, um my thought would be like, at the end of the day, you're going to get a security vulnerability ID for it and whether you care is kind of up to you, but that protects the end users, because hey this project has security vulnerabilities, they're, choosing not to patch them, um but you still give them the option of not having to be bothered by it.

C

hmm So we could still get uh so contacts. Josh works for GSD still.

B

um Yeah so Cloud security, Alliance and then the GST project is one of our open source initiatives.

C

So GSD is a database of vulnerabilities and it it I've spoken to culinary gsds is like cve light, so it's an IV id4 vulnerability, but it doesn't necessarily need to go through the vetting process that CBE requires and so you're saying that we could theoretically assign a G's GSD to it. Even though right you fix it or you fix it, but you don't contribute it and you publish it somewhere, saying hey! This fix is pending with the maintainer rejected. It.

D

C

And um uh you still assign a gsdid for it. Yeah.

B

And one of the things that would potentially make that more palatable too is we're adding types of the ideas. So you could say this is a security concern versus this is a like confirmed vulnerability.

B

C

So should the um uh would it be good to generate the the diff and maybe have that sitting on a commit Branch, but not have the Polar Express get generated, so you can have it get to the point where the diff has been generated, but not the pull request.

B

That makes sense to me and what you could do is using the osbe schema put that as like an Evidence reference on the ID. So here's our demonstration of why this is a vulnerability.

C

Interesting Okay so still entering the dick.

D

C

D

D

um Don't you know linked the GS, you need to the dip, don't generate the pr.

C

Ok Okay so then so you're still disclosing the vulnerability in that way, but you're, not okay, and so you you can um so communicating that this is the flow right in in the main, to the maintainer saying like hey. If you opt out in the future, just a heads up you're still the vulnerability will still get published and still go public, but you're just not going to get harassed about it like. If that, if.

E

You wanted to you know if you want to, if you want to know about it,.

C

Great, if you don't, you know.

B

Yeah I think that's the best of both world because then maintainer can say: hey I, don't want to deal with it, but you're still not just saying: hey, there's a whole bunch of vulnerability to start going untouched. So.

D

D

F

Sorry I was interrupting. um I think it'd be nice to have if there's a, if there's a global opt-out um to have that data accessible um because I know some some folks are um they're putting together sort of scorecards and you know other ways of evaluating open source repositories so um yeah, if they're, if they're not accepting these, maybe that'll factor into a signal so having one Global opt-out list, um that's accessible.

C

Yeah I I well I mean the way that I'm there's no. What do you mean a little Loft at like requiring people to register to a single central location instead of um having them put put it in their GitHub repository.

F

um I was thinking that, if, if let's say you know um yeah, they might, they might have it in their GitHub repository. But if I'm developing a tool and I'm going to use that automated to put a bunch of pull requests that I'm going to have to go and look up the opt-out lists at some point. So that I'm not bothering those folks because that's sort of like what I'm imagining is the coordination from different people. Trying to you know um like comply with this specification.

F

Is that they're going to have to look up that opt-out list, such as making that also, you know available, not just the folks making the tooling to submit the pull requests, but also to others that are evaluating repos.

C

So there I think maybe ties in to another component, which is around security assertions, um and so, given that security assertions, which is a project that is also someone under Alpha Omega, is being built out as a a platform to show the stuff that could be a place where this information gets encoded. It's. So it's not a requirement of this working group that that information be centralized, but it could be something that the security assertions working group UI presents as one of those assertions that hey this project has opted out.

F

C

Yeah, and so that would make that something that is encode I think that the the encoding, the information that the opt-out is present into the repository, so source code means that you can always be using the late like if they decide to opt back in they can just change, delete a file from the repository right. So, um but you want that centralized location for that information, so security, surgeons, I think, could stop that problem.

C

um I will mention that yeah.

E

D

I will put a note there.

C

Are there any other? uh Yes, you gotta hand up, go for it.

G

uh Yeah just another use case, I see for the opt-out, is for um end of life, end of support uh versions, so you could have a vulnerability in a in a version of a package that is no longer supported and the maintainer will tell you: okay, I'm, not going to fix it. It's it's out of scope um and that's a use case where he'll probably opt to opt out for those specific versions.

G

But uh we still want people to know that if they're using these versions that these vulnerabilities exist, they're not going to get fixed um but and also the maintenance will probably won't want to get a constant VR uh request. So that's a use case where I see uh the update will be helpful. So.

C

That's a branch sort of granularity, then.

G

Yeah yeah, maybe Branch, maybe tags I, don't know, but but yeah end of life versions is something that so we should probably consider in that context.

D

C

um Although in your experience, working with customers or just in.

B

General, have you.

C

Seen cases where your end users want changes, contributed to multiple branches that represent multiple different versions of their application.

G

So so the the the the reason this pop to mind is uh there was this vulnerability recently where you had with open, SSL and node had it built in into their uh code, and then it was relevant from node 16 through note, 17 and up to node 18, and then, uh when node issued their security advisory. They said uh folks that are using node, 17 and 18. Please be advised. We have this vulnerable, open, SSL and upgrade, and then I told I reached out to the one of the core maintainers and I told you.

G

You have open SSL in note 16 as well, and then his response was yeah, but we no longer supported it. So we expect user to to update to 17 or 18.. So they didn't even thought to mention it, um but the vulnerability is still there so that and it's not something that they're planning to fix, because it's end of life right.

C

That makes sense.

E

C

Do you yeah, so what what has your experience been around contributions to multiple Branch, multiple maintained branches? Is that something that the customers have or you've seen experience.

C

A

I think it's common that they still use like git flow, the main branch for with some other Branch for the next release and so forth. So yes, it's a vulnerability. Fixing it across all of us would be important.

D

B

B

um I guess one thing I was going to add to that really quick is one thing to be cautious of. If you do start looking at branches is there might be branches that aren't tied to a major version and if you start opening PR's against those, oh boy, I.

A

Think, with open source, you could open it against the main and let them pull it to whatever branches they want. Yeah.

C

I think that makes the most amount of sense, so is that is that a rule that we want to encode in the in this in this uh policy that the the the change should always be contributed against the the um default branch.

B

That seems reasonable to me and then you can request having it be done for other branches, but by default it's just the default branch.

D

A

um But yes, when in in customer environments, they do commit again against the various different branches depending on what they want to do right.

D

D

D

C

uh Missing the meeting- it's all good.

A

And I think uh sorry to bring this up again, but I think private pivars for security vulnerability. Disclosures are critical, I, don't know how we can have GitHub enable those by default. Yes, that's I, think that's the main pushback that you've been getting from maintainers is that you announce the vulnerability before they can merge it and incorporate in all of their versions.

A

C

um Yeah the um I I need to so so Michael scovera is communicated with me that he's gonna be sitting down with the GitHub folks about that shortly. To discuss that feature and having it being enabled by default.

D

C

um There's one so under mandatory private disclosure, this other topic um the I. So what what I originally said was the top 10 vulnerable projects within the top 10 000 critical, open source projects, as defined by the open SSS security critical projects working group must receive private disclosure reports manually if needed. Disclosures may follow a standard disclosure timeline example. 90 day disclosure timeline the um so two problems with this line when I wrote it first off the top 10 000 critical OSS projects list is not an ordered list.

C

It's an unordered list and the second problem with it is that that list actually wasn't developed by the open source security, Foundation critical projects working group. It was developed by Alpha Omega. So um one of the concerns that I have is if there is a list of top 10 000 projects and you've got a vulnerability that impacts the top. You know or impacts 100 of them, or you know a thousand of them.

C

You're expected to do private disclosure to all a thousand of them in one of these campaigns and like that seems like an excessive, it doesn't seem necessarily excessive. It just seems.

C

um It's a difficult proposition to say: you've got to go through manual disclosure on all all of these projects um and so uh Brian, spelling Brian, Bell North's response to this is why only the top ten shouldn't reports all be private at first um and my thought is: I, don't know how to solve this problem right like you want. You want to privately disclose to the critical projects, but if there's, if they haven't, enabled get a private disclosure, how do you do this in a way? That's same.

C

um There was a flow that was proposed by uh yes Nia and myself. That is a corollary to this, where you automate the process of issuing an issue requesting that the maintainer enable private disclosure and then from there you.

C

um If the project doesn't opt in within 20 days or something like that, then you will automatically generate the pull request.

C

But that's a bunch of additional automation that you then have to write to do that. Work and you know that flow as well.

F

Is there a potential to solve it, sort of one time to say that if you want to be in these top 1000 list- and you want to be getting the private disclosures that this is what you need to do.

C

So the top 10 000 is intended to be a list of top critical open source projects, as defined by either the open source security, Foundation critical projects. There's like a there's, a calculation that I can't. You can run against a repository to determine if it's in the critical like give it a criticality score, um then there's also the Harvard census. That was done that determined what critical open source projects were. So there's a couple of lists out there that were kind of glommed together to become the critical 10 000 list.

C

So it's not something that you opt in to be becoming a part of it's something that kind of gets determined by data accrued over time.

C

I mean you can make a solid argument for why you should be a critical project and we probably you could probably get at it. That way.

F

Or maybe- or maybe it's not about whether or not you're a critical project it's just about if you want to receive the benefit of a private disclosure.

C

Well, the idea would be anybody who has private disclosures enabled can get them that way right. You just have to enable it, but you're, not if you're not going to use github's like if you're going to say yes, I want a private disclosure but I'm not going to use github's flow.

C

That's the problem right, because then that takes it out that takes the the process out of band right. It means that they're, expecting a private Disclosure by a different Channel yeah go ahead. Gosh I.

B

Hope, maybe a dumb question. um So what's the distinction with these critical projects or like wanting to do the private disclosure versus public? Is that just because the Fallout from doing a public disclosure could be more significant, yeah.

C

Honestly, that's the idea, yes, so so Trying to minimize the downstream impact.

B

D

C

C

If so, I mean one alternative is to say.

C

When, when this feature get like when, when there's an API finally for get a uh security advisories, we can get to the point where we say all right.

C

You have so like mandatory private disclosure. You must, if the if the project that is vulnerable is in the top 10 000 list, you must request that the project enable GitHub private disclosures. If they do not within 20 days, you may issue a public pull request.

B

Would it make sense to just have this policy across the board.

D

B

So just always try to go for the private disclosure, or is that just a problem of it's.

C

A problem scale yeah.

E

B

Because if it becomes manual, then obviously everything kind of goes out. The window.

C

Yeah, the the other big issue that I've run into is: there's a lot of projects that are unmaintained and so someone coming across a project. It's more I think at a certain point, it's more important for somebody to come across an open source project and see the pull request, but I guess we're still putting that 20-day timeline on there right, like you,.

E

C

Don't act on this issue within 20 days.

B

Yeah, because that would kind of have the same effect where hey they didn't respond for x, amount of time now we're making it public and if that's just the only PR people see when they go to the project. It's going to be pretty obvious that hey this thing isn't being touched.

C

So I would love to get here when GitHub supports it. But do we build this document around what GitHub doesn't support today, but will be or we theorize that they're supporting or do we build it around? What GitHub is currently supporting and then modify it once there are more capabilities that we can work with.

B

um Something else that comes to mind is what, if projects are hosted on, say a different platform that doesn't support this yet so maybe the same thing would be having something to find where, if the platform doesn't support automated private disclosures, you do one thing and if it does, then you just use automated private disclosures.

C

D

D

C

Right, let's um so so the current state of the world is no platform supports this right. No platform supports this. So, given that no platform supports this, we're currently left with open pull, requests right and the thing we're trying to avoid is private disclosure or sorry. The thing we're trying to avoid is the problem. We're trying to solve is the scale of the problem right. The scale of the problem is: you've, got 50 60, 100 000 projects all with the same vulnerability.

C

um At a certain point, you just have to open the pull request.

B

Is there a way to automate notification.

C

No, because every single project has a different disclosure channel right, some of them use hacker one, some of them use security.txt. You know some. Some of them have a security email address. Some of them use bug crowd because the the disclosure, um because there's no standardized disclosure Channel.

C

Doing this at scale is a problem.

B

Yeah, it's pretty tricky.

B

I mean dumb idea, and probably don't do this. um What if it's something like creating automated issues to say, hey, we suspect we have a vulnerability for your project. Please contact us.

C

This is exactly the problem we're trying to get away from because it just overwatches.

B

And cares yeah it pisses them off.

C

Yeah you're, more likely to piss I I, feel like that's more likely to piss them off than than just giving them the change and saying here merges please.

B

Yeah I definitely agree I'm, just trying to think of how we navigate this.

F

um So, with respect to do we make the dock for what's available today versus, what's available next um I think maybe I haven't. You know, I missed parts of that.

F

You know the maybe it's written here in somewhere in the dock, but um it sounds like if the time is going to take to you know to review and ratify this document and then to get people that actually put in practice. It's going to be longer than some things like that. You know you mentioned earlier, maybe two to three weeks for um some things to become available or apis for the um I think you know they could have.

F

um What's it called they GitHub security advisory. um You know and something like a timeline like that I think it's reasonable to plan it out and have the discussion. Otherwise, maybe you know have a section or for proposed, like um you know next version of this, so you could. We could have a broken out in section of for okay like what's you know what is going to be the um you know, the next version.

E

F

The stock um with future facing uh features that we expect to be there and then that can help shape what we're a Consolidated view of whether the request would be to different. um You know different repositories.

C

C

So I think that what so yes, given the timeline that this document is getting processed, I, think that if we've seen two weeks, we'll get up supports, that'll be really valuable. I mean this is this. This working group doesn't meet until two weeks out anyway, so we will hopefully see what GitHub announces between now and then um yeah I think I think that so there's two solutions.

C

This problem either we order the 10 000 like either we get someone to order the top 10 000 projects list, and then we can say like these are the top 10 or 20 some odd projects within this list right like or these are like 10, 20, critical impacted projects or we remove this or environment and like make it a general rule, if you have to you, have to use ghsas whenever those that's supported, but then how do you right? So how do you? How do you?

C

How do you do this on platforms or not GitHub, right.

B

Yeah, for example, I imagine, there's going to be quite a few on git lab and what do we do if they don't support it? It's.

C

Not a ton on gitlab, but yes.

B

G

G

Also, the list will probably, as you mentioned before, it's it's probably dynamic in a sense, so the 10th critical today won't be the 10 critical tomorrow or next week or next year, just.

C

G

C

Yeah, the other thing that I was thinking about is, let's say you run the campaign and you get. You know you report it to the top 10 privately and they fix it now. The top 10 is shifted to cover different top ten, because one of them in that list fixed it.

B

Yeah I feel like trying to distinguish between the top projects and the Not Top projects is.

B

Making it more General might be a and.

G

We can also just.

B

Put a pin in this for two weeks and.

D

C

Just happens, yeah.

B

Yeah and nail down the other stuff in the meantime.

E

C

um There was another thing that Brian wanted in this document. He said uh a public so for vulnerability. Messaging, a campaign must include information like the impact of the vulnerability being fixed, a description of the code change with the fixed.

D

Vulnerability identified a.

C

Public page describing the campaign and its compliance to this policy and a contact information example.

G

C

For real humans who could follow up on the pr I was thinking that that so he wants to add that as a requirement, I was thinking. If we, if we leave that requirement in there, that's fine, but something that can satisfy that constraint is just an issue that, like all these like that can be a website or a page.

G

Or templates for the issues that are open, which that contain this information.

C

Well, so what I've done previously is I, just if you go to my issues, I just have like both PR tracking. So these are the tracking issues, and literally every time you open these tracking links. Every single pull request is linked back to this issue, so you can see all the pull requests that were generated from this that and so that information could satisfy this policy right. You can just use a GitHub issue with that.

C

Does that make sense? Is that, like a yes, we can do.

B

That question um so having the contact information makes a lot of sense. The page for the campaign I'm trying to understand the distinction between that and just the description, that's already in the pr.

C

That's a great question: I think that it's going to end up being duplicated information, honestly um yeah I.

C

Mean yeah because.

B

If the intent is understanding- okay, why is the campaign exist that it needs to exist somewhere? But if it exists on the pr that kind of solves the problem, yeah.

C

C

All right, that's one of those questions.

G

Maybe maybe ask like what what is this public page supposed to serve like? Why.

C

So Brian's argument is that uh it should uh should be an initial PR message that people see it immediately at Ru. Why wait until you know wait that was the point of the public page is describe the campaign and give reference Authority.

C

Yeah, so it's it's to give reference Authority like this is the source of this thing right. This is the.

D

Like without being a.

C

I don't know I'm gonna talk to Brian about that and ask him to give further feedback on this on this issue. um Xavier wanted to add this requirement that uh there was a statement that the pull request had been reviewed by a third party.

C

um The topic being like um he said, okay, so this be a can, not a must the the idea being that, like the pull request, has had some third third party externally say like yes, this looks like a valid security fix, so it can't be within your organization. So let's say, you've got tralex issuing the polar price you've got to ask some other third party organization to vet. Your change.

C

G

Complication to the process and slows down like like how how would that work.

C

um So in the past, I have asked to get up security lab to review the change that I'm going to be making so like I tell them like hey. This is the this is the this is the what the change is going this. This is what the change will be that I'm making. Does this make sense.

C

It so his his point is that it it uh so it says, uh I think that adding this info in the pr, uh uh if this third party is willing to add its name to The Campaign, which might always be the case, adds more weight and decreases the suspicion of bad intention.

G

So so the idea is in terms of the flow that this, this kind of peer review will happen before the actual uh automatic VR is created, and then in the pr it will, it will be listed, for example, this this was reviewed by.

C

Yes, numbers are necessarily every single pull request, but the the some examples right unit tests or something like that that demonstrate the change right were reviewed.

G

Yeah so I don't know if I put it as a must right, maybe is it desired? Yes,.

D

D

C

This info, in the pr.

B

um It might be worth distinguishing between the pull requests being reviewed and the code that automates support, request being reviewed.

B

um Maybe you could distinguish that, as this campaign has been reviewed by a third party. Yes,.

E

C

E

B

Differentiating between the direct pull request per project versus The Campaign as a whole, because I assume, like GitHub security lab, is not going to review each and every one of your PRS, for example. But they do review the code that generates it.

D

D

um So let's do.

C

D

E

C

E

C

Communicate the following: let's think of this pull request.

E

D

D

um This review me.

E

Foreign message.

C

B

um I guess my two cents would be being pretty explicit about it being the campaign and not the pr, um because they assume the intent is hey. This isn't spam here is this third party that took a look at the campaign that we're doing yeah.

D

B

Agree that this is legit.

E

B

um Especially because one pain point that you could run into, if you say hey, this PR was reviewed by the third party, is then what if the pr happens to be one of the edge cases that you missed with your unit tests and they're like freak out over the code, change being either incorrect or applying to the wrong section of code?

B

D

C

Yes, does this need to be changed in any way to describe that better or.

B

I think what you have right now is good.

C

We're at time, but I want the one final thing I want to cover is uh I agree with zavier's Point here and automated vulnerability. Fixed campaign must not be used to advertise a company or product or service. Does that make sense.

B

A thousand percent yeah.

C

I would add the caveat that while it can't be used to advertise a company or product or service, it can be sponsored by right. It can't be used to advertise, but it couldn't be. The the campaign can communicate that, it's being sponsored by so and so by by an organization.

B

F

What's the difference.

B

Yeah because I could see sponsored being viewed as just being advertisement.

F

If you're using.

C

The if you're using the campaign, the pull request body to at like outwardly, describe the like the features of this thing and like you know why you should buy it or something like that.

D

Right like this, so this.

C

Is an example of the.

D

The source opting.

C

Out um sponsorship and support: this is what I put previously in campaigns like this contribution was sponsored by human security and the new Dan Community Fellowship, a fellowship creative, celebrate dance memory and Legacy by funding open source work that makes the world a better and more secure place is PR was generated by.

G

D

C

For open for free for open source SAS offering uh that uses format, preserving AST transformations to fix bugs standardized code and apply best practices, my migrate Library versions and fix common vulnerabilities at scale, so it's not really is it. Is that an advertisement.

B

Speaking personally, I would be fine with it, but I could also see why this would be a super touchy and gray area for a lot of folks.

B

B

Because the question becomes: where do you draw this line of hey? This is just who is sponsoring this project who's, helping make it actually run versus hey by the way check out this other stuff we do, which would kind of tip into the Red Zone I'd, say.

D

B

Kind of probably a good one to open up to a wider group for discussion. Yeah.

C

I will um I will I will say so. I added it to the spec. All right, I will work on this document more and try to review some more feedback. um I do want to close it out. We are five minutes over um anybody. uh Thank you for coming. um I, hope, I'll, see you all in two weeks, um it'd be lovely to see you all again.

C

um Hopefully, we'll have a little bit more attendance too um I know some people that meant to make it but couldn't um and uh feel free to continue to look over this document, read it through and add comments and and suggestions throughout it. um You know the more we can um uh move this document forward, the the best yeah. So thank you all um any other questions or concerns or final points.

B

All good, on my end thanks everybody Perfect.

C

All right, I'll see you guys in two weeks, thanks.

E