OpenSSF TAC, 18 Apr 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: OpenSSF TAC (April 18, 2023)

Description

Meeting minutes: https://docs.google.com/document/d/18BJlokTeG5e5ARD1VFDl5bIP75OFPCtzf77lfadQ4f0/edit#heading=h.9m0zi4b0wnne

A

Laughs right, oh you're, ready for this morning, I.

B

I want to believe krobe, you have an actual air horn in your office and you just turn that on I.

C

I wish now I've got a uh two sound boards.

D

E

Oh um Brian, I, don't know if you saw this um Ian Coldwater posted on their Twitter they're. Looking for a job, okay,.

B

Good to know, thank you, sorry, we're recording now so uh yep welcome everybody.

B

What have I noticing the agenda we weren't going to have a readout from the vulnerability disclosures group unless that's something that has just been added, um did you think that might happen, or did you want to defer it to the next meeting.

C

Was I on this calendar for today, I.

B

Can do it? Okay, well, I! You know if you wanted to to prep uh I, think you'd be granted a clearance as well, but there's a table at the top or on the second page of the attack meeting notes of yeah.

C

I lost track of it. I thought it was. Somebody else was the victim this week, no I'm ready now, okay,.

F

The agenda was under embargo, probe, I.

C

F

Released it oh.

E

Man, which uh which wait the open the vulnerability exposure working group, is.

B

Yeah that was scheduled to report today, um but uh that's that's fine.

E

I can help too, if you need me to fill in anything I.

C

Can sound like an expert on any topic with 30 seconds of preparation, perfect.

C

It's my specialty.

A

Small circles, we call them one take Crow.

B

I dare say we have a quorum.

G

I think we do, in uh apologies, I'm playing a bit of a meeting room roulette here in London, so I'm hoping that uh hoping this rooms, even though I'm squatting, it'll stay available.

G

um So as Brian know, it looks like we do have Quorum, so we will go ahead and get started. I just wanted to give a quick update. I know that the last attack meeting I had given an indication that, uh at this tech meeting, we had hoped to had fully seeded the the new tack.

G

um The governing board is uh currently in process with finalizing their votes for the appointed seats, and so that process will run through the end of this week, and so at the beginning of next week we should have the results to share, and so I take back what I said last time and the the next tech meeting uh coming up on May the second. If my math serves me right, uh yeah May, 2nd, uh we'll have the fulltack the new tax seated.

G

So just brief update on that front, um and with that we do have quota for we are uh we'd. Have uh Quorum rather is the and I'm getting kicked.

D

Out we have Quorum.

G

I'll turn it over to Dustin to go ahead and give the update to the from the securing software request. Working group.

H

No worries: hey folks, a quick update from securing software Reaper's work group a reminder that our our mission is to bring together all the maintainers of some repositories Registries uh and discuss our our various shared problems. um I chair this group with support uh significant support from Jacques Chester.

D

H

Newman uh we meet every two weeks in alternating time zones uh to maximize coverage across the time zones. We usually have about 10 to 20 attendees. Depending on our agenda. We last updated the attack in December 2022, so I wanted to provide a couple highlights since then. So one is around salsa we've had a lot of discussion and collaboration around some aspects of the upcoming salsa 1.0 specifications, specifically around distribution and discovery of salsa provenance.

H

We work together to publish a guide to Distributing provenance for the salsa 1.9 spec and that'll, be in the uh it's in the release. Candidate now we'll be in the final version, and we had significant input from many folks in the working group on that recommendation. So that was a really great collaboration um and we've also been providing some light support for npm as they ship build provenance uh and beta, uh and uh you know determine their attestation format for salsa.

H

um We also in the last couple of months have sort of finalized our survey that we performed of Open Source software repositories, sort of aggregate. All the data um kind of two takeaways from that one is that we published a blog post about this on open, ssf blog. We also sort of summarize our key takeaways and recommendations. So uh all the things in those takeaways are considered actionable things that we could.

H

uh You know the surveys reveal to us that we can take further action on and the last is, there's been a bit of work in collaboration around supporting publishing via oedc, first and for repositories.

H

