Skip to content

Node.js Security Initiatives 2024 #1255

Closed

Description

@RafaelGSS

Hey!

Since May 2023 the Security team has been working on the following initiatives:

  • Permission Model (2 Phase) - (Done)
  • Automate update dependencies (Done)
  • Assessment against best practices (Done)
  • Automate Security release process (In progress)

As always, I want to express my gratitude to everyone who contributed to our latest project. The work was exceptional. During today's meeting (#1245), we discussed the need to explore new initiatives to enhance the Node.js security ecosystem. Therefore, I would like to use this issue as a forum for brainstorming and sharing ideas. Please feel free to share any problems you've encountered and any potential solutions you may have. Even if you don't have a solution in mind, please share the problem anyway. All input is welcome. This thread will be reviewed and discussed through the Node.js Security team meetings (feel free to join).

@nodejs/security-wg

Activity

  1. pinned this issue on Mar 14, 2024
  2. marco-ippolito commented on Mar 14, 2024

    @marco-ippolito
    Member

    I think SBOM should be an initiative for this year

    Ref: #1115

  3. mhdawson commented on Mar 14, 2024

    @mhdawson
    Member

    I think we should make the work to audit the build processes of the dependencies an initiative for 2024. It both aligns well with the emphasis on supply chain security and should also help the project to limit the risk of issues during security release.

    Ref: #1037 #1236

  4. mhdawson commented on Mar 28, 2024

    @mhdawson
    Member

    Proposal from discussion in the meeting today for 2024

    • Permission Model (2 Phase)
    • Assessment against best practices
    • Automate Security release process
    • Including SBOMs with Node.js
    • Audit and improving the build processes of Node.js dependencies
  5. UlisesGascon commented on Apr 13, 2024

    @UlisesGascon
    Member

    Given the recent discussions around the xz incident, I suggest including a new initiative dedicated to mitigating potential threats originating from similar vectors within the organization.

    As an outcome of this initiative, I propose to:

    • Evaluate the current situation of the project regarding this scenario.
    • Prepare a list of potential changes to increase our resilience against this kind of threat.
    • Share our learnings openly so that other projects within the OpenJS Foundation and outside can benefit from them.

    ref: #1282

  6. RafaelGSS commented on Apr 17, 2024

    @RafaelGSS
    Author
  7. RafaelGSS commented on Apr 24, 2024

    @RafaelGSS
    Author
  8. RafaelGSS commented on Apr 25, 2024

    @RafaelGSS
    MemberAuthor

    Code Integrity feature for Node.js.

    @rdw-msft can you provide more details on this?

  9. RafaelGSS commented on Apr 25, 2024

    @RafaelGSS
    MemberAuthor

    Include a "Defense in Depths" policy to Node.js Threat Model.

    @mhdawson @rdw-msft can you include some context here? (Feel free to edit this comment)


    Here's the document we use to differentiate between "defense in depth" and "security boundary" features: https://www.microsoft.com/en-us/msrc/windows-security-servicing-criteria

  10. RafaelGSS commented on Apr 25, 2024

    @RafaelGSS
    Author
  11. GeoffreyBooth commented on Apr 29, 2024

    @GeoffreyBooth
    Member

    Code Integrity feature for Node.js.

    Regarding this, there’s a WIP PR for import maps: nodejs/node#49443. Import maps could be used as a place to store the subresource integrity hashes for modules: https://github.com/guybedford/import-maps-extensions#integrity. This would require some coordination with standards bodies such as WICG and WinterCG. cc @guybedford

  12. RafaelGSS commented on Apr 29, 2024

    @RafaelGSS
    MemberAuthor

    Permission Model adoption on Package Managers: #1300

  13. rdw-msft commented on May 1, 2024

    @rdw-msft

    Include a "Defense in Depths" policy to Node.js Threat Model.

    @mhdawson @rdw-msft can you include some context here? (Feel free to edit this comment)

    Here's the document we use to differentiate between "defense in depth" and "security boundary" features: https://www.microsoft.com/en-us/msrc/windows-security-servicing-criteria

  14. RafaelGSS commented on May 9, 2024

    @RafaelGSS
    MemberAuthor

    Improve CII Best Practices and reach silver badge.

  15. RafaelGSS commented on May 9, 2024

    @RafaelGSS
    MemberAuthor

    Defining scopes of the Security team

  16. RafaelGSS commented on May 23, 2024

    @RafaelGSS
    MemberAuthor

    Selected Initiatives for 2024:

      1. Automate Security release process - Champion: @RafaelGSS / @marco-ippolito
      1. Node.js maintainers: Threat Model - Champion: @nodejs/security-wg
      1. Audit build process for dependencies - Champion: @mhdawson

    Please note we have skipped item 3 (SBOM) as we don't have a volunteer for that. If you are interested in moving forward with this initiative, join us.

    Refs: #1319

  17. unpinned this issue on Sep 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions