From 1edb908e2077abf819151f52db3691dde1e5d680 Mon Sep 17 00:00:00 2001
From: Roeniss Moon <roeniss2@gmail.com>
Date: Sun, 18 Jan 2026 19:43:53 +0900
Subject: [PATCH] chore: Update obsolete untranslated articles for some
 languages

---
 ...ing-balance-for-open-source-maintainers.md |  7 +-
 ...ecurity-best-practices-for-your-project.md | 80 ++++++++++++++++++-
 ...ecurity-best-practices-for-your-project.md | 80 ++++++++++++++++++-
 ...ing-balance-for-open-source-maintainers.md | 17 ++--
 ...ecurity-best-practices-for-your-project.md | 80 ++++++++++++++++++-
 ...ecurity-best-practices-for-your-project.md | 80 ++++++++++++++++++-
 ...ecurity-best-practices-for-your-project.md | 80 ++++++++++++++++++-
 ...ing-balance-for-open-source-maintainers.md | 17 ++--
 ...ecurity-best-practices-for-your-project.md | 80 ++++++++++++++++++-
 ...ing-balance-for-open-source-maintainers.md | 17 ++--
 ...ecurity-best-practices-for-your-project.md | 80 ++++++++++++++++++-
 ...ecurity-best-practices-for-your-project.md | 80 ++++++++++++++++++-
 ...ecurity-best-practices-for-your-project.md | 80 ++++++++++++++++++-
 ...ing-balance-for-open-source-maintainers.md | 17 ++--
 ...ecurity-best-practices-for-your-project.md | 80 ++++++++++++++++++-
 ...ing-balance-for-open-source-maintainers.md | 17 ++--
 ...ecurity-best-practices-for-your-project.md | 80 ++++++++++++++++++-
 ...ing-balance-for-open-source-maintainers.md | 19 +++--
 ...ecurity-best-practices-for-your-project.md | 80 ++++++++++++++++++-
 ...ecurity-best-practices-for-your-project.md | 80 ++++++++++++++++++-
 ...ecurity-best-practices-for-your-project.md | 80 ++++++++++++++++++-
 ...ing-balance-for-open-source-maintainers.md | 17 ++--
 ...ecurity-best-practices-for-your-project.md | 80 ++++++++++++++++++-
 ...ecurity-best-practices-for-your-project.md | 80 ++++++++++++++++++-
 ...ecurity-best-practices-for-your-project.md | 80 ++++++++++++++++++-
 25 files changed, 1369 insertions(+), 119 deletions(-)

diff --git a/_articles/bn/maintaining-balance-for-open-source-maintainers.md b/_articles/bn/maintaining-balance-for-open-source-maintainers.md
index 7aa999c22c2..19aa51978a8 100644
--- a/_articles/bn/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/bn/maintaining-balance-for-open-source-maintainers.md
@@ -156,7 +156,7 @@ My software is gratis, but my time and attention is not.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
-It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
   </p>