um Ipi support is currently in beta I think this would be the first software repository to support it um and we'll be launching this week, and we've had a lot of discussion about that feature, as well, uh specifically between uh the pipi and the npm ecosystem, which is uh kind of support this soon, as well. I think uh some upcoming things so there's been a lot of discussion around a shared data, setup malware, probably wanting to hone this in the open ssf uh in some way.

H

That is, uh you know, uh available to security researchers, but not maybe completely publicly available, uh there's an upcoming plan to propose an implementation of how what that would look like and how that could be shared across multiple software repositories in a standard way, uh and also there's been a lot of discussion about dependency, confusion attacks specifically how they affect many other repositories.

H

um We are considering drafting uh sort of a best practice recommendation for how these passwords should best at dependence, combat dependency, confusion, attacks and that's it any questions from the tech. Anything like more clarity on.

H

Okay, thanks very much.

H

I'm not sure if Bob is returned from the room, maybe we can just hand it over to Luigi.

G

Yeah, can you guys hear me now: yep, okay, yeah Luigi go ahead and take us away. Yeah.

I

Sorry I was not able to find the mute icon on the top. uh Yes, um I would like to present uh I think the first version that I mean the first. The person we won. Can you listen to me?

I

Okay? Yes, the version we won for the uh security policy in um for uh open ssf project and content and resource and infrastructure. We have a shared document. The link is in the meeting notes and we are also an issue open in the um working group of vulnerability disclosure because I well weeks ago, we agreed that it was the probably the best group that we have to discuss this new policy.

I

um I think that Disney policies is quite important for us, because uh some repo have it some rapper, don't have it and probably have a sort of standard template for the entire Foundation could be a good idea.

I

um It's important to consider that open ssf is part of Linux Foundation or is strictly related to Linux foundation. So the idea is to not have document that are in Conflict both internally for open ssf, for example the inbound and the outbound security policy, but also with the Linux Foundation. There is a David that is following this: uh well, the discussion with the Linux Foundation, Council and um yeah I think it's ready.

I

uh The working group will not be the disclosure um as being keep posted by me in the channel and in the Ripple, and the idea is to have a sort of approval or first approval or and feedback by the TAC group to be sure that we are. We are aligned, especially um from all the sentences and the I mean idea concept and everything that can be really bought to legal and not just to the security or the procedure. Here is the issue.

I

If you want to see it, it's in the room, chat, uh I, don't know if you have had time to read the document. It is quite standard honestly and um well open a discussion or if you don't have a particular feedback or if you think it is a good version, see yes syrup.

C

To put things in context as part of our guidance, we recommend that all open source projects have a security policy documented that describes how they handle defects and reports. It's important for us to kind of uh drink, our own champagne, so to speak. So I I strongly agree with Luigi's proposal. We still probably need to over the words for like eight months, but the I joke, I I think it's actually pretty in a pretty good State, um but we we should talk about it.

C

I think it's a good thing for the tag to consider, and then we make that part of our standard operating procedures that every repo has this a way to report defects, and especially all software projects.

I

Yeah, in addition, it is also um it's part of the score card. I mean the scorecard check if we have a security, dot, MD and I think it's a good idea if we show that it's possible to have a security.md or a security process as a foundation. In addition, GitHub now have a very good way to report to handle cve and in general security issue, because every repo can collect their own security, rep um wrapper by researcher and handled by the maintainer.

I

So we don't need to have a sort of a unique point in contact or multiple email, because we can have just an email if someone want to contact us via email for a lot of reason. But if the pro, if the vulnerability or the security issue is in a project that we posted in GitHub, the reception can just just open a vulnerability report in the in the repo. This help has to keep my order and everything. I guess.

C

Praying it's a great way to lead by example, and encourage others to role model. Our Behavior yeah.

I

Initially I mean it is interesting. The um thank you Michael for the commenting.

I

The chat, yeah uh initially uh I started to work on this policy, because uh I wanted to try to spread at least a sort of the food in open, ssf uh specification, the security insights that should help uh scanner, a human to collect information about the security standard in place by a repo, not just if they ever not a secure.nd, but also what are the contact uh if they have a back Bounty um if they have a penetration test report that sometimes some especially important open source project have, but it's not easy to find them and um and I've seen that we don't have a security of MD.

I

So the idea is that we can spread the security and then we can create the security inside specification uh and spreading and Publishing all the repo. In this way, we can try to standardize how we can how we communicate with the community and with other people. What are our current standards?

I

um Yeah and yeah I? Think it's important. It's the first version. It can be improved. There is no pgp key, for example, at the moment, because we need to understand how we want to share secret in the foundation. That's not easy and uh other thing, and there is also the save Fable that is uh temporary removed because the Linux Foundation Council um suggests for now to not publish that kind of save fiber and um but yeah.

I

Oh yeah. Sorry.

E

Where's the conversation about the Safe Harbor happening.

I

uh In the comments in the document, but they are resolved, but please you can find in the history of the document. If you cannot it's a privileged issue and I can try to fix it and I have a summarized. Also. The debit comment in the GitHub issue do not lose this kind of information.

J

Yeah well I'm not sure how much how many details? Oh sorry, I, should raise my hand I see. Ava was ahead of me.

K

No worries thanks David, um just echoing Michael's comments from the written chat and my own feedback. This is fantastic I agree. I would suggest looking at how something like spdx short codes work such that there would be a machine readable in addition to the human readable form in a marketing of a good security.md.

K

Perhaps a machine, readable, concise format at the head of that file or somewhere else, to make this very easily aggregatable and automatable.

I

Yes, I mean uh is still a work in progress. There is a tunnel and if you want to join it, you are definitely welcome because uh at the moment Jonathan uh offered me a lot of good feedback and opinion and fact also- and it's definitely not easy- to write a specification.

I

I am learning this now and uh probably this is the easiest part, because then we need to convince the community to use it and um so having mark contacts and feedback on also all the specifications that maybe I don't know that are already popular or not popular enough, but people are working on them and we can try to um join in a single file or let's try to to join them all to understand if they are in conflict or not, for example, I know the spdx and another one that yeah, not just this spdx I joined them um I mean my first opinion about that specification.

I

It was that was too complex, but maybe I have just misunderstood. It so definitely open to review and change my mind honestly. It's very easy to change my opinion. If you have a good arguments, so no problem and MVP also to happen issue in the repo, because I'm trying to track in all the job in GitHub for a lot of reasons, especially because it's like we lose the conversation um so better if it is public on GitHub and yeah. But thank you.

F

David I think you're up.

J

Yeah, so real, quick um um first as far as uh you know, identifying who to report to uh the security insights uh spec is is really what not not spdx, um but uh as far as the Safe Harbor goes, we got some interesting feedback regarding the safe harbor. Don't want to go into all the details, but what was the original text was very U.S Centric. Obviously, vulnerability reporting can go around the world.

J

A second problem is that it is an unfortunate reality that some security researchers go Rogue, so they'll report but they're going to report and simultaneously either attack or help attackers. So saying we won't. You know, hey it's as long as you report, it's okay, that you simultaneously attack. People is not really what we're going for.

J

So um the suggestion that I I got back was basically just tell people, you know, obey the law and keep it simple and don't try to.

E

You can't do that because the law states, at least in the United States, that you're not allowed to find vulnerabilities in systems that you don't own. So the current state is that if we don't give explicit permission, they are breaking the law by auditing any Services we're running.

J

That well um I'm, not actually I, don't I understand, that's your position. I, don't think. That's the universal position.

E

K

It's it's cmaa, yep I'm, a strongly agreeing with Jonathan here. This is uh well understood in all the hacker communities that I know. uh Okay, that that is the policy and I can certainly uh offline cite plenty of Precedence. Where hackers have reports, sorry, where researchers have reported vulnerabilities in production systems and then been sued uh for having done so.

E

There's an entire document, that's held by disclosed IO that has a long long, history of all, of the different cases where security researchers have been legally prosecuted by organizations for engaging in in ethical research. So this is something that we need to carve out in this policy that this is allowed in behavior and that we will not be chasing them legally and that they are. This is allowed like this is allowed and we waive cfaa.

E

J

um I I I, obviously I'm I'm, absolutely in favor of making sure that they are legally safe. The feedback I'm getting from legal counsel, though, is that the original text that was proposed basically says uh in many ways: it's open season on our systems and feel free to take everything and take them down, and that's not the goal either.

J

So somehow we need to find it sounds like there really needs to be some sort of meaning in the minds of this, uh because uh there's a yo, I I think there's a way to handle this, but I think it's complicated. We won't solve it here, but I think we need to find a a forum to solve it.

C

J

Spin up a call.

C

About Safe Harbor in particular,.

D

I think that's easy.

C

Enough to do we have access to the experts, we can make that happen pretty quickly. Yes and.

K

Then talk, please make sure that when that call is uh getting scheduled, it is broadcast pretty widely. Please include the attack and the public policy committee.

E

Yeah I have a question for I know that the attack is not in a voting state, but is there? Are there any concerns with the idea of globally across all open source security, Foundation repositories enabling at an organization level, private vulnerability, reporting across all repositories, foreign.

K

Check on that is within the open, ssf no I'd want to have the TAC chat with all of the maintainers before committing them to that, but I would suspect. The answer here is no um I know a lot of other open source projects. Do that and support that I. Think the the challenging question for a safe harbor is stepping outside of Open Source projects and into commercial spaces. That's where it's trickier. Yes,.

E

Yes and any services that are getting hosted, like you know, best practice is bad or stuff like that. Bob you got your hand up.

G

Yeah I was just going to Echo what Eva just said. um Also a time check just a few more minutes on this, and we need to move on to other topics.

G

A

Sorry, I I think we actually um did enable GitHub private reporting on every project under ossf um and look I'm trying to find a repo that it is not enabled on which tells me that it's enabled on everyone. Okay, I I, haven't found one yet so um this may be moved. We could obviously revisit it and turn it off, because I think it was done at the org level.

E

um Did we do core infrastructure as well, which is another open, ssf org.

J

uh Best price uh CII: it already turns on the GitHub reporting uh for vulnerability, private vulnerability reports, all right.

I

Oh yes, we have enabled apparently.

G

All right any other questions for Luigi.

G

So I guess in terms of next steps here, Luigi you're still waiting on Council to get back with you on the final content and then once you do that we can think back to the tech to get a final ratified vote on this. Does that plan of record seem okay for you.

I

Yes, it's like an action item so um well. David is in contact with the Linux foundation on Council and I. Think that we can present the document if it is okay for them. If they mail contact is okay and we can just uh spread in the GitHub organization and, let's see uh syrup.

C

And so the working group will take the action item to get the Safe Harbor call set up, um we'll make sure we invite the tech and public policy committee I would strongly ask everyone on this call to review the issue, provide any feedback you have there and then we'll see how and if we can proceed with or without the Safe Harbor now and we'll, let you know kind of what the decisioning and where we land on that, because I think it's very important to provide that protection again to set that role.

C

Modeling again, that we uh welcome open openness and transparency and collaboration with all members of the community. So we'll get that back to everybody.

G

All right, thank you, crew. Thank you, Luigi. All right, thanks, Jonathan.

E

um So there is still the open source, security, Foundation, uh inbound, vulnerability or sorry. Now the outbound, my bad I'm. Looking at the wrong document, um uh this document has been passed through legal.

E

um uh We need to cat meow. um We need to um go through this document with uh the working group and and review the legal wording changes, um but I did want to remind the TAC that if you uh would like to review this document before voting, I'm hoping that we can do a vote next attack meeting on this document um as to whether or not we should adopt it or not or the tax should adopted or not.

E

um uh That would be greatly appreciated. So if you could take the time to read through this document, if you have not done so, that would be greatly appreciated and.

B

Jonathan would that be the Sig autofix meeting where this is the next chance to discuss this before coming back to the tech? No.

E

No, this is not this. This is the vulnerability disclosure working group. This is the open source security, Foundation vulnerability, disclosure policy. This is our outgoing reporting, mostly associated with how alpha omega will be reporting security, vulnerabilities, there's a tie-in which is the link. There is a link to a proposed policy, which is the automated vulnerability fix campaign, but that will not be finished and complete and going out and shipping with this policy, it is currently a raft that is being bounced around that a snake for.

B

The sake of others who want to discuss the outbound policy, though the next good chance would be tomorrow morning's 8, A.M, Pacific uh vulnerability. Disclosures meeting then.

E

Yes, the yes, the yes 11.

