|
321 | 321 | - Threat modeling guide (soon on MDN) |
322 | 322 | - Example threat model (soon on MDN) |
323 | 323 |
|
324 | | -### Use package managers such as NPM to automatically manage dependencies and enable updates |
| 324 | +### Control dependency updates |
325 | 325 |
|
326 | | -Package managers streamline the process of managing libraries and dependencies, ensuring that you can easily update to the latest versions, which often include important security patches. |
| 326 | +If your project uses any third-party dependencies, you need to be able to respond when updated versions of those packages are released. There are two security considerations here: |
| 327 | + |
| 328 | +- If a vulnerability is found in a dependency, and a fixed version is released, you need to adopt it as soon as possible. |
| 329 | +- If an attacker has compromised the account of one of the dependency's maintainers, and used it to publish a malicious update, you need to avoid adopting it. |
| 330 | + |
| 331 | +To address both these considerations, a software project should: |
| 332 | + |
| 333 | +- Use a package manager and a tool, such as [Dependabot](https://docs.github.com/en/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configuring-dependabot-security-updates) or [Renovate](https://docs.renovatebot.com/), that can monitor your dependencies for known vulnerabilities and updates. |
| 334 | +- Use a [lockfile](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/Supply_chain_attacks#using_a_lockfile) to give you precise control over the versions of your dependencies, and to prevent your build system from automatically updating dependencies. |
| 335 | +- Have a process to review suggested dependency updates, to evaluate the risk/reward of accepting them. |
| 336 | +- Consider enforcing a delay before accepting updates, using settings like Deno's [`minimumDependencyAge`](https://deno.com/blog/v2.6#controlling-dependency-stability): this increases the chances that a malicious update will be discovered before you have accepted it into your own project. |
| 337 | + |
| 338 | +#### Learn more |
| 339 | + |
| 340 | +- [Configuring Dependabot](https://docs.github.com/en/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configuring-dependabot-security-updates) (GitHub) |
| 341 | +- [Package Managers Need to Cool Down](https://nesbitt.io/2026/03/04/package-managers-need-to-cool-down.html) |
327 | 342 |
|
328 | 343 | ### Monitor known vulnerabilities in your web app's direct & indirect dependencies |
329 | 344 |
|
|
333 | 348 |
|
334 | 349 | - [Configuring Dependabot](https://docs.github.com/en/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configuring-dependabot-security-updates) (GitHub) |
335 | 350 |
|
336 | | -### Keep dependencies up to date |
337 | | - |
338 | | -Keeping dependencies (i.e., libraries, polyfills, frameworks, etc.) up to date minimizes the risk of exploitation through known vulnerabilities. Regular updates should be part of your development lifecycle. |
339 | 351 |
|
340 | 352 | ### Do not push secrets to a repository |
341 | 353 |
|
|
0 commit comments