Formation of a Security Working Group

[UlisesGascon]

In #161 we discussed about how to address security in the organization. Aside of the TC managing the Security vulnerabilities, the idea of creating a dedicated Working Group may solve many challenges that we are facing, here is my proposal:

Mandate

The Security Working Group's purpose is to achieve the highest level of security for Express.js and modules from jshttp and pillarjs.

Main Objective
The Security WG is responsible for managing incoming security reports, and responsible also to prepare patches or releases. The nature of this task is sensitive, so only the Security triage team, Repo Captains and TC members will be envolved on it.

Additional responsibilities

• Define the Security triage role
• Define and maintain security policies and procedures for the project and the packages in scope
• Elaborate guidelines and recommendations for the ecosystem on how to build more secure middleware
• Review and recommend processes for handling of security reports (but not the actual handling of security reports, which are reviewed directly by the TC).
• Promote improvement of security practices within the Express.js ecosystem (For example: OSSF Scorecard, threat model, etc..)
• Recommend security improvements for the project and the packages in scope
• Support the TC team on security triage when is requested
• Support initiatives from the OpenJS Foundation Security Collab Space.

Out of Scope

The Security WG is not responsible for managing incoming security reports, nor is responsible also to prepare patches or releases

Backlog (keep on the radar)

Items that can be part of the initial activities from the group:

• CSRF (and csurf) in 2024 express#5491
• See EFI: Security #171
• Implementing OSSF Scorecard security-wg#2

Next steps

Once we are clear on the responsibilities and scope, I will create a repository expressjs/security-wg and prepare a PR to properly summarise and kick off the initiative.

It is also expect for us to have regular meetings and a fluent offline communication channel in the slack.

Additional Notes

The WG will work in openness and trying to be as much transparent as possible, anyone will be able to join to the meetings and to the offline discussions. I am basically following the steps of the Node.js Security WG, as it is a model with a great success over the years and I am familiar with it, so I expect the governance to be almost identical 🙂

The vulnerabilities related activities (management, triage, patching...) remind in private, we won't disclosure any vulnerability until the patch is available to the public.

[wesleytodd]

I was thinking that maybe we need some formal structure around these key initiatives? Like node has working groups and teams, the foundation has collab spaces. I think we could just have a running list of technical priorities, which are assigned responsibilities like you list above. Does it make sense to put that in the governance? Or are we alright just starting it and seeing how it goes?

[UlisesGascon]

I think we could just have a running list of technical priorities, which are assigned responsibilities like you list above.

I agree, I think the list will be long, but I am sure security will be part of the list so we can wait to build the list or update the list once other priorities are defined and then add the security part into it.

Does it make sense to put that in the governance? Or are we alright just starting it and seeing how it goes?

I think that we can run this WG as an experiment / prototype and update the governance as we have more solid feedback on the experience.

[wesleytodd]

I think the list will be long

Yes it will lol, but hopefully as we make progress we can get it manageable as we catch up.

I think that we can run this WG as an experiment

Cool I agree with this.

The Security WG is not responsible for managing incoming security reports, nor is responsible also to prepare patches or releases

I assume you are including this for a reason. Can you help me understand the reasoning more clearly?

[wesleytodd]

Also just want to post this here so we don't forget about it: expressjs/express#5491

[UlisesGascon]

I assume you are including this for a reason. Can you help me understand the reasoning more clearly?

Oh! I assumed that the TC won't delegate this (or at least will require a longer discussion), but we can delegate it.
We need to take in account that the security patching and triage should be "private" at least until we have a patch in place,
just to avoid that the vulnerabilities can be exploited in the wild before there is a proper patch in place.

If we want to delegate this to the WG, we might want to create a security triage role and we nominate people that have the trust from the project and the willing to help on this (similar to captains). I am not against the idea at all, just I thought that it will easier to start without delegating responsibilities, but makes totally sense to do it (IMO).

We can ask for advice from @ruddermann @ljharb on how to operationally manage this delegation 😏

[wesleytodd]

Good, I thought that might just be the way to keep it private. I think ideally we would delegate the triage to the security wg and the project captains. I don't think there will be a situation where the TC members are not either also on the security wg and/or operating as the captain. So unless we end up in a situation where the TC members are somehow unaware of a security issue I think it is alright to delegate.

I agree if we do that we need to make a role that is separate from folks who just join the WG to participate or observe and that any input/advice is very welcome!

[UlisesGascon]

Thanks for all the feedback @wesleytodd, I updated the initial comment to include the changes 🙂

[ruddermann]

Thanks is great and sorry for missing the meeting! Your timing is great, because I was finally re-organizing myself this weekend. This WG will be a great way for me and OpenJS to pilot and test out DE STF work I need to do anyway.

Where do you all want to focus first? I'll let you know how/if I can help! You can check out this Board of Epics that I'm wrapping up putting together now to get a sense of what I'll be doing:

[wesleytodd]

Where do you all want to focus first?

I think the first thing needs to be us deciding if we can handle doing the security audit. That was time sensitive I think, but I think from the call folks seemed generally alright with it. @UlisesGascon I don't remember if you voiced a specific opinion, but if we do think it is a good idea then I think ideally we would get started on that right? Obviously we would need to ensure the rest of the @expressjs/express-tc folks are alright since this likely would be a pretty broadly impactful effort.

[bensternthal]