B

E

Eastern Pacific, whatever you said, yes, okay,.

B

And did we skip over the Quick Loan disclosures update.

E

We've not done the vulner disclosure update. This is yes, that is that so yeah. That has not happened yet.

B

Or maybe this is a good time to for probe to to step in and do that.

C

D

C

Ready I was born ready.

C

Can everybody see my screen yep great, so we're here today to talk about the vulnerability, disclosures working group and our status um new things we're here to talk about you'll, hear about today in the following briefing we adopted openvex Sig and we are now actually participating within the larger sisa Vex working group.

C

uh You just heard Jonathan talk about the autofix Sig and the disclosure policy for auto fixing and then also the associated uh extra outbound vulnerability reporting. uh We just heard about the security MD for all open source sound for foundation projects proposal.

C

uh We also are trying to solicit participation in a cvd guide for open source consumers, and uh we have a presentation scheduled at openssa, North America, simplifying vulnerability, coordinating vulnerabilities and disclosures at open source projects. Madison Oliver and I will be doing that as part of the ossna and we are will have a Blog coming out very soon imminently. That's actually on your desks for comment uh getting to know the open source, vulnerability uh format.

C

As a reminder, the vulnerable disclosures working group has about 16 active members and 15 to 20 kind of people that float in and out from time to time, we are focused on trying to improve uh secure overall security of Open Source software, the ecosystem by helping mature and Advocate well-managed vulnerability, reporting and communication things like security MDS. uh This is uh all of our member projects and sigs and we'll talk briefly about each one. In the coming slides, CBD guides, we produce guidance.

C

We currently have a document focused on open source projects and maintainers on how they can conduct themselves via widely accepted industry, coordinated vulnerability, disclosure practices. We have a reverse of that guide, focused at security, researchers or finders, helping them understand how best to interact with open source and how they might find ways to best collaborate with developers. And again we have that CBD guide for consumers coming and ideally, we can find some wonderful developers someday that will help us provide some tooling and scripts that will automate some of those practices to help maintainers.

C

Do things frictionlessly.

C

The osv we've just reinvigorated our relationship with those folks live in Sydney Australia. So uh are not up right now to talk at the attack, so we had to move a meeting to accommodate them, but osv is a standard with which producing and consuming vulnerability information. The open source way provides both human and machine, readable data.

C

They um if you get a security advisory from GitHub. It's also in the osv format. Fun fact: we're looking to engage with the cve board to talk about some challenges with the data quality of some open source projects there and continue our partnership and collaboration with them as they roll out their new Json format.

C

uh We also are looking to meet with Linux distros to see if we can get more Linux distributions using OSB as part of their vulnerability disclosure processes and there's an amazing opportunity to collaborate with that new open, Vex Sig and what we'd like from the TAC is hey.

C

If you can help us find ways to encourage more people to leverage osv, it's a fun project, 100 open source and we think, there's a lot of value in having sharing more information about vulnerabilities than less.

C

uh The open source security incident Response Team Sig. This is a spin-off of the mobilization plan, and this is the tldr on this is to proposals to create a team of Upstream, open source security incident handlers and to work with maintainers and researchers and consumers of Open Source to help get things fixed more quickly. We currently have a funding proposal that is under review by the governance committee. The plan is always open for comment and feedback. We would love to hear additional thoughts on how this idea could be implemented. So uh patch is welcome.

C

Take a look at the issue and provide us any feedback. You have and again we're looking specifically for uh feedback from the governing board on. If this is something that's viable, that they're interested in funding and supporting or not and there's a couple if the plan is approved, we have two software projects in there.

C

One is the siren service, which is a vulnerability communication, advertising service being able to try to find ways to get all of the different methods of advertising, fixes uh more penetrated throughout the industry and then there's a tool that cert CC created, called Vince and unfortunately, its current implementation is not super open source friendly. The code is open sourced, but the implementation is super tied to AWS. So we're looking at potentially trying to find ways to make that more portable being able to anyone could use that software in any environment they wanted.

C

