Collaborators Inactivity Policy Review about security-wg HOT 3 OPEN

In terms of the suggested expantions, the intention was to look at it from a top level model (separate from our existing threat model) which would include all ways that supply chain security might be compromised and what we have in place already to address those concernts.. I think this would include all of the different roles we have in terms of access as well as people with no access at all. The top level view should help us understand the relative risks and were it might be best to focus our energy. One way to start might be to build the list of

• classes instractructure that are used in the project (test machines, jenkins machnines, release machines etc.)
• what having access to those classes of infrastructure would let people do
• Different roles that give people different levels of access to those components
• The projections/approaches we already have in place to mitigate risks

EDIT: which in part I meant to say all those suggestions are good ideas to include in the scope.

from security-wg.

Yep, this is great! We can also extend the threat model a bit to explain how the roles in the organization can impact the final users in case of bad actors or human errors. It would be beneficial to document in simple terms all the measures we have in place to prevent this (as referenced here) and how the organization promotes individuals to those roles, etc.

I believe that from an external point of view, this might be an interesting topic to cover, especially when adopting Node.js, particularly in commercial companies.

from security-wg.

I would like to expand this discussion to a more sensitive role of Node.js organization: Releasers.

• Is there a security concern about keeping inactive releaser keys in our machines?
• Is the process of signing releases from a collaborator easily exploited?
• Should we be more restrictive to the inactive limit for releasers? And what about security-triagge group?

cc/ @nodejs/releasers

from security-wg.