OpenSSF Vulnerability Disclosures WG, 12 Jul 2023

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: OpenSSF Vulnerability Disclosures (July 12, 2023)

Description

Meeting minutes: https://docs.google.com/document/d/1jzqhW9SK9QRA39fQz0RiAkvpRWB0xztt1TAFJEseTlA

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

A

Hey folks, we will give it a few moments. If anybody has anything to talk about today. Let's add it to the agenda.

A

Otherwise, it could be a very short meeting.

B

Let's see if I can hear you now, can you hear me I, don't know if I can hear you, though,.

A

Why can't you hear me yeah.

B

All right because I have my PC hooked up to I, have the same same surrounds on split systems that hooked up to a multi, multi-output system, and so I can have my gaming PC or my Mac hooked up and I was playing games last night. So I'm like whenever.

C

I start my morning again: I forgot to change it over, so you were saying something when you logged in and I could be your.

A

Oh well, if you have any items for the agenda, please grab them. Otherwise it could be a very short call, because I don't have anything to talk about, but I'm glad to talk about things that the community are excited about.

B

I have a thing to talk about.

A

Why isn't it on the agenda? Oh.

B

Because the meeting notes aren't in the chat.

A

uh They're in the same agenda we've been using for the last year, all.

B

A

B

That they finally finally remove that redirect link so that it points to I, don't know that document! Oh, no! No! Okay, we're good! You.

A

Work there, man I.

B

Do doesn't mean I run everything.

A

See I have a policy and.

D

Brian generally,.

A

Don't come to meetings if there is no agenda or items on the agenda, yeah yeah, so I'm going to start enforcing that.

B

Brian Russell over there funds this thing he doesn't run. He doesn't know how the whole thing works either.

A

It's because paying for it doesn't mean you know how it works or care exactly I just wanted to work. Damn it yeah.

D

B

It's not my money.

A

Well, it's kind of my money too. You know yeah.

E

Yeah I I would say it's it's many many organizations Monies back to the topic, though you said that you had some things to put on Jonathan or I: do. Are they on there at this point, I'm I'm working on that? Okay.

A

Having an agenda before the meeting helps people prepare and then decide if they want to come. If it's something interesting.

B

I would assume that the rest of us are in operating of ADHD and do the thing to the last minute in order to you know, make sure that our lives are on track.

A

Sometimes your lack of planning is not my problem.

A

Boy Scouts taught me always be prepared.

D

A

Also, how to cook a biscuit on top of a fire I made with straw and uh rubbing two sticks together.

D

A

I know it's not as useful.

C

I never got past.

B

C

I never got past whatever. The first thing is for Boy Scouts, like Tenderfoot I, think like partially got the second flag second class and then didn't go very far.

C

There's no something I was motivated to do.

B

I enjoyed the camping, I enjoyed socializing I didn't need to move up in the ranks in that particular organization.

A

All right so, as folks uh join us, please add things to the agenda: Jonathan added an item underneath the cve auto fix subgroup.

A

So if you scroll down a little bit to the sub project,.

B

Team end up with the cve in the beginning of the damn name.

A

I I, don't know it's only been on the agenda since the dawn of time.

B

We don't have anything to do with auto fixing CVS.

A

Would you like to talk about your topic Jonathan.

B

C

um After many weeks of chewing.

B

On it, the um specification for open, ssf compliant automated vulnerability, fixed campaign is in a state in which we are. We are seeking additional feedback on the document, given the changes we've made to determine if it is missing anything that people think we really need to have in there.

B

For, for the specification uh and I presume that there's given a specification, there's a lot of verbiage in this document that currently doesn't um uh is not specification standard sort of like so we should probably make it better in that aspect, but um I will screen share real fast.

B

um Okay, so a couple of main areas, this document covers I, should have sent this to the email list for this meeting. Adhd um uh yeah all right. So um the goal of this document is to Define what it means to be operating in an open, ssf, compliant automated vulnerability, fixed campaign, um and it describes a set of constraints under which you must operate in order to be considered um uh unconditionally compliant.

B

