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
A vulnerability is basically a flaw, a security misconfiguration or a weak point in our system that can be exploited by third parties to behave in unintended ways.
104
+
<pmarkdown="1"class="pquote-credit">
105
+
— [@UlisesGascon](https://github.com/ulisesgascon), ["What is a Vulnerability and What’s Not? Making Sense of Node.js and Express Threat Models"](https://gitnation.com/contents/what-is-a-vulnerability-and-whats-not-making-sense-of-nodejs-and-express-threat-models)
106
+
</p>
107
+
</aside>
108
+
109
+
Once you receive a vulnerability report, what happens next?
110
+
111
+
Having a basic incident response plan, even a simple checklist, helps you stay calm and act efficiently when time matters. It also shows users and researchers that you take reports seriously.
112
+
113
+
Your process doesn't have to be complex. At minimum, define:
114
+
- Who reviews and triages security reports
115
+
- How you evaluate severity and decide on mitigation
116
+
- What steps you take to prepare a fix and publish a disclosure
117
+
- How you notify affected users or contributors, if needed
118
+
119
+
Coordinated disclosure works best when there's a clear plan. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
120
+
121
+
For inspiration, the [Express.js Security WG](https://github.com/expressjs/security-wg/blob/main/docs/incident_response_plan.md) provides a simple but effective example of an open source incident response plan.
122
+
123
+
This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes later.
0 commit comments