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.