um So the first requirement is to report all vulnerabilities Upstream in particular, uh the vulnerability must be reported Upstream before you attempt to do a bulk pull request like so. For example, you must try to get like you can't, just like you know, start doing both lower Quest generation without having worked with the Upstream maintainer to try to fix it in the vulnerable library right like we. If you can fix it Upstream, it's always best to fix it Upstream than trying to fix all the downstream consumers.

B

The cases that make that may not be sufficient.

D

B

When vulnerability exists in um code generated by created by code, generator I have firsthand experience with this. There was a vulnerability in 15 000, open source Java projects across the industry across GitHub, because um some code generator was generating in uh vulnerable code and people kept pumping it out and creating GitHub repositors from it um or the vulnerabilities in a project. That's vendored widely, as is often the case in civil.

F

Plus libraries.

B

Or uh libraries pre-package manager, for example, jQuery.

B

um Then there's a requirement to do coordinated non non-automated, private disclosure. This is mostly in cases where the vulnerability is not newer or is newer novel right. So if you're dealing with a new or not vulnerability, then then you must at.

D

Least, report to a some.

B

Number some number of of um projects privately, um if they're not vulnerable, it's not new level.

C

For example, external.

B

Entity processing to do in properties, so the Java standard Library, which is very well understood, vulnerability. We've talked you know, there's a bunch of documents about it, then coordinated uh non-linear product disclosure is not required.

B

um Then private disclosure there's a discussion around. What is private disclosure? What is PVR? What should be you know, pmpvr, which is a programmatic means of private vulnerability. Reporting GitHub just calls this private vulnerability. Reporting gitlab has private pull requests, um requirements of how to use this and then Additionally. You must use the open source project.

B

Osf, slash, disclosed check tool to find the relevant security contacts and email them at the same time as you try to request um Disclosure by it, you basically, you simultaneously ask them by issue to enable the feature and also send them an email with the pat with the vulnerability in the patch um and then there's this flow chart that describes um uh describes how pmpvr uh or sorry how this, how this entire flow Works um there's a line.

B

That's missing that I'm going to update the image uh there we go um and then we have some example: scenarios that were written up around like take.

D

This document run.

B

Through some scenarios that explain like what would happen, these are really useful use cases they're contrived examples, but it helps explain, sort of some of the flows um and then four automated fixed patch um avoid patching test code exclusively. So you should try to fix non. You should try to fix it. You should try to not create pull requests that only fix test code.

B

Basically, um the pack Target should be the default Branch external review requirement um campaigns uh should be uh the fixes should be reviewed by a third party um uh in the past. I've used GitHub security lab to review like patches and stuff, like that. So, like you know, make sure it compile stuff like that, um offer a requirement to offer disclosure assistance during the process and then some requirements around messaging um uh uh anyway, um so like what what must be included in the in the vulnerability disclosure, what uh should be included?

B

um What must not be included in particular um uh marketing should be excluded um and then um sponsorship messages um must be posted on if you're into your sponsorships or stuff. Then that goes in an attach you can you can link to a document that describes the campaign, and that is where sponsorship information goes.

B

um This is the part. That's a little bit less fleshed out um this topic of opt out, um so there's a requirement that you do have an opt-out mechanism. The only one that we have for like a standard is the open, SS security, Insight spec, which is the thing that's being developed uh by Luigi.

B

um The problem is that um uh this is the minimal spec and some of the feedback that we got from people are is that this specification is too verbose to be a a valid opt-out. We should have something that's simpler than having to drop an entire file in your repository that, like and I'm, going to fill out all this information in a valid way, um the goal upside was. We were trying to encourage the use of the. If you're going to opt out, we were hoping that you would at least um follow a different standard.

B

The open SF is offering downside. It is more verbose and heavy more heavyweight. So, there's a discussion around like what alternative um opt-out mechanisms we want to support.

B

um There was a discussion about using a standardized flag and a security.nb file, um something in the git ignore or get attributes file or using something like the GitHub robots.txt file, which I currently am using for my campaigns in the past um on what the opt-out behavior is is that you must create a private public fork or sorry. You might must create a public Fork from the vulnerable repository um and create a dedicated branch and apply the patch, but you must not create a pull request against the opt out or opted out repository.

B