A few notes from OSTIF on what to expect with regards to an audit:

Overall we try our best to carry out the security audit with minimal disruption to the project's day to day, and usually require no more than ~10 hours (approx. 1-2 hours onboarding/discussion, 1-2 hours for follow up questions, 1-2 hours for calibration and closing out) of total time from the project side. A little guidance and help at the beginning is extremely
helpful, so we can have the audit team focus on the right things that will provide the most benefit to you long-term.

The first step to move forward would be scheduling a kick off meeting with OSTIF (I can help with this). I would suggest getting a meeting on the calendar in the next week or so. This meeting will be a great introduction between the teams and provide a forum for asking questions and discussing a reasonable timeline.

While we have extended our audit deadline to Q2, it's important to remember that, although the deadline isn't pressing, our time is not unlimited and it will go fast.

[wesleytodd]

Would folks have time next week to get together? I would be down, and @bensternthal can help us get it on the calendar. I would prefer if we can find a time that is not so late for @UlisesGascon like the last one, which is likely to be our biggest problem scheduling VC meetings based on the availability folks posted in the TC meeting. Maybe we just need to get good at recording and posting better minutes.

[UlisesGascon]

This WG will be a great way for me and OpenJS to pilot and test out DE STF work I need to do anyway.

Thanks for the context @ruddermann! I believe that CVD and CVE will be a great game changer for us based on our current situation. Also we can work on implementing best practices too. So there two big epics can be the baseline work for this WG.

[UlisesGascon]

@UlisesGascon I don't remember if you voiced a specific opinion, but if we do think it is a good idea then I think ideally we would get started on that right? [...] Maybe we just need to get good at recording and posting better minutes.

I had only question regarding the scope, are we planning to audit other things like body-parser, cookie... or just express?

I think the most important meeting is the kick off as we will need to provide a lot of context for the auditors regarding the project. So I guess that the more knowledgeable people from the project should be part of that meeting. The following meetings (I assume) will be more related to make changes in the project, so this part is more open to a different composition.

Agree that a recording can be a great resource, as we can collect some feedback offline if needed. When we did the onboarding of the LF IT team in Node.js Infra we did some meetings discussing about infra details, and quite frequently we did offline research and consolidation. The important here is to have someone able to coordinate the responses and to move forward the wheel (like a PM), so the auditors are not blocked waiting and waiting or pinging many people to get responses from

While I am not the most knowledgeable person on the project historical context, I can help to coordinate responses and push if needed.

Side note: I will on holidays the second half of March, so my envolved will be limited on that period

[dougwilson]

I have a question: what exactly is the audit? I hear audit and whay comes to my mind ia looking things over, but you say it is to make changes too, so it sounds like more than what I think of for an audit of something. And much of the express code is not within the express repo, so when I was thinking of it, I was assuming it was gonna at least be across all the repos in the three github orgs, as they are what make up Express as the code base (and as far as you can go without stepping outside of the Express project). But maybe it doesn't make sense to do that, idk, as I hage no idea what the audit even is :)

[wesleytodd]

what exactly is the audit?

Basically yeah, going over things and working with us on proactive security issues which they find.

I had only question regarding the scope

I think it would be express and direct dependents. We would likely want to scope it to that as the most impactful part.

I was assuming it was gonna at least be across all the repos in the three github orgs

I think this is wider scope than we need or want. There are old repos, lower usage repos, and a bunch of other things likely not worth spending time on.

[dougwilson]

Ah, gotcha. I think express-session should probably be included even though it is not a dependency of express, as it seems to me a sec audit there would be very useful.

[dougwilson]

And multer, which is another very heavily used one with large security surface area.

[wesleytodd]

@bensternthal Can we setup that meeting for sometime this week?

[sheplu]

I will try to join the meeting if this is this week or next week :)

[wesleytodd]

We started a DM, we are looking at 7am PT on Thursday if that works for you. I think that's 4pm for you?

[UlisesGascon]

I think that's 4pm for you?

Yep, 4pm

[ctcpip]

is there an invite for the meeting or does it appear on any public calendar?

[wesleytodd]

It is not on the public calendar, just a small kick off to better understand the scope of the audit and expectations. If you are available and want to attend you can for sure though as far as I am concerned. Feel free to DM in the openjs slacks and when we hear back I can ping you.

[UlisesGascon]

After few days of discussions seems clear that: We agree on the need to have a working group (primary goal of this issue) and that we have many things to start to work on (public and private), also there are some folks interested in actively participate in the initiative.

So, I will create a new repository in the expressjs org for this WG and then:

1. I will create an initial PR to consolidate my initial comment
2. I will Open some issues with the topics that have being started on this thread.

If there are no objections I will do that on Monday 🙌

[wesleytodd]

A few threat model example links shared from the meeting that I didn't want to loose:

nodejs/node#45223
https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/threat_model
https://github.com/kubeedge/community/blob/master/sig-security/sig-security-audit/KubeEdge-threat-model-and-security-protection-analysis.md

[UlisesGascon]

I will close this issue now, as we have a dedicated repo for the WG 🎉

Follow up discussions in:

• Express.js Security WG Initiatives 2024 security-wg#1
• docs: add contributing guide security-wg#4
• docs: add working group details security-wg#5
• OSTIF Audit for Express security-wg#6
• Express.js Threat Model security-wg#3
• Implementing OSSF Scorecard security-wg#2