Security is an area I have been thinking about for some time. A recent security-related PR brought the topic back to my attention, and I have also noticed more people in the community raising similar concerns.
I believe this is a good moment to discuss how we can improve security across Meteor and include concrete initiatives in our next roadmap. I would like to hear some ideas about what we can do, process, tools, and etc.
An initial audit
As a small baseline, I created a full application with Meteor 3.5.1 and ran npm audit.
The result was:
- 8 moderate vulnerabilities
- 0 high vulnerabilities
- 0 critical vulnerabilities
Seven findings came from development tooling, mainly through the Rspack and webpack-dev-server dependency chain.
Running the audit without development dependencies left one moderate finding related to qs, included through url inside meteor-node-stubs. Wich already is solved in this PR
A few proposes
GitHub Security Advisory and CVEs
Meteor already has a security email address and a SECURITY.md. We could build on them with a clearer GitHub Security Advisory process:
- A user, researcher, or contributor privately reports a possible vulnerability.
- A maintainer validates the report and creates a private draft advisory.
- The reporter and necessary contributors can collaborate privately.
- The team identifies the affected versions, severity, mitigation, fix, and required backports.
- If no CVE exists, a maintainer can request one through GitHub.
- The corrected packages or Meteor versions are released.
- The advisory is published together with the security release and communication to users.
This would give maintainers a central place to coordinate fixes without disclosing vulnerabilities too early.
Automating Dependency Security Audits
There is already an open PR proposing automated npm security audits proposed by @harry97. This could help us detect vulnerable dependencies earlier, monitor Meteor’s npm packages continuously, and gradually introduce blocking checks for new high- or critical-severity findings without letting existing audit noise disrupt development.
Using Security Analysis Tools
We should also evaluate security analysis tools that can identify risks beyond npm dependencies. The StepSecurity PR opened @storyteller, for example, highlights possible improvements to GitHub Actions, token permissions, and third-party workflow dependencies. These tools could become part of periodic repository reviews, with maintainers validating each recommendation before adopting it.
But this PR bring me up a few questions: what tools should we use? what open source solutions do we have in the market?
Publishing an SBOM for Meteor Releases
Meteor could generate and publish a Software Bill of Materials for each release. An SBOM would provide a machine-readable inventory of the included packages and versions, helping maintainers and users quickly determine whether a release contains a vulnerable component. It would also improve supply-chain visibility and support organizations with security or compliance requirements.
Opening the discussion
npm audit cannot determine by itself whether every finding is exploitable in a Meteor application. It is only one input in a broader process of detection, triage, correction, and communication.
The goal of this proposal is not to suggest that Meteor is insecure. It is to make our security work more continuous, visible, and predictable.
These are only some initial ideas. We would like to hear from the community: what else can we improve in the framework, tooling, documentation, release process, or project governance. The idea is make Meteor and the applications built with it more secure?