So we're looking to retool some of that and provide that back Upstream to the Vince crew I mentioned openvex openvex is a simple implementation of the Vex vulnerability exploitability exchange standard. This is a project that is donated and I'm waiting on my dear friend Dan Lawrence. To give me an update from legal on how that IP, review and transfer is coming, but this sig is focused on supporting the openvex spec. There is some tooling associated with it, and then one of our biggest goals is to further the industry collaboration.

C

There are many members that participate with sisa's, s-bomb and Vex efforts, we're looking to expand that potentially working with Oasis with the csaf standard working on security, working with security scanners, things like spdx and Cyclone DX, and anyone that's interested in sharing information about Vex, which is just a way to State your Effectiveness to a vulnerability. We think there's a lot of value in that and right now, we're not looking for any feedback from the tech, but patches and comments are always welcome.

F

um I haven't heard anything about the IP or legal review, so I just ping, my colon to see if I'm missing anything there, but thank.

C

F

For the thanks for poking me,.

C

You're welcome we missed you. Yesterday we had a great call. Everyone should check out the video um autofix Sig, which is uh heading up headed up by Jonathan, is a way for security. Researchers to more quickly share vulnerability reports at scale, and the goal is not to honk off all the open source, maintainers we're trying to find best ways and tools and methods that they can.

C

Leverage he's currently got his specification for the vulnerability, Fix Auto fix campaigns, and also that disclosure vulnerability disclosure policy which isn't directly related, it's related, but it's not directly for the autofix. So again, as Jonathan mentioned and Luigi mentioned, please review both Luigi's policy and also Jonathan's Auto fix proposal. That would be super groovy.

C

And that is that, for the volume disclosures group is, uh do we have any questions? Is there any more information about anything I've covered today that you're looking for, and was this update in the format you wanted? Is there other ways we could share this information that you're curious to.

D

C

G

If you have one question in the chat group, great.

C

I heard you mentioned discussing OSB with the cve board. I briefly got disconnected what outcome I'm, not looking for the TAC to do anything. I know: uh half of the cve board members, so I'm just waiting to try to find a love connection between Sydney and Washington DC so that we can talk. They have some questions about data quality and looking to find ways to improve that interoperability and kind of ease the ability for Upstream maintainers to be able to report vulnerabilities and get the cve identifier. So right now, there's nothing.

C

We need from the attack, that's just kind of a statement of what the the group will be looking to do and.

D

If anyone's interested in participating.

C

We would love the help.

C

Did I answer your question amen.

K

Yes, thank you very much. You.

C

K

C

Any other questions or comments.

G

Just a quick comment: I I still think this. This format is uh very useful, so I would say plus one to keeping it up excellent.

C

And I will post it into the meeting notes here within seconds from now, so you could all look at it in your spare time, which I know you'll do you'll read it before you go to sleep every night.

A

Thank you crop.

G

G

So looking at the agenda, the only other thing that we had listed today was more of an FYI and a reminder uh to both attack directly, as well as the broader audience. um Francis and David wheeler and several others have been working on a I guess.

G

Skeleton document is the phrase that comes to mind, but certainly it's it's got more uh more on it than just a few bullet points around helping to flush out the the meaning behind the phrase Sterling tool chain, and so this is uh something that I would certainly ask the current attack the incoming tack, as well as the folks that are representing the broader Community to please go in and take a look.

G

I think you know, there's a you know a lot of discussion around what this could be and should be, and I think ultimately, what's most important is that the community really.

C

G

Engage in a meaningful way to help really refine the concept and, as we think about turning that concept into a set of action plans, um it's going to be very important that we, uh we obviously have a collaboration, that's kind of a key ingredient to all of this, so um not going to walk through the document in detail on this call, but uh just another reminder to please take a look at that.

G

Add questions add comments uh in there and we will continue to refine that once the incoming attack is finally seated I think we will have a further discussion around how to turn this document into more of an action plan. So I guess more to come on that front, but uh just wanted to call everyone's attention to that.

G

Any questions on that.

G

All right uh any other topics, folks on the call want to race. Today, we've hit the entirety of today's agenda.

K

Just a quick reminder that next week is RSA and if folks are in town, be lovely to meet up in the hallways or Global city everywhere.

G

Awesome well safe travels to all that are traveling for that um and I don't see any other topics or hands raised. So with that we'll go ahead and close. Today's call thanks. Everybody.

C

Have a great day.

C