@@ -172,9 +172,8 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 * [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
-* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
-* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
-* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+* [Saying No](https://mikemcquaid.com/saying-no/)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series
 
 ## Contributors
 
diff --git a/_articles/bn/security-best-practices-for-your-project.md b/_articles/bn/security-best-practices-for-your-project.md
index 6fd0533b9da..a131e94af19 100644
--- a/_articles/bn/security-best-practices-for-your-project.md
+++ b/_articles/bn/security-best-practices-for-your-project.md
@@ -50,13 +50,27 @@ Picture this: a project built on the sturdy foundation of a widely-used library.
 
 To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks. 
 
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
 ## Avoid unwanted changes with protected branches
 
 ### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
 
 A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
 
-## Set up an intake mechanism for vulnerability reporting
+## Make it easy (and safe) to report security issues
 
 ### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
 
@@ -70,15 +84,75 @@ To avoid this, publish a security policy. A security policy, defined in a `SECUR
 
 On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
 
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ulisesgascon?s=180" class="pquote-avatar" alt="avatar">
+  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.
+  <p markdown="1" class="pquote-credit">
+— [@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)
+  </p>
+</aside>
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+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 incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts  
+* How severity is evaluated and how mitigation decisions are made  
+* What steps you take to prepare a fix and coordinate disclosure  
+* How you notify affected users, contributors, or downstream consumers 
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+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.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
 ## Conclusion: A few steps for you, a huge improvement for your users
 
 These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
 
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
 ## Contributors
 
 ### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
 
 This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
 
-[@JLLeitschuh](https://github.com/JLLeitschuh)
-[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/de/security-best-practices-for-your-project.md b/_articles/de/security-best-practices-for-your-project.md
index 203d300298c..123a84577dd 100644
--- a/_articles/de/security-best-practices-for-your-project.md
+++ b/_articles/de/security-best-practices-for-your-project.md
@@ -50,13 +50,27 @@ Picture this: a project built on the sturdy foundation of a widely-used library.
 
 To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks. 
 
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
 ## Avoid unwanted changes with protected branches
 
 ### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
 
 A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
 
-## Set up an intake mechanism for vulnerability reporting
+## Make it easy (and safe) to report security issues
 
 ### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
 
@@ -70,15 +84,75 @@ To avoid this, publish a security policy. A security policy, defined in a `SECUR
 
 On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
 
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ulisesgascon?s=180" class="pquote-avatar" alt="avatar">
+  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.
+  <p markdown="1" class="pquote-credit">
+— [@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)
+  </p>
+</aside>
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+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 incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts  
+* How severity is evaluated and how mitigation decisions are made  
+* What steps you take to prepare a fix and coordinate disclosure  
+* How you notify affected users, contributors, or downstream consumers 
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+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.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
 ## Conclusion: A few steps for you, a huge improvement for your users
 
 These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
 
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
 ## Contributors
 
 ### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
 
 This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
 
-[@JLLeitschuh](https://github.com/JLLeitschuh)
-[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/el/maintaining-balance-for-open-source-maintainers.md b/_articles/el/maintaining-balance-for-open-source-maintainers.md
index 7320d7227c5..1de9b14f448 100644
--- a/_articles/el/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/el/maintaining-balance-for-open-source-maintainers.md
@@ -8,7 +8,7 @@ order: 0
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 ---
 
-As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run.
 
 To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
 
@@ -73,7 +73,7 @@ It's important to understand what causes us to get burned out. Here are a few co
   </p>
 </aside>
 
-* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+* **Conflicting demands:** Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
 
 <aside markdown="1" class="pquote">
   With paid open source, conflict between employer's focus and what's best for the community
@@ -99,7 +99,7 @@ There are tools like the [Burnout Checklist](https://governingopen.com/resources
 
 This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
 
-* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning.
 
   You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
 
@@ -144,7 +144,7 @@ To meaningfully trust others on these axes, you cannot be someone who says yes t
   </p>
 </aside>
 
-  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
@@ -156,7 +156,7 @@ My software is gratis, but my time and attention is not.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
-It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
   </p>
@@ -168,19 +168,18 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 
 * [Maintainer Community](http://maintainers.github.com/)
 * [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
-* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
 * [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
-* [Saying No](https://mikemcquaid.com/saying-no/), Mike McQuaid
-* [Governing Open](https://governingopen.com/)
+* [Saying No](https://mikemcquaid.com/saying-no/)
 * Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series
 
 ## Contributors
 
 Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
 
-This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from:
 
 [@agnostic-apollo](https://github.com/agnostic-apollo)
 [@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
diff --git a/_articles/el/security-best-practices-for-your-project.md b/_articles/el/security-best-practices-for-your-project.md
index 8d1b80b51ca..899dcb34c37 100644
--- a/_articles/el/security-best-practices-for-your-project.md
+++ b/_articles/el/security-best-practices-for-your-project.md
@@ -50,13 +50,27 @@ Picture this: a project built on the sturdy foundation of a widely-used library.
 
 To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks. 
 
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
 ## Avoid unwanted changes with protected branches
 
 ### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
 
 A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
 
-## Set up an intake mechanism for vulnerability reporting
+## Make it easy (and safe) to report security issues
 
 ### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
 
@@ -70,15 +84,75 @@ To avoid this, publish a security policy. A security policy, defined in a `SECUR
 
 On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
 
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ulisesgascon?s=180" class="pquote-avatar" alt="avatar">
+  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.
+  <p markdown="1" class="pquote-credit">
+— [@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)
+  </p>
+</aside>
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+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 incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts  
+* How severity is evaluated and how mitigation decisions are made  
+* What steps you take to prepare a fix and coordinate disclosure  
+* How you notify affected users, contributors, or downstream consumers 
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+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.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
 ## Conclusion: A few steps for you, a huge improvement for your users
 
 These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
 
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
 ## Contributors
 
 ### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
 
 This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
 
-[@JLLeitschuh](https://github.com/JLLeitschuh)
-[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/fr/security-best-practices-for-your-project.md b/_articles/fr/security-best-practices-for-your-project.md
index a048e13edcc..79e03a628e1 100644
--- a/_articles/fr/security-best-practices-for-your-project.md
+++ b/_articles/fr/security-best-practices-for-your-project.md
@@ -50,13 +50,27 @@ Picture this: a project built on the sturdy foundation of a widely-used library.
 
 To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks. 
 
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
 ## Avoid unwanted changes with protected branches
 
 ### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
 
 A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
 
-## Set up an intake mechanism for vulnerability reporting
+## Make it easy (and safe) to report security issues
 
 ### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
 
@@ -70,15 +84,75 @@ To avoid this, publish a security policy. A security policy, defined in a `SECUR
 
 On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
 
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ulisesgascon?s=180" class="pquote-avatar" alt="avatar">
+  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.
+  <p markdown="1" class="pquote-credit">
+— [@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)
+  </p>
+</aside>
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+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 incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts  
+* How severity is evaluated and how mitigation decisions are made  
+* What steps you take to prepare a fix and coordinate disclosure  
+* How you notify affected users, contributors, or downstream consumers 
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+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.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
 ## Conclusion: A few steps for you, a huge improvement for your users
 
 These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
 
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
 ## Contributors
 
 ### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
 
 This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
 
-[@JLLeitschuh](https://github.com/JLLeitschuh)
-[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/hi/security-best-practices-for-your-project.md b/_articles/hi/security-best-practices-for-your-project.md
index 386adeb8765..713f36c1bb0 100644
--- a/_articles/hi/security-best-practices-for-your-project.md
+++ b/_articles/hi/security-best-practices-for-your-project.md
@@ -50,13 +50,27 @@ Picture this: a project built on the sturdy foundation of a widely-used library.
 
 To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks. 
 
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
 ## Avoid unwanted changes with protected branches
 
 ### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
 
 A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
 
-## Set up an intake mechanism for vulnerability reporting
+## Make it easy (and safe) to report security issues
 
 ### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
 
@@ -70,15 +84,75 @@ To avoid this, publish a security policy. A security policy, defined in a `SECUR
 
 On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
 
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ulisesgascon?s=180" class="pquote-avatar" alt="avatar">
+  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.
+  <p markdown="1" class="pquote-credit">
+— [@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)
+  </p>
+</aside>
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+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 incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts  
+* How severity is evaluated and how mitigation decisions are made  
+* What steps you take to prepare a fix and coordinate disclosure  
+* How you notify affected users, contributors, or downstream consumers 
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+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.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
 ## Conclusion: A few steps for you, a huge improvement for your users
 
 These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
 
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
 ## Contributors
 
 ### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
 
 This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
 
-[@JLLeitschuh](https://github.com/JLLeitschuh)
-[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/hu/maintaining-balance-for-open-source-maintainers.md b/_articles/hu/maintaining-balance-for-open-source-maintainers.md
index 224b70e715d..ebf6888caa7 100644
--- a/_articles/hu/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/hu/maintaining-balance-for-open-source-maintainers.md
@@ -8,7 +8,7 @@ order: 0
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 ---
 
-As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run.
 
 To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
 
@@ -73,7 +73,7 @@ It's important to understand what causes us to get burned out. Here are a few co
   </p>
 </aside>
 
-* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+* **Conflicting demands:** Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
 
 <aside markdown="1" class="pquote">
   With paid open source, conflict between employer's focus and what's best for the community
@@ -99,7 +99,7 @@ There are tools like the [Burnout Checklist](https://governingopen.com/resources
 
 This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
 
-* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning.
 
   You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
 
@@ -144,7 +144,7 @@ To meaningfully trust others on these axes, you cannot be someone who says yes t
   </p>
 </aside>
 
-  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
@@ -156,7 +156,7 @@ My software is gratis, but my time and attention is not.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
-It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
   </p>
@@ -168,19 +168,18 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 
 * [Maintainer Community](http://maintainers.github.com/)
 * [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
-* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
 * [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
-* [Saying No](https://mikemcquaid.com/saying-no/), Mike McQuaid
-* [Governing Open](https://governingopen.com/)
+* [Saying No](https://mikemcquaid.com/saying-no/)
 * Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series
 
 ## Contributors
 
 Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
 
-This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from:
 
 [@agnostic-apollo](https://github.com/agnostic-apollo)
 [@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
diff --git a/_articles/hu/security-best-practices-for-your-project.md b/_articles/hu/security-best-practices-for-your-project.md
index b1bfd9df2ae..e754bf61e71 100644
--- a/_articles/hu/security-best-practices-for-your-project.md
+++ b/_articles/hu/security-best-practices-for-your-project.md
@@ -50,13 +50,27 @@ Picture this: a project built on the sturdy foundation of a widely-used library.
 
 To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks. 
 
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
 ## Avoid unwanted changes with protected branches
 
 ### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
 
 A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
 
-## Set up an intake mechanism for vulnerability reporting
+## Make it easy (and safe) to report security issues
 
 ### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
 
@@ -70,15 +84,75 @@ To avoid this, publish a security policy. A security policy, defined in a `SECUR
 
 On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
 
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ulisesgascon?s=180" class="pquote-avatar" alt="avatar">
+  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.
+  <p markdown="1" class="pquote-credit">
+— [@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)
+  </p>
+</aside>
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+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 incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts  
+* How severity is evaluated and how mitigation decisions are made  
+* What steps you take to prepare a fix and coordinate disclosure  
+* How you notify affected users, contributors, or downstream consumers 
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+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.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
 ## Conclusion: A few steps for you, a huge improvement for your users
 
 These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
 
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
 ## Contributors
 
 ### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
 
 This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
 
-[@JLLeitschuh](https://github.com/JLLeitschuh)
-[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/id/maintaining-balance-for-open-source-maintainers.md b/_articles/id/maintaining-balance-for-open-source-maintainers.md
index e59b7919cdf..11b205f60f7 100644
--- a/_articles/id/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/id/maintaining-balance-for-open-source-maintainers.md
@@ -8,7 +8,7 @@ order: 0
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 ---
 
-As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run.
 
 To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
 
@@ -73,7 +73,7 @@ It's important to understand what causes us to get burned out. Here are a few co
   </p>
 </aside>
 
-* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+* **Conflicting demands:** Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
 
 <aside markdown="1" class="pquote">
   With paid open source, conflict between employer's focus and what's best for the community
@@ -99,7 +99,7 @@ There are tools like the [Burnout Checklist](https://governingopen.com/resources
 
 This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
 
-* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning.
 
   You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
 
@@ -144,7 +144,7 @@ To meaningfully trust others on these axes, you cannot be someone who says yes t
   </p>
 </aside>
 
-  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
@@ -156,7 +156,7 @@ My software is gratis, but my time and attention is not.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
-It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
   </p>
@@ -168,19 +168,18 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 
 * [Maintainer Community](http://maintainers.github.com/)
 * [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
-* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
 * [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
-* [Saying No](https://mikemcquaid.com/saying-no/), Mike McQuaid
-* [Governing Open](https://governingopen.com/)
+* [Saying No](https://mikemcquaid.com/saying-no/)
 * Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series
 
 ## Contributors
 
 Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
 
-This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from:
 
 [@agnostic-apollo](https://github.com/agnostic-apollo)
 [@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
diff --git a/_articles/id/security-best-practices-for-your-project.md b/_articles/id/security-best-practices-for-your-project.md
index 1fbb5b55d11..cfb4d70009e 100644
--- a/_articles/id/security-best-practices-for-your-project.md
+++ b/_articles/id/security-best-practices-for-your-project.md
@@ -50,13 +50,27 @@ Picture this: a project built on the sturdy foundation of a widely-used library.
 
 To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks. 
 
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
 ## Avoid unwanted changes with protected branches
 
 ### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
 
 A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
 
-## Set up an intake mechanism for vulnerability reporting
+## Make it easy (and safe) to report security issues
 
 ### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
 
@@ -70,15 +84,75 @@ To avoid this, publish a security policy. A security policy, defined in a `SECUR
 
 On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
 
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ulisesgascon?s=180" class="pquote-avatar" alt="avatar">
+  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.
+  <p markdown="1" class="pquote-credit">
+— [@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)
+  </p>
+</aside>
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+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 incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts  
+* How severity is evaluated and how mitigation decisions are made  
+* What steps you take to prepare a fix and coordinate disclosure  
+* How you notify affected users, contributors, or downstream consumers 
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+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.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
 ## Conclusion: A few steps for you, a huge improvement for your users
 
 These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
 
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
 ## Contributors
 
 ### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
 
 This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
 
-[@JLLeitschuh](https://github.com/JLLeitschuh)
-[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/ja/security-best-practices-for-your-project.md b/_articles/ja/security-best-practices-for-your-project.md
index 7be942d99e7..c1274dc144b 100644
--- a/_articles/ja/security-best-practices-for-your-project.md
+++ b/_articles/ja/security-best-practices-for-your-project.md
@@ -50,13 +50,27 @@ Picture this: a project built on the sturdy foundation of a widely-used library.
 
 To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks. 
 
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
 ## Avoid unwanted changes with protected branches
 
 ### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
 
 A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
 
-## Set up an intake mechanism for vulnerability reporting
+## Make it easy (and safe) to report security issues
 
 ### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
 
@@ -70,15 +84,75 @@ To avoid this, publish a security policy. A security policy, defined in a `SECUR
 
 On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
 
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ulisesgascon?s=180" class="pquote-avatar" alt="avatar">
+  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.
+  <p markdown="1" class="pquote-credit">
+— [@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)
+  </p>
+</aside>
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+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 incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts  
+* How severity is evaluated and how mitigation decisions are made  
+* What steps you take to prepare a fix and coordinate disclosure  
+* How you notify affected users, contributors, or downstream consumers 
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+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.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
 ## Conclusion: A few steps for you, a huge improvement for your users
 
 These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
 
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
 ## Contributors
 
 ### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
 
 This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
 
-[@JLLeitschuh](https://github.com/JLLeitschuh)
-[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/ko/security-best-practices-for-your-project.md b/_articles/ko/security-best-practices-for-your-project.md
index 5ddcd1a1380..c7ea6ef44b0 100644
--- a/_articles/ko/security-best-practices-for-your-project.md
+++ b/_articles/ko/security-best-practices-for-your-project.md
@@ -50,13 +50,27 @@ Picture this: a project built on the sturdy foundation of a widely-used library.
 
 To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks. 
 
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
 ## Avoid unwanted changes with protected branches
 
 ### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
 
 A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
 
-## Set up an intake mechanism for vulnerability reporting
+## Make it easy (and safe) to report security issues
 
 ### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
 
@@ -70,15 +84,75 @@ To avoid this, publish a security policy. A security policy, defined in a `SECUR
 
 On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
 
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ulisesgascon?s=180" class="pquote-avatar" alt="avatar">
+  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.
+  <p markdown="1" class="pquote-credit">
+— [@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)
+  </p>
+</aside>
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+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 incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts  
+* How severity is evaluated and how mitigation decisions are made  
+* What steps you take to prepare a fix and coordinate disclosure  
+* How you notify affected users, contributors, or downstream consumers 
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+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.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
 ## Conclusion: A few steps for you, a huge improvement for your users
 
 These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
 
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
 ## Contributors
 
 ### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
 
 This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
 
-[@JLLeitschuh](https://github.com/JLLeitschuh)
-[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/ms/maintaining-balance-for-open-source-maintainers.md b/_articles/ms/maintaining-balance-for-open-source-maintainers.md
index 3166fa10552..1fcbfd51257 100644
--- a/_articles/ms/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/ms/maintaining-balance-for-open-source-maintainers.md
@@ -8,7 +8,7 @@ order: 0
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 ---
 
-As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run.
 
 To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
 
@@ -73,7 +73,7 @@ It's important to understand what causes us to get burned out. Here are a few co
   </p>
 </aside>
 
-* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+* **Conflicting demands:** Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
 
 <aside markdown="1" class="pquote">
   With paid open source, conflict between employer's focus and what's best for the community
@@ -99,7 +99,7 @@ There are tools like the [Burnout Checklist](https://governingopen.com/resources
 
 This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
 
-* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning.
 
   You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
 
@@ -144,7 +144,7 @@ To meaningfully trust others on these axes, you cannot be someone who says yes t
   </p>
 </aside>
 
-  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
@@ -156,7 +156,7 @@ My software is gratis, but my time and attention is not.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
-It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
   </p>
@@ -168,19 +168,18 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 
 * [Maintainer Community](http://maintainers.github.com/)
 * [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
-* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
 * [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
-* [Saying No](https://mikemcquaid.com/saying-no/), Mike McQuaid
-* [Governing Open](https://governingopen.com/)
+* [Saying No](https://mikemcquaid.com/saying-no/)
 * Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series
 
 ## Contributors
 
 Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
 
-This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from:
 
 [@agnostic-apollo](https://github.com/agnostic-apollo)
 [@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
diff --git a/_articles/ms/security-best-practices-for-your-project.md b/_articles/ms/security-best-practices-for-your-project.md
index 0440ac47a65..a31efb4e6b7 100644
--- a/_articles/ms/security-best-practices-for-your-project.md
+++ b/_articles/ms/security-best-practices-for-your-project.md
@@ -50,13 +50,27 @@ Picture this: a project built on the sturdy foundation of a widely-used library.
 
 To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks. 
 
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
 ## Avoid unwanted changes with protected branches
 
 ### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
 
 A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
 
-## Set up an intake mechanism for vulnerability reporting
+## Make it easy (and safe) to report security issues
 
 ### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
 
@@ -70,15 +84,75 @@ To avoid this, publish a security policy. A security policy, defined in a `SECUR
 
 On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
 
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ulisesgascon?s=180" class="pquote-avatar" alt="avatar">
+  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.
+  <p markdown="1" class="pquote-credit">
+— [@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)
+  </p>
+</aside>
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+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 incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts  
+* How severity is evaluated and how mitigation decisions are made  
+* What steps you take to prepare a fix and coordinate disclosure  
+* How you notify affected users, contributors, or downstream consumers 
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+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.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
 ## Conclusion: A few steps for you, a huge improvement for your users
 
 These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
 
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
 ## Contributors
 
 ### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
 
 This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
 
-[@JLLeitschuh](https://github.com/JLLeitschuh)
-[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/nl/maintaining-balance-for-open-source-maintainers.md b/_articles/nl/maintaining-balance-for-open-source-maintainers.md
index bbcdd1e890e..50cae409ad5 100644
--- a/_articles/nl/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/nl/maintaining-balance-for-open-source-maintainers.md
@@ -8,7 +8,7 @@ order: 0
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 ---
 
-As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run.
 
 To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
 
@@ -73,7 +73,7 @@ It's important to understand what causes us to get burned out. Here are a few co
   </p>
 </aside>
 
-* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+* **Conflicting demands:** Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
 
 <aside markdown="1" class="pquote">
   With paid open source, conflict between employer's focus and what's best for the community
@@ -99,7 +99,7 @@ There are tools like the [Burnout Checklist](https://governingopen.com/resources
 
 This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
 
-* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning.
 
   You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
 
@@ -144,7 +144,7 @@ To meaningfully trust others on these axes, you cannot be someone who says yes t
   </p>
 </aside>
 
-  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
@@ -156,7 +156,7 @@ My software is gratis, but my time and attention is not.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
-It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
   </p>
@@ -168,19 +168,18 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 
 * [Maintainer Community](http://maintainers.github.com/)
 * [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
-* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
 * [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
-* [Saying No](https://mikemcquaid.com/saying-no/), Mike McQuaid
-* [Governing Open](https://governingopen.com/)
+* [Saying No](https://mikemcquaid.com/saying-no/)
 * Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series
 
 ## Contributors
 
 Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
 
-This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from:
 
 [@agnostic-apollo](https://github.com/agnostic-apollo)
 [@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
diff --git a/_articles/nl/security-best-practices-for-your-project.md b/_articles/nl/security-best-practices-for-your-project.md
index 40b31985e9e..c7dce473faf 100644
--- a/_articles/nl/security-best-practices-for-your-project.md
+++ b/_articles/nl/security-best-practices-for-your-project.md
@@ -50,13 +50,27 @@ Picture this: a project built on the sturdy foundation of a widely-used library.
 
 To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks. 
 
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
 ## Avoid unwanted changes with protected branches
 
 ### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
 
 A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
 
-## Set up an intake mechanism for vulnerability reporting
+## Make it easy (and safe) to report security issues
 
 ### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
 
@@ -70,15 +84,75 @@ To avoid this, publish a security policy. A security policy, defined in a `SECUR
 
 On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
 
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ulisesgascon?s=180" class="pquote-avatar" alt="avatar">
+  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.
+  <p markdown="1" class="pquote-credit">
+— [@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)
+  </p>
+</aside>
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+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 incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts  
+* How severity is evaluated and how mitigation decisions are made  
+* What steps you take to prepare a fix and coordinate disclosure  
+* How you notify affected users, contributors, or downstream consumers 
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+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.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
 ## Conclusion: A few steps for you, a huge improvement for your users
 
 These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
 
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
 ## Contributors
 
 ### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
 
 This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
 
-[@JLLeitschuh](https://github.com/JLLeitschuh)
-[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/pcm/maintaining-balance-for-open-source-maintainers.md b/_articles/pcm/maintaining-balance-for-open-source-maintainers.md
index a7bd2aab9e9..092c1ed6263 100644
--- a/_articles/pcm/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/pcm/maintaining-balance-for-open-source-maintainers.md
@@ -8,7 +8,7 @@ order: 0
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 ---
 
-As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run.
 
 To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
 
@@ -73,7 +73,7 @@ It's important to understand what causes us to get burned out. Here are a few co
   </p>
 </aside>
 
-* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+* **Conflicting demands:** Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
 
 <aside markdown="1" class="pquote">
   With paid open source, conflict between employer's focus and what's best for the community
@@ -99,7 +99,7 @@ There are tools like the [Burnout Checklist](https://governingopen.com/resources
 
 This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
 
-* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning.
 
   You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
 
@@ -144,7 +144,7 @@ To meaningfully trust others on these axes, you cannot be someone who says yes t
   </p>
 </aside>
 
-  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
@@ -156,7 +156,7 @@ My software is gratis, but my time and attention is not.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
-It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
   </p>
@@ -168,19 +168,18 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 
 * [Maintainer Community](http://maintainers.github.com/)
 * [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
-* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
 * [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
-* [Saying No](https://mikemcquaid.com/saying-no/), Mike McQuaid
-* [Governing Open](https://governingopen.com/)
-* Workshop agenda was remixed from [Mozilla's Movement Building from Home](hhttps://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series
+* [Saying No](https://mikemcquaid.com/saying-no/)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series
 
 ## Contributors
 
 Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
 
-This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from:
 
 [@agnostic-apollo](https://github.com/agnostic-apollo)
 [@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
diff --git a/_articles/pcm/security-best-practices-for-your-project.md b/_articles/pcm/security-best-practices-for-your-project.md
index 424d1b04180..396368e6633 100644
--- a/_articles/pcm/security-best-practices-for-your-project.md
+++ b/_articles/pcm/security-best-practices-for-your-project.md
@@ -50,13 +50,27 @@ Picture this: a project built on the sturdy foundation of a widely-used library.
 
 To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks. 
 
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
 ## Avoid unwanted changes with protected branches
 
 ### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
 
 A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
 
-## Set up an intake mechanism for vulnerability reporting
+## Make it easy (and safe) to report security issues
 
 ### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
 
@@ -70,15 +84,75 @@ To avoid this, publish a security policy. A security policy, defined in a `SECUR
 
 On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
 
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ulisesgascon?s=180" class="pquote-avatar" alt="avatar">
+  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.
+  <p markdown="1" class="pquote-credit">
+— [@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)
+  </p>
+</aside>
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+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 incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts  
+* How severity is evaluated and how mitigation decisions are made  
+* What steps you take to prepare a fix and coordinate disclosure  
+* How you notify affected users, contributors, or downstream consumers 
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+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.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
 ## Conclusion: A few steps for you, a huge improvement for your users
 
 These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
 
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
 ## Contributors
 
 ### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
 
 This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
 
-[@JLLeitschuh](https://github.com/JLLeitschuh)
-[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/pl/security-best-practices-for-your-project.md b/_articles/pl/security-best-practices-for-your-project.md
index 3c7249de79e..82e658624ea 100644
--- a/_articles/pl/security-best-practices-for-your-project.md
+++ b/_articles/pl/security-best-practices-for-your-project.md
@@ -50,13 +50,27 @@ Picture this: a project built on the sturdy foundation of a widely-used library.
 
 To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks. 
 
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
 ## Avoid unwanted changes with protected branches
 
 ### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
 
 A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
 
-## Set up an intake mechanism for vulnerability reporting
+## Make it easy (and safe) to report security issues
 
 ### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
 
@@ -70,15 +84,75 @@ To avoid this, publish a security policy. A security policy, defined in a `SECUR
 
 On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
 
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ulisesgascon?s=180" class="pquote-avatar" alt="avatar">
+  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.
+  <p markdown="1" class="pquote-credit">
+— [@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)
+  </p>
+</aside>
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+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 incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts  
+* How severity is evaluated and how mitigation decisions are made  
+* What steps you take to prepare a fix and coordinate disclosure  
+* How you notify affected users, contributors, or downstream consumers 
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+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.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
 ## Conclusion: A few steps for you, a huge improvement for your users
 
 These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
 
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
 ## Contributors
 
 ### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
 
 This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
 
-[@JLLeitschuh](https://github.com/JLLeitschuh)
-[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/pt/security-best-practices-for-your-project.md b/_articles/pt/security-best-practices-for-your-project.md
index f8601c9b41b..c9c37a49956 100644
--- a/_articles/pt/security-best-practices-for-your-project.md
+++ b/_articles/pt/security-best-practices-for-your-project.md
@@ -50,13 +50,27 @@ Picture this: a project built on the sturdy foundation of a widely-used library.
 
 To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks. 
 
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
 ## Avoid unwanted changes with protected branches
 
 ### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
 
 A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
 
-## Set up an intake mechanism for vulnerability reporting
+## Make it easy (and safe) to report security issues
 
 ### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
 
@@ -70,15 +84,75 @@ To avoid this, publish a security policy. A security policy, defined in a `SECUR
 
 On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
 
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ulisesgascon?s=180" class="pquote-avatar" alt="avatar">
+  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.
+  <p markdown="1" class="pquote-credit">
+— [@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)
+  </p>
+</aside>
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+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 incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts  
+* How severity is evaluated and how mitigation decisions are made  
+* What steps you take to prepare a fix and coordinate disclosure  
+* How you notify affected users, contributors, or downstream consumers 
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+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.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
 ## Conclusion: A few steps for you, a huge improvement for your users
 
 These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
 
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
 ## Contributors
 
 ### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
 
 This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
 
-[@JLLeitschuh](https://github.com/JLLeitschuh)
-[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/ro/maintaining-balance-for-open-source-maintainers.md b/_articles/ro/maintaining-balance-for-open-source-maintainers.md
index 5e5a3d800a8..ce1f8bdad2a 100644
--- a/_articles/ro/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/ro/maintaining-balance-for-open-source-maintainers.md
@@ -8,7 +8,7 @@ order: 0
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 ---
 
-As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run.
 
 To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
 
@@ -73,7 +73,7 @@ It's important to understand what causes us to get burned out. Here are a few co
   </p>
 </aside>
 
-* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+* **Conflicting demands:** Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
 
 <aside markdown="1" class="pquote">
   With paid open source, conflict between employer's focus and what's best for the community
@@ -99,7 +99,7 @@ There are tools like the [Burnout Checklist](https://governingopen.com/resources
 
 This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
 
-* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning.
 
   You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
 
@@ -144,7 +144,7 @@ To meaningfully trust others on these axes, you cannot be someone who says yes t
   </p>
 </aside>
 
-  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
@@ -156,7 +156,7 @@ My software is gratis, but my time and attention is not.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
-It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
   </p>
@@ -168,19 +168,18 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
 
 * [Maintainer Community](http://maintainers.github.com/)
 * [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
-* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
 * [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
 * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
-* [Saying No](https://mikemcquaid.com/saying-no/), Mike McQuaid
-* [Governing Open](https://governingopen.com/)
+* [Saying No](https://mikemcquaid.com/saying-no/)
 * Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series
 
 ## Contributors
 
 Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
 
-This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from:
 
 [@agnostic-apollo](https://github.com/agnostic-apollo)
 [@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
diff --git a/_articles/ro/security-best-practices-for-your-project.md b/_articles/ro/security-best-practices-for-your-project.md
index b3ee8ac0fc1..337621a9cad 100644
--- a/_articles/ro/security-best-practices-for-your-project.md
+++ b/_articles/ro/security-best-practices-for-your-project.md
@@ -50,13 +50,27 @@ Picture this: a project built on the sturdy foundation of a widely-used library.
 
 To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks. 
 
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
 ## Avoid unwanted changes with protected branches
 
 ### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
 
 A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
 
-## Set up an intake mechanism for vulnerability reporting
+## Make it easy (and safe) to report security issues
 
 ### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
 
@@ -70,15 +84,75 @@ To avoid this, publish a security policy. A security policy, defined in a `SECUR
 
 On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
 
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ulisesgascon?s=180" class="pquote-avatar" alt="avatar">
+  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.
+  <p markdown="1" class="pquote-credit">
+— [@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)
+  </p>
+</aside>
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+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 incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts  
+* How severity is evaluated and how mitigation decisions are made  
+* What steps you take to prepare a fix and coordinate disclosure  
+* How you notify affected users, contributors, or downstream consumers 
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+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.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
 ## Conclusion: A few steps for you, a huge improvement for your users
 
 These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
 
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
 ## Contributors
 
 ### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
 
 This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
 
-[@JLLeitschuh](https://github.com/JLLeitschuh)
-[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/sw/security-best-practices-for-your-project.md b/_articles/sw/security-best-practices-for-your-project.md
index b4ad2295148..21d88ca2e8e 100644
--- a/_articles/sw/security-best-practices-for-your-project.md
+++ b/_articles/sw/security-best-practices-for-your-project.md
@@ -50,13 +50,27 @@ Picture this: a project built on the sturdy foundation of a widely-used library.
 
 To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks. 
 
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
 ## Avoid unwanted changes with protected branches
 
 ### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
 
 A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
 
-## Set up an intake mechanism for vulnerability reporting
+## Make it easy (and safe) to report security issues
 
 ### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
 
@@ -70,15 +84,75 @@ To avoid this, publish a security policy. A security policy, defined in a `SECUR
 
 On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
 
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ulisesgascon?s=180" class="pquote-avatar" alt="avatar">
+  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.
+  <p markdown="1" class="pquote-credit">
+— [@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)
+  </p>
+</aside>
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+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 incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts  
+* How severity is evaluated and how mitigation decisions are made  
+* What steps you take to prepare a fix and coordinate disclosure  
+* How you notify affected users, contributors, or downstream consumers 
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+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.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
 ## Conclusion: A few steps for you, a huge improvement for your users
 
 These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
 
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
 ## Contributors
 
 ### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
 
 This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
 
-[@JLLeitschuh](https://github.com/JLLeitschuh)
-[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/zh-hant/security-best-practices-for-your-project.md b/_articles/zh-hant/security-best-practices-for-your-project.md
index c43ca139d8f..f7a81a4fea6 100644
--- a/_articles/zh-hant/security-best-practices-for-your-project.md
+++ b/_articles/zh-hant/security-best-practices-for-your-project.md
@@ -50,13 +50,27 @@ Picture this: a project built on the sturdy foundation of a widely-used library.
 
 To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks. 
 
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
 ## Avoid unwanted changes with protected branches
 
 ### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
 
 A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
 
-## Set up an intake mechanism for vulnerability reporting
+## Make it easy (and safe) to report security issues
 
 ### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
 
@@ -70,15 +84,75 @@ To avoid this, publish a security policy. A security policy, defined in a `SECUR
 
 On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
 
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/ulisesgascon?s=180" class="pquote-avatar" alt="avatar">
+  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.
+  <p markdown="1" class="pquote-credit">
+— [@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)
+  </p>
+</aside>
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+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 incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts  
+* How severity is evaluated and how mitigation decisions are made  
+* What steps you take to prepare a fix and coordinate disclosure  
+* How you notify affected users, contributors, or downstream consumers 
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+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.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
 ## Conclusion: A few steps for you, a huge improvement for your users
 
 These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
 
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
 ## Contributors
 
 ### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
 
 This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
 
-[@JLLeitschuh](https://github.com/JLLeitschuh)
-[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!