openjs-foundation / pkg-vuln-collab-space Goto Github PK

We need to pick a time for a recurring meeting. As we will be announcing the Collab Space officially around the OpenJS World Event, we should shoot for the first one being the week right after. The consensus from the folks on the kick off call was Tuesday morning is the best time. That means the first meeting would be Tuesday June 8th. To make sure we most effectively use our time I propose we start with a monthly cadence to the meetings.

First Meeting (All times PST, more timezones in the links):

Monday June 7th

👎 8:00 am
🚀 9:00 am
😕 10:00 am

Tuesday June 8th (All times PST, more timezones in the links)

👀 8:00 am
🎉 9:00 am
❤️ 10:00 am

Vote for as many times as you can attend. Additionally, once we get a feel for the regular attendance we can re-evaluate and do alternating times if necessary.

In README.md, in last section, there is a link to join the Slack channel and it does not work.

https://github.com/openjs-foundation/pkg-vuln-collab-space/blob/main/README.md#links--resources

✌️

Hey Everyone!

Big thanks to @rginn for scheduling the meeting time! Here is the agenda:

1. Introductions
2. Discuss meeting time
3. Establish scope
4. Brainstorm Ideas
5. Take Aways & Next Steps

Zoom link: https://zoom.us/j/6263062106
Notes: https://hackmd.io/@nottherealwes/H1BPiHJCO/edit

cc @naugtur @boneskull @mhdawson @dominykas @ljharb @MarcinHoppe @rginn @darcyclarke @lirantal @JamieSlome

• @darcyclarke @wesleytodd to set up & coordinate the meeting cadence (first call)
• determine reporting mechanism/style (ex. monthly status report at CPC meetings)
• kick-off new project board to track items in flight
• determine first set of todos/questions to answer in call

https://security.googleblog.com/2021/06/announcing-unified-vulnerability-schema.html

This new vulnerability schema aims to address some key problems with managing vulnerabilities in open source. We found that there was no existing standard format which:

• Enforces version specification that precisely matches naming and versioning schemes used in actual open source package ecosystems. For instance, matching a vulnerability such as a CVE to a package name and set of versions in a package manager is difficult to do in an automated way using existing mechanisms such as CPEs.
• Can be used to describe vulnerabilities in any open source ecosystem, while not requiring ecosystem-dependent logic to process them.
• Is easy to use by both automated systems and humans.

This is the gist of it:

{
        "id": string,
        "modified": string,
        "published": string,
        "withdrawn": string,
        "aliases": [ string ],
        "related": [ string ],
        "package": {
                "ecosystem": string,
                "name": string,
                "purl": string,
        },
        "summary": string,
        "details": string,
        "affects": [ {
                "ranges": [ {
                        "type": string,
                        "repo": string,
                        "introduced": string,
                        "fixed": string
                } ],
                "versions": [ string ]
        } ],
        "references": [ {
                "type": string,
                "url": string
        } ],
        "ecosystem_specific": { see spec },
        "database_specific": { see spec },
}

Here is the spec doc: https://docs.google.com/document/d/1sylBGNooKtf220RHQn1I8pZRmqXZQADDQ_TOABrKTpA/edit

@bnb created an npm RFC PR after a recent RFC meeting. With their permission, I am sharing that issue here.

npm/rfcs#422

To get the collab space kicked off, we are going to be running a session at OpenJS World 2021. To get this planned, we would like to do a session sometime early next week. Our proposed agenda (open for discussion to make sure we cover the most important things):

1. Introductions
2. Quick recap of the scope/proposal
3. Outline plan for the session
4. Assign action items and schedule next meeting

To make sure the most folks who want to participate can attend we thought we would open up a short vote. All times are PST.

Monday May 10th

• 👍 7:00 am
• 👎 11:00 am
• 😄 12:00 pm
• 🚀 1:00 pm

Tuesday May 10th

• 👀 7:00 am
• 🎉 8:00 am
• 😕 12:00 pm
• ❤️ 1:00 pm

Vote for as many as you can attend and we will choose the best time (with the added restriction that both @darcyclarke and I can attend as the champions). We will leave this open until Friday, so get your votes in if you would like to attend.

cc @pkg-vuln-collab-space (looks like this doesn't work yet?)
@naugtur @boneskull @mhdawson @dominykas @ljharb @MarcinHoppe @rginn

One constant in this discussion has been how we align incentives across the process. Today we only seem to align on one goal: "improving security". But at what cost? Today different parts of the ecosystem make decisions without considering the impact those decisions have on other parts. I would like to provide a forum here for folks to discuss what their incentives structures are, so we can better understand where they overlap and where the diverge.

Maybe we can start here with brainstorming with some user story style perspectives, but I would like to make a doc in the repo about this at some point. I will start with my incentives:

1. As a maintainer of OSS projects, I want to help my users be the most secure they can. This means responding to security issues quickly and efficiently.
2. As a maintainer of OSS projects, I do not want false positives clogging up my inbox and brain.
3. As an employee at a technology company, I want security issues surfaced so I can assess them. I want them to come with enough context that I can understand the issue and address it in my companies products.
4. As a member of a team dedicated to developer productivity, I want solutions which reduce the burden on the developers I support and improves their ability to assess and remediate security issues.
5. As a human person who donates my free time, I want to have hobbies that are not merging dependabot PRs and talking with security professionals about the applicability of a CVE on my projects.