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
{{ message }}
Repository navigation
Adding a vulnerability scanner as part of the dependency updates #59911
I think we should add a vulnerability scanner in the dependency updates flow.
PRs such as #57769, should be scanned for vulnerabilities before going through - I would also not installing things if they would pull vulnerable dependencies (not sure how easy that would be).
Not sure how well existing tools cover this but we also need to make sure there isn't a TOCTOU problem. e.g. if the bot opens a PR to update to a vulnerable dependency and a few hours later people discovered that there's malicious code in the updated version, there should be some updates in the PR to remind the reviewers.
Also it would be safer to keep the dependency update PRs open for a while, e.g. so that there's a >7 day period since the publish date of the newest updated dependency.
@RafaelGSS do you think this is an activity that can be part of the AlphaOmega grant?
Sure. I'm just a bit more restricted in time than I was before, but I can take a look on this.
I think the --before (or cooldown option) would prevent us to fall in those recent supply chain attacks, but we'll need to monitor closely in case of security fixes to dependencies as they will get delayed to be merged on main.
can be integrated via the SCM integration which then creates PR checks for security (SCM and SAST) so yes dependencies are part of it
not sure if it's widely known but Snyk automates dependency updates as well through PRs like dependabot etc and has a built-in mechanism we added back in 2019 or so with a delay (what has been pointed above as "cooldown"), from the docs:
Snyk does not recommend upgrades to versions that are less than 21 days old. This is to avoid versions that introduce functional bugs and are subsequently unpublished or versions that are released from a compromised account, an account for which the account owner has lost control to someone with malicious intent.
RE TOCTOU malware - I'm checking with the product about Snyk's approach to this
It would be cool to enrich package dependency results from Snyk Advisor (whether directly through Snyk in some way, or through some kind of integration, for example, I created a while back the Dependency Advisor GitHub Action)
Also I've been trying to raise awareness to npq as an npm wrapper that runs on the dev's machine and proactively runs heuristics and checks prior to installing packages (would've caught many past security incidents and avoid devs falling for them).
Happy to learn if any of the above or other measures would be useful.
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 240 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.
Activity
mcollina commentedon Sep 17, 2025
cc @nodejs/security-wg @lirantal @feross
joyeecheung commentedon Sep 17, 2025
Not sure how well existing tools cover this but we also need to make sure there isn't a TOCTOU problem. e.g. if the bot opens a PR to update to a vulnerable dependency and a few hours later people discovered that there's malicious code in the updated version, there should be some updates in the PR to remind the reviewers.
Also it would be safer to keep the dependency update PRs open for a while, e.g. so that there's a >7 day period since the publish date of the newest updated dependency.
richardlau commentedon Sep 17, 2025
If we want to wait on updates we could pass
--beforetonpm installin the update scripts.BridgeAR commentedon Sep 17, 2025
I think that is a good idea. We should have a couple of days before we pull in updates. I think three days would make sense.
aduh95 commentedon Sep 17, 2025
Dependabot has a
cooldownoption that we could use if we’re not alreadymcollina commentedon Sep 17, 2025
@RafaelGSS do you think this is an activity that can be part of the AlphaOmega grant?
RafaelGSS commentedon Sep 17, 2025
Sure. I'm just a bit more restricted in time than I was before, but I can take a look on this.
I think the --before (or cooldown option) would prevent us to fall in those recent supply chain attacks, but we'll need to monitor closely in case of security fixes to dependencies as they will get delayed to be merged on main.
tools: use dependabot cooldown and move tools/doc
lirantal commentedon Sep 24, 2025
I can speak for the Snyk capabilities:
Also I've been trying to raise awareness to npq as an npm wrapper that runs on the dev's machine and proactively runs heuristics and checks prior to installing packages (would've caught many past security incidents and avoid devs falling for them).
Happy to learn if any of the above or other measures would be useful.
RafaelGSS commentedon Sep 24, 2025
I'd love to hear more about that. Is it possible for you to join any of our security-wg meetings? @lirantal
tools: use dependabot cooldown and move tools/doc
tools: use dependabot cooldown and move tools/doc
tools: use dependabot cooldown and move tools/doc
github-actions commentedon Apr 23, 2026
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
github-actions commentedon May 23, 2026
This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 240 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.