You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Refs: nodejs/node#52459
I believe it would be great to add this discussion to the agenda.
We can have a look at the current policy for inactivity and elaborate an opinion.
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.
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.
Activity
UlisesGascon commentedon Apr 18, 2024
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.
RafaelGSS commentedon Apr 18, 2024
I would like to expand this discussion to a more sensitive role of Node.js organization: Releasers.
cc/ @nodejs/releasers
mhdawson commentedon Apr 18, 2024
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
EDIT: which in part I meant to say all those suggestions are good ideas to include in the scope.
github-actions commentedon Jul 25, 2024
This issue has been inactive for 90 days. It will be closed in 14 days unless there is further activity or the stale label is taken off.
github-actions commentedon Oct 24, 2024
This issue has been inactive for 90 days. It will be closed in 14 days unless there is further activity or the stale label is taken off.
github-actions commentedon Jan 25, 2025
This issue has been inactive for 90 days. It will be closed in 14 days unless there is further activity or the stale label is taken off.
github-actions commentedon Apr 26, 2025
This issue has been inactive for 90 days. It will be closed in 14 days unless there is further activity or the stale label is taken off.
marco-ippolito commentedon Jun 9, 2025
nodejs/node#52459 has been closed, we can close this too