um You would publish a link to that publicly. A Global Security database ID might can be assigned and the maintainers must not be contacted by the campaign operators regarding the disclosure of the vulnerability. So, if you've opted out, the vulnerability still gets published, it still gets public made public the maintainers just don't get made aware of it.

B

um uh Let's see vulnerability fix origin. There's a discussion of like what get up what what style of GitHub account you should be using um uh maintain their communication. Responsiveness.

B

um Like you know you might you can't just run one of these campaigns and like be done, you have to actually engage with a maintainers when they have feedback um the ability to redeploy and rebase changes. So you must. Your campaign must have the ability to if the maintainer says hey, this is broken.

B

Like you know, you should be able to rebase those changes with an updated fix from your campaign and then some standardized messaging around, uh like you know, GPT key signing and ccom conventions and then uh coordination with the host uh around um contacting GitHub in order in in in or whoever the host is before you do this work or you use their apis in this way. This is a high level um of the um the specification. Yes art, it's in the uh I'm. Sorry, you know I.

G

Didn't I didn't look there I'll go look! Thank.

B

You anyway, right there, it's right. There I got you.

C

So yeah, so this is this- is the the document.

B

We're looking for feedback on are there things we even thought about? Are there? um uh Are there things we even thought about? Is there more that we need for this to become a proper specification stuff like that, so um Crow.

A

What's the deadline you'd like this feedback by, is there an issue or you just want it right in the stock.

B

I I I need this within the next three hours.

B

A

Will not be able to contribute I'm. Sorry, no I.

B

uh Yeah no I'm I'm uh I'm, going away on vacation for the next two weeks. So sometime within the next two weeks to be lovely.

B

um Also so I'm gonna be running the um I'm gonna run this week's autofix Sig, um but uh I'm gonna be in California from next Tuesday to the following set for 10 days from that next Tuesday. So the six that I've been running are probably gonna. Go unpaused for both of those and I will not be making the next one of these meetings. I think because that's in two weeks, right, yeah, so I will be I'll, be seeing you all in four weeks.

A

But you would like the feedback within the next two weeks, correct that would be lovely.

B

From my cursory overview of this document, are there any questions, concerns.

E

I wanted to bring up one thing: I think I have a an unaddressed comment somewhere, I think about the second page in um uh no go back up yep right. There.

B

Yeah success metrics, um so he.

C

B

Agree that the alpha omega should be tracking this information I'm, not certain. If we want to include this in the specification for because this, the idea for the specifications to Define the set of requirements for anybody who's implementing this specification implementing this um do. Do you want to see success metrics for everybody that does work like this? Or do you just want to see it for Alpha Omega? Because we'll be you know, you're you're, a stakeholder in Alpha, Omega.

E

Yeah I mean it's, it I would say. Ideally you know we kind of have visibility into everyone. That's involved, but Alpha Omega would be the main uh starting point for me, and you know I I note in the comment too I'm not sure if it's really right for the specification either but I I think thinking about it having it down somewhere uh such that you know we can kind of see.

E

Is this process working because I I think um I think everything that that you've laid out just generally makes sense, I think for any process, though, that you put out there there's kind of an unknown of of how well it's it's actually doing the job it set out to do so. That's why I think it's important to really track uh is this?

E

Is this achieving those goals from the get-go yeah and then, if it's not, you know, we can say, let's go back to the specification and and tweak things and kind of treat it more like an experiment.

C

C

Yes, I, agree: I, yes, so I think that in.

B

The infrastructure that I'm building out, which is another Repository.

B

C

I'm gonna surf no, not a subject.

B

Oh there we go um so this is the um this. This diagram here is a flow graph. um That's gonna, take it slow, okay,.

D

That's a flow graph, but the there's.

B

This project, which is the open Audible and this blows project which I've been working on um to uh to basically take the this flow graph and turn it into something that we could actually operationalize in in a code base. So this is a state machine for that flow graph, and ideally this would be something that would um have a database, backend and stuff like that. So you could take. You know information about how long it takes to transition between these states and stuff like that and use that for metrics as well as understanding.

B

Like is the issue closed. You know what stage is every single thing in so so this this would be um more the portal for that information to get captured, but yes, the the that it is something that we want to consider capturing I. Just don't know if it's good in the specification or more just like. Let's make that something that we put into the code base for this.

E

I mean I I think what you could do is maybe start a separate dock link to it. So it's not it's not really blocking the proposal to get the success metrics down, uh but I think you know. If you said you know, the specification is uh linked with these metrics and you know we we can always just pick arbitrary metrics, but I think we have to be a little bit more thoughtful.

E

Think about a statement of of what we're trying to achieve, maybe some goals of of how we know um basically make the goals, explain how we know we're getting there and then make make the metrics back those goals up and I think.

B

E

That that will give us a really useful sense of did. We did we all give good feedback. Did we make the right decisions on this proposal?

E

um I right, there's a tendency to kind of just treat any sort of specification or a process is kind of uh we designed it once and and we're done with it I think a lot of times.

E

It might be better, looked at as an MVP where it's like everybody thought this was probably the best that we could do, but sometimes the real world uh kind of resets expectations once you start going through it uh and and I think if you have metrics to work against you know, then, when you make changes, you can also cite those and say Hey. You know we're trying to close more issues, so we're modifying what we're doing here. We've changed the language of this email or we've. We've changed the time that we we resend emails.

E

Things like that yeah.

B

Wouldn't it wouldn't it just absolutely suck if we found out that um actually opening public pull requests for security vulnerabilities was actually faster and quicker and and got more things fixed than doing it privately sort of thing right.

E

Yeah I mean that's, but but that's something that we want to know right.

B

E

Yeah, how are our decisions and what we think is going to be good actually? Is it actually good? Yes,.

B

Yes, that makes that makes a lot of sense. All right, so I can I can write up a success. I'll basically take your comment and expand upon it in a separate document.

C

I, don't know if we so one.

B

Of the things that I found is when, especially when it comes to publishing specifications, is that if you link to another document in the specification and that specification doesn't end up getting I with the with the um the model, disclosure policy.

D

Like I had a link.

B

To this document, but this document was under active development um people like the lawyers and stuff like that. Don't love it when you're trying to productize a final document- and you have another document- that's a work in progress. So um so we will tie them together in some way dependently conceptually in our own hands, but we may not have a direct link between the two of them within the contents of the of the reading of the document.

E

I I think this is where maybe the phrasing that goes along with the link of that document is key. To basically say you know um here.

B

Are some things you might want to consider for for Success yeah.

E

And I I think you can be very explicit and say uh this document doesn't need to be blocked on agreement on success.

C

Right so that might actually be process yeah.

B

Yeah, so that might be above the protocols right. That might be a section, then, if it's, if it's like these are things that you may want to consider in terms of considering success that could either above or below protocols. Right, like you know, um not something that you must implement, but these are some things you might want to consider success, metrics, yeah,.

E

I mean my criteria is if we can just find it back that.

C

D

E

On the dock somewhere is, is the most key.

B

Thing yeah yeah, that makes sense all right, I will um I will poke putting finding a home for that somewhere. In this document, then that's outside of the protocols all.

E

Right cool also, if you want to Riff on that or have someone just kind of to brainstorm, metrics with and write that kind of corollary, doc, I'm happy to take some time and work.

B

We will be meeting today uh and 2 p.m. Eastern Perfect come.

D

Hang out with us.

B

B

Anybody else any other comments, questions concerns um issues with this document, things that you know you want to see change things you want to see improved. You don't like a word.

B

Going once going twice sold to the man who's running the meeting.

A

Yeah, if anyone has any additional feedback, as Jonathan mentioned, uh let's comment on the doc- we'll probably talk about this later this afternoon in the autofix Sig, uh but please try to provide some feedback and the worst case within the next two weeks. uh We want to try to get this thing wrapped up as Jonathan returns, home.

B

Outside of me, email.

A

All right do we have any additional topics. The group would like to collaborate on today.

D

F

um I don't know if this is a collaboration topic, but I just wanted to say. Thank you, everybody for commenting on our uh vulnerability disclosure policy template. We really appreciated it.

F

um We you know, took I, think pretty much all of your feedback in. So thank you very much awesome.

A

Man you're very welcome. I still owe you a couple um comments from comments. uh It's not gonna happen today, no worries but yeah we're glad to help I'm glad you found it useful and I hope your community, you know, gets value out of it. Yeah.

F

We definitely will, and uh thank you all for uh thank you all for interacting with us um and yeah um yeah, we're happy if you've.

C

F

uh If anyone else finds that sort of template useful awesome.

A

Yeah, thank you team appreciate that.

A

Do we have any um additional topics we wanted to talk about.

B

Art, do you want to talk at all about our conversation that we had about uh uh CE drama, or is there any valuable takeaways that we can? We can share with the group from that conversation.

A

There's no drama with cve, never okay,.

G

Yeah um uh and Jonathan by no by no means to reduce the uh any say anything less about the nasty issue that it is. um It is a sort of pervasive. Oh.

B

Yeah, no no yeah, yeah, yeah yeah, not.

G

To not to say it's not a problem, um but it is fairly common and it's my position is it's understandably common. It's a little bit. It is truly tricky to figure out what this is um very, very quick summary.

G

um A specification for perhaps one angle on this could be that the uh XML authentication spec um has perhaps.

B

Go ahead, I mean the XML specification bill as not authentication special, but the XML specification, as written has extent or external entity resolution built into the specification. So anybody that conforms to the specification in their parser is themselves vulnerable to an a well understood, vulnerability, called external entity processing the Java standard, Library influenced this specification correctly and is vulnerable, and my kind of tirade in the industry is. Can we like make it so that this known vulnerability is not something that's opted into by default across all parsers?

B

Can we make it so that secure by default people have to opt into the vulnerable, vulnerable Behavior.

G

Sorry, thank you Jonathan for saying what you did better than what I was going to say that you.

C

G

Run on the money yeah, so this and this uh this has happened before right, faithful implementation of a vulnerable stacker protocol, and you know you can get into pretty interesting questions about vulnerability and should the should the spec even take care of this or not, but practically it comes down to. If this could be addressed at closer to the root of the graphs, it saves a lot of other people a lot of time.

G

It may be a breaking change. There is some real consideration to sort of go through here um and then so. There's there's that fundamental issue, and then how does CDE deal with this as sort of a another piece of the puzzle um and I'm going to say a number of hours have been spent uh by Jonathan and others arguing and discussing and trying to decide to assign or not and um pretty much.

G

My position has become if, uh if more than one learned expert has spent more than an hour or two talking about it, the answer has already been for another hour sign the cve. Already we can discuss the thing and publish the things, and instead of talking about that thing like she was talking about about Java or whatever or xxc I forget what it is. We can just say: cve blah the ID.

G

We can go decide it's not a bug. We can go, decide that the spec is going to be fixed or not. We can go decide that Java. Is there isn't going to do something? We're talking about hardening, which means to me seems to me like they're, going to respond, which means it should have a cve ID, but um that whole conversation is sticky.

G

I may, uh if we wanted to Jonathan I may try to raise it up at cve again, I believe Jonathan has exhausted the official CBE escalation path and the higher Court upheld the lower courts ruling to not assign in CBE terms.

B

Inspiring me to go, say: okay, fine! Maybe we should get a cve for the specification and be like okay, the CBE. You know the whole XML specification is vulnerable by default. To this thing, yeah.

G

And there's precedent for this there by the vulnerable, vulnerable specs in the past, and- and it is a reasonable thing to discuss but again- uh and this gets a little bit- uh sometimes argumentative within the CDE sort of board.

G

um What really is CBE about I take a somewhat personal position that it is about identification of the abstract thing, which is a vulnerability and nothing more, and it should not try to do more and that's where we get argumentative yes, anyway. I grew up. uh But um again, if you spend a couple hours with some knowledgeable people talking about it, the answers should already be set. Have a cve go figure it out. You can reject you can dispute.

G

You can modify cves later, but we have to talk about the thing we should have an ID and we should not spend I. Did this recently with a very large multinational, Hardware software manufacturer. No one should be spending fifty thousand dollars in time discussing whether or not there should be a cve ID you're.

B

You're classy at that point, lawyers are involved in the conversation too right.

G

uh No, not even yet that would be. That would be like double the price I mean. So there's a there's. This THX 1183 scene, where the guy is climbing up the ladder and the computer decides to stop chasing him. I think everyone remember that if you're arguing when you've spent more than a dollar fifty on a CPE assignment, did you spent.

D

Too much money all right.

G

Sorry yeah, so that's Jonathan and that's that's the issue. um We might take another crack at it from the spec side um approach with CDE and I'll. Tell you this when I spend my hours and still think that I'm wasting my time yep, it is good to push the edge cases, because that's how we advance the cve rules and the cve culture and all those things you have to take one to the highest port in CBE land in order to kind of push anything around anyway. I'm done ranting and uh croak.

A

Please I would suggest, since this is not an isolated incident, this potentially could be an excellent panel and or birds of a feather session at the forthcoming. uh Much talked about Volcan next year since we'll have all the industry luminaries together. It would be a great topic to kind of talk through what how we could potentially uh do improve in the future.

B

Is there um a cfp open for that yet or is it just.

C

An idea not yet okay.

G

I'd be willing to say and curb if you know better, please please correct me: March 24 ish. It sounds about right. Sometime.

A

Like towards the end of first quarter, I think is.

G

What I've got it's roughly scheduled?

G

um This comes from the land of sort of peace, art, Sig and cve Summit, and um the idea I've been proposing even if I was asked, was a day of pisert Sig and the day of cve and a day of other stuff. And then the fourth day is with the whole thing. Can we assemble this all together, because these islands of isolation are not solving our Collective problems um uh and I'm, saying that partly because CBE definitely wants to have a summit and they want to do all their cve stuff.

G

So, let's CV have a day with peace have a day have a day of other stuff, um which is also code for open source stuff and then, um but that's I'm, not running the show.

G

So uh that's just my suggestion, but I think there's real interest from multiple sectors this year and it's a great way to get together right, all US, Open, Source, hippies and all the commercially money oriented people and uh the government to see people and the coordinators and the sissas and the uh all of the folks and see if we could stream together a more functional vulnerability, architecture.

A

And I could say just for this foundation and it's a particular working group. We've got a very strong response of interest to want to participate and I. Think if you as we expand that out uh like the cncf or the GSD people kind of the uh open, ssf adjacent things, I think you get I think there's a lot of interest. People would love to participate.

A

um It sounds like Jonathan has a cfp in mind already yeah, but I think this topic would be a great example. Birds of a feather thing, great topic.

G

A

Yeah I think we very easily could fill a day with uh CBD uh philosophical conversations of events. We've had experienced and kind of like Get The Brain Trust, together to Think Through, how it potentially could get solved with this and there's many other challenges.

C

A

And as soon as I hear anything official I'll be glad to share it with this group and everyone that's expressed interest all right. Do we have any other additional topics? The group would like to discuss.

H

um I guess I have a quick update. uh I had mentioned last week about the tc39 tg3, the security test group for tc39 and that the chair election was coming up. So the meeting was this week yesterday the Share Group was elected, so um I think still working out the exact frequency, whether it's bi-weekly monthly, but those meetings will be resuming imminently.

H

A

Good and people can reflect back on our meeting notes when we had that conversation the last time if they wanted more information.

A

All right team, we will with no hearing no other topics.

A

We will adjourn so that I can try to fix my air air travel to Spain I.

B

Gotta I mean you don't have to you can go fix your air travel. It's not. You can I got another one if you want it. Just had a quick update on the um uh great artifact repository audit, um they're, active disc I. Think I mentioned this a couple weeks ago. It's the idea that um so see there's another working group with the Sig under the open source Security fund, no under the or securing software repositories working group.

B

The goal of the Sig is to try to see if we can find organizations to fund um pen tests of all the major artifact servers in the industry. um That conversation is continuing to move forward. uh Alpha omega's, um there's interest from alpha omega's leadership to fund it, potentially so that'll, be a discussion later today uh or happening soon. Hopefully, um the other topic that I wanted to bring up.

B

These are just like updates around the open, SF.

C

Those are vulnerability, disclosure.

B

Related because they are vulnerabilities.

B

Now I'll bring them out of that other one is. This is out of scope all right anyways! That's that study. That's the only thing other thing for me, so yeah.

D

A

Well, everyone enjoy the rest of your day. Happy open sourcing and CBD cheers all right.

G

Bye: everyone yeah, okay,.

D