Add a new page on supply chain attacks (#41034)

wbamberg · Elchi3 · github-actions[bot] · web-flow · commit 79f65d8322a4 · 2025-10-09T10:10:13.000-07:00
* Add a new page on supply chain attacks

* Add some glossary pages

* Use MFA glossary entry

* More references to MFA

* Use CI glossary entry

* tweak CI definition

* Rename page

* Apply suggestions from code review

Co-authored-by: Florian Scholz &lt;fs@florianscholz.com&gt;

* Apply suggestions from code review

Co-authored-by: github-actions[bot] &lt;41898282+github-actions[bot]@users.noreply.github.com&gt;

* Defense summary should be H2

* Add a bit on SRI

* Talk about lock files

* lock file-&gt;lockfile

* Don't use SMS as an authentication example

* Link lockfiles to SBOMs

---------

Co-authored-by: Florian Scholz &lt;fs@florianscholz.com&gt;
Co-authored-by: github-actions[bot] &lt;41898282+github-actions[bot]@users.noreply.github.com&gt;
diff --git a/files/en-us/glossary/authentication/index.md b/files/en-us/glossary/authentication/index.md
@@ -7,15 +7,15 @@ sidebar: glossarysidebar
 
 **Authentication** is in general the process of proving that some fact is genuine. More specifically, in web security, it is the process of verifying the claimed identity of some entity, such as a user. This then makes it possible to decide whether to grant the user the access that they are requesting, such as being signed into a particular account.
 
-Authentication is typically performed by having a user present a user identifier along with a {{glossary("credential")}}, such as a password, a one-time SMS code, or an assertion signed with a private key. The system then checks the binding between the user identifier and the credential, so it can decide whether or not to authenticate the user.
+Authentication is typically performed by having a user present a user identifier along with a {{glossary("credential")}}, such as a password, a one-time code, or an assertion signed with a private key. The system then checks the binding between the user identifier and the credential, so it can decide whether or not to authenticate the user.
 
 Types of authentication information, also called _authentication factors_, are commonly presented in three categories:
 
 - Something the user knows, such as a password.
 - Something the user has, such as a phone.
 - Something the user is, such as a thumbprint.
 
-Multi-factor authentication (MFA) systems require the user to provide more than one factor: for example, a password combined with a one-time code sent to the user's phone.
+{{glossary("Multi-factor authentication")}} (MFA) systems require the user to provide more than one factor: for example, a password combined with a one-time code generated using an authenticator app on the user's phone.
 
 ## See also
 
diff --git a/files/en-us/glossary/continuous_integration/index.md b/files/en-us/glossary/continuous_integration/index.md
@@ -0,0 +1,16 @@
+---
+title: Continuous integration
+slug: Glossary/Continuous_integration
+page-type: glossary-definition
+sidebar: glossarysidebar
+---
+
+Continuous integration (CI) is a software development practice in which changes to the source are frequently integrated into the main codebase.
+
+It's an important practice whenever a team of developers is working on a shared codebase. In this situation, different developers might be making overlapping changes to the code at the same time, each in their personal branches. Frequent integration of each developer's changes makes it much less likely that conflicts will occur, and much easier to resolve them when they do.
+
+As [Martin Fowler observes](https://martinfowler.com/articles/continuousIntegration.html#EveryonePushesCommitsToTheMainlineEveryDay):
+
+> Integration is primarily about communication. Integration allows developers to tell other developers about the changes they have made. Frequent communication allows people to know quickly as changes develop.
+
+A major aspect of CI is automated build and test: typically, in a CI system, as soon as a developer opens a pull request to commit their changes to the main branch, an automated process builds the product and runs tests. Once all the tests pass, the change can be peer-reviewed.
diff --git a/files/en-us/glossary/multi-factor_authentication/index.md b/files/en-us/glossary/multi-factor_authentication/index.md
@@ -0,0 +1,18 @@
+---
+title: Multi-factor authentication
+slug: Glossary/Multi-factor_authentication
+page-type: glossary-definition
+sidebar: glossarysidebar
+---
+
+Multi-factor authentication (MFA) is an authentication method in which the user has to present more than one type of evidence to a system in order to be authenticated.
+
+Most commonly, three different types of evidence (or _factors_) are distinguished:
+
+- Something you know, such as a password or PIN
+- Something you have, such as a cellphone or a hardware security token
+- Something you are: a biometric such as a fingerprint
+
+If an authentication system requires the user to provide more than one of these factors in order to authenticate, then it is a multi-factor system.
+
+For example, the system might ask the user for a password as well as a code generated by the authenticator app on their phone.
diff --git a/files/en-us/glossary/principle_of_least_privilege/index.md b/files/en-us/glossary/principle_of_least_privilege/index.md
@@ -0,0 +1,12 @@
+---
+title: Principle of least privilege
+slug: Glossary/Principle_of_least_privilege
+page-type: glossary-definition
+sidebar: glossarysidebar
+---
+
+The principle of least privilege is a design consideration in computer security, according to which entities (including users, system processes, or programs) should be granted the minimum amount of access that they need in order to do their jobs.
+
+For example, in a software development team, all members might need the ability to write to the source code repository, but only a subset of the team might need the ability to alter the repository's security settings.
+
+Applying the principle of least privilege reduces the potential damage when an entity is compromised by an attacker: so for example, if a team member's account is compromised, then the damage that the attacker can do is limited by the privileges that were granted to that team member.
diff --git a/files/en-us/learn_web_development/core/frameworks_libraries/svelte_typescript/index.md b/files/en-us/learn_web_development/core/frameworks_libraries/svelte_typescript/index.md
@@ -215,7 +215,7 @@ And if you pass something that is not a number, it will complain about it:
 
 ![Type checking in VS Code - the ms variable has been given a non-numeric value](06-vscode-type-checking-in-components.png)
 
-The application template has a `check` script configured that runs `svelte-check` against your code. This package allows you to detect errors and warnings normally displayed by a code editor from the command line, which makes it pretty useful for running it in a continuous integration (CI) pipeline. Just run `npm run check` to check for unused CSS, and return A11y hints and TypeScript compile errors.
+The application template has a `check` script configured that runs `svelte-check` against your code. This package allows you to detect errors and warnings normally displayed by a code editor from the command line, which makes it pretty useful for running it in a {{glossary("continuous integration")}} (CI) pipeline. Just run `npm run check` to check for unused CSS, and return A11y hints and TypeScript compile errors.
 
 In this case, if you run `npm run check` (either in the VS Code console or terminal) you will get the following error:
 
diff --git a/files/en-us/learn_web_development/extensions/server-side/express_nodejs/skeleton_website/index.md b/files/en-us/learn_web_development/extensions/server-side/express_nodejs/skeleton_website/index.md
@@ -401,7 +401,7 @@ npm install
 ```
 
 > [!NOTE]
-> It is a good idea to regularly update to the latest compatible versions of your dependency libraries — this may even be done automatically or semi-automatically as part of a continuous integration setup.
+> It is a good idea to regularly update to the latest compatible versions of your dependency libraries — this may even be done automatically or semi-automatically as part of a {{glossary("continuous integration")}} setup.
 >
 > Usually library updates to the minor and patch version remain compatible.
 > We've prefixed each version with `^` above so that we can automatically update to the latest `minor.patch` version by running:
diff --git a/files/en-us/learn_web_development/extensions/testing/introduction/index.md b/files/en-us/learn_web_development/extensions/testing/introduction/index.md
@@ -130,7 +130,7 @@ Finally, you can get smarter with your testing using auditing or automation tool
 - see if a button click causes something to happen successfully (like for example, a map displaying), displaying the results once the tests are completed
 - take a screenshot of each, allowing you to see if a layout is consistent across the different browsers.
 
-If you wish to invest money in testing, there are also commercial tools that can automate much of the setup and testing for you (such as [Sauce Labs](https://saucelabs.com/) and [Browser Stack](https://www.browserstack.com/)). These kinds of tools usually enable a continuous integration workflow, where code changes are automatically tested before they are allowed to be submitted into your code repository.
+If you wish to invest money in testing, there are also commercial tools that can automate much of the setup and testing for you (such as [Sauce Labs](https://saucelabs.com/) and [Browser Stack](https://www.browserstack.com/)). These kinds of tools usually enable a {{glossary("continuous integration")}} workflow, where code changes are automatically tested before they are allowed to be submitted into your code repository.
 
 #### Testing on prerelease browsers
 
diff --git a/files/en-us/learn_web_development/extensions/testing/your_own_automation_environment/index.md b/files/en-us/learn_web_development/extensions/testing/your_own_automation_environment/index.md
@@ -795,7 +795,7 @@ So this is pretty cool. We have tested this locally, but you could set this up o
 
 ## Integrating Selenium with CI tools
 
-As another point, it is also possible to integrate Selenium and related tools like LambdaTest, and Sauce Labs with continuous integration (CI) tools — this is useful, as it means you can run your tests via a CI tool, and only commit new changes to your code repository if the tests pass.
+As another point, it is also possible to integrate Selenium and related tools like LambdaTest, and Sauce Labs with {{glossary("continuous integration")}} (CI) tools — this is useful, as it means you can run your tests via a CI tool, and only commit new changes to your code repository if the tests pass.
 
 It is out of scope to look at this area in detail in this article, but we'd suggest getting started with Travis CI — this is probably the easiest CI tool to get started with and has good integration with web tools like GitHub and Node.
 
diff --git a/files/en-us/learn_web_development/getting_started/environment_setup/command_line/index.md b/files/en-us/learn_web_development/getting_started/environment_setup/command_line/index.md
@@ -464,7 +464,7 @@ With Prettier there's a number of ways automation can be achieved and though the
 
 - Before you commit your code into a git repository using [Husky](https://github.com/typicode/husky).
 - Whenever you hit "save" in your code editor, be it [VS Code](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode), or [Sublime Text](https://packagecontrol.io/packages/JsPrettier).
-- As part of continuous integration checks using tools like [GitHub Actions](https://github.com/features/actions).
+- As part of {{glossary("continuous integration")}} checks using tools like [GitHub Actions](https://github.com/features/actions).
 
 Our personal preference is the second one — while using say VS Code, Prettier kicks in and cleans up any formatting it needs to do every time we hit save. You can find a lot more information about using Prettier in different ways in the [Prettier docs](https://prettier.io/docs/).
 
diff --git a/files/en-us/web/accessibility/guides/information_for_web_authors/index.md b/files/en-us/web/accessibility/guides/information_for_web_authors/index.md
@@ -41,7 +41,7 @@ Tools to integrate into your build process, programmatically adding accessibilit
 - [Lighthouse Audits](https://github.com/GoogleChrome/lighthouse/blob/main/docs/readme.md#using-programmatically)
 - [AccessLint.js](https://github.com/accesslint/accesslint.js/tree/master)
 
-Continuous integration tools to find accessibility issues in your GitHub pull requests:
+{{glossary("Continuous integration")}} tools to find accessibility issues in your GitHub pull requests:
 
 - [AccessLint](https://accesslint.com/)
 
diff --git a/files/en-us/web/api/publickeycredential/getclientcapabilities_static/index.md b/files/en-us/web/api/publickeycredential/getclientcapabilities_static/index.md
@@ -37,12 +37,12 @@ The WebAuthn client capability strings are:
   - : The client supports usage of the [hybrid](/en-US/docs/Web/API/AuthenticatorAttestationResponse/getTransports#hybrid) transport.
     This means that the client can use authenticators that rely on Bluetooth, NFC, or USB.
 - `"passkeyPlatformAuthenticator"`
-  - : The client allows usage of a passkey authenticator that supports multi-factor authentication mechanisms such as a PIN or biometric check.
+  - : The client allows usage of a passkey authenticator that supports {{glossary("multi-factor authentication")}} mechanisms such as a PIN or biometric check.
     The authenticator can be part of the same platform (device) as the client, or connected via a hybrid transport such as Bluetooth or USB.
     The credentials are stored on the authenticator.
     See [Passkeys developer guide for relying parties](https://developers.google.com/identity/passkeys/developer-guides).
 - `userVerifyingPlatformAuthenticator`
-  - : The client has a platform authenticator (part of the same device) that supports multi-factor authentication mechanisms, such as a PIN or biometric check.
+  - : The client has a platform authenticator (part of the same device) that supports {{glossary("multi-factor authentication")}} mechanisms, such as a PIN or biometric check.
     The credentials may be stored on either the RP or the authenticator.
 - `relatedOrigins`
   - : The client supports [Related Origin Requests](https://web.dev/articles/webauthn-related-origin-requests).
diff --git a/files/en-us/web/api/publickeycredential/isuserverifyingplatformauthenticatoravailable_static/index.md b/files/en-us/web/api/publickeycredential/isuserverifyingplatformauthenticatoravailable_static/index.md
@@ -10,7 +10,7 @@ browser-compat: api.PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvai
 
 The **`isUserVerifyingPlatformAuthenticatorAvailable()`** static method of the {{domxref("PublicKeyCredential")}} interface returns a {{jsxref("Promise")}} which resolves to `true` if a user-verifying platform authenticator is present.
 
-A user-verifying platform authenticator is a kind of multi-factor authenticator that is part of the client device (it is generally not removable) and that involves an action from the user in order to identify them. Common user-verifying platform authenticators include:
+A user-verifying platform authenticator is a kind of {{glossary("multi-factor authentication", "multi-factor authenticator")}} that is part of the client device (it is generally not removable) and that involves an action from the user in order to identify them. Common user-verifying platform authenticators include:
 
 - Touch ID or Face ID (macOS and iOS)
 - Windows Hello (Windows)
diff --git a/files/en-us/web/api/web_authentication_api/index.md b/files/en-us/web/api/web_authentication_api/index.md
@@ -7,11 +7,11 @@ browser-compat: api.PublicKeyCredential
 
 {{securecontext_header}}{{DefaultAPISidebar("Web Authentication API")}}
 
-The Web Authentication API (WebAuthn) is an extension of the [Credential Management API](/en-US/docs/Web/API/Credential_Management_API) that enables strong authentication with public key cryptography, enabling passwordless authentication and secure multi-factor authentication (MFA) without SMS texts.
+The Web Authentication API (WebAuthn) is an extension of the [Credential Management API](/en-US/docs/Web/API/Credential_Management_API) that enables strong authentication with public key cryptography, enabling passwordless authentication and secure {{glossary("multi-factor authentication")}} (MFA) without SMS texts.
 
 ## WebAuthn concepts and usage
 
-WebAuthn uses [asymmetric (public-key) cryptography](https://en.wikipedia.org/wiki/Public-key_cryptography) instead of passwords or SMS texts for registering, authenticating, and [multi-factor authentication](https://en.wikipedia.org/wiki/Multi-factor_authentication) with websites. This has some benefits:
+WebAuthn uses [asymmetric (public-key) cryptography](https://en.wikipedia.org/wiki/Public-key_cryptography) instead of passwords or SMS texts for registering, authenticating, and {{glossary("multi-factor authentication")}} with websites. This has some benefits:
 
 - **Protection against phishing:** An attacker who creates a fake login website can't login as the user because the signature changes with the [origin](/en-US/docs/Glossary/Origin) of the website.
 - **Reduced impact of data breaches:** Developers don't need to hash the public key, and if an attacker gets access to the public key used to verify the authentication, it can't authenticate because it needs the private key.
diff --git a/files/en-us/web/api/webotp_api/index.md b/files/en-us/web/api/webotp_api/index.md
@@ -23,7 +23,7 @@ Phone numbers are often used as a way to identify the user of an app. An SMS is
 
 OTP use cases include:
 
-- Improving sign-in security by using a phone number as an extra factor (i.e., for two-factor authentication (2FA) or multifactor authentication (MFA)).
+- Improving sign-in security by using a phone number as an extra factor as part of a {{glossary("multi-factor authentication")}} system.
 - Verifying sensitive actions such as payments.
 
 The WebOTP API allows web apps to expedite this validation process by copying the OTP from the SMS and passing it to the app automatically after the user has provided consent (most native platforms have an equivalent API).
diff --git a/files/en-us/web/performance/guides/performance_budgets/index.md b/files/en-us/web/performance/guides/performance_budgets/index.md
@@ -45,7 +45,7 @@ The ultimate value of a Performance Budget is to correlate the impact of Perform
 During development, there are a few tools to run checks against new or modified assets:
 
 - A module bundler (e.g., [webpack](https://webpack.js.org/)), has [performance features](https://webpack.js.org/configuration/performance/) that will notify you when assets exceed specified limits.
-- [Bundlesize](https://github.com/siddharthkp/bundlesize), allows you to define and run file size checks in your continuous integration (CI) pipeline.
+- [Bundlesize](https://github.com/siddharthkp/bundlesize), allows you to define and run file size checks in your {{glossary("continuous integration")}} (CI) pipeline.
 
 File size checks are the first line of defense against regressions but translating size back into time metrics can be difficult since development environments could be missing 3rd party scripts, and optimizations commonly provided by a [CDN](/en-US/docs/Glossary/CDN).
 
diff --git a/files/en-us/web/performance/guides/rum-vs-synthetic/index.md b/files/en-us/web/performance/guides/rum-vs-synthetic/index.md
@@ -16,7 +16,7 @@ An example of synthetic monitoring is [WebPageTest.org](https://www.webpagetest.
 
 Controlling for environmental variables is helpful in understanding where performance bottlenecks have been occurring and identifying the source of any performance issues. For example, but it isn't reflective of the actual experience of users, especially the long tail.
 
-Synthetic monitoring can be an important component of regression testing and production site monitoring. Test the site at every stage of development and regularly in production. Changes from baseline performance as part of continuous integration should fail a push. If an issue arises in production, synthetic monitoring can provide insight, helping identify, isolate, and resolve problems before they negatively user experience.
+Synthetic monitoring can be an important component of regression testing and production site monitoring. Test the site at every stage of development and regularly in production. Changes from baseline performance as part of {{glossary("continuous integration")}} should fail a push. If an issue arises in production, synthetic monitoring can provide insight, helping identify, isolate, and resolve problems before they negatively user experience.
 
 ## Real User Monitoring
 
diff --git a/files/en-us/web/privacy/index.md b/files/en-us/web/privacy/index.md
diff --git a/files/en-us/web/security/attacks/index.md b/files/en-us/web/security/attacks/index.md
diff --git a/files/en-us/web/security/attacks/supply_chain_attacks/index.md b/files/en-us/web/security/attacks/supply_chain_attacks/index.md
diff --git a/files/en-us/web/security/index.md b/files/en-us/web/security/index.md

Original file line number	Diff line number	Diff line change
`@@ -401,7 +401,7 @@ npm install`
`401`	`401`	```
`402`	`402`
`403`	`403`	`> [!NOTE]`
`404`		`-> It is a good idea to regularly update to the latest compatible versions of your dependency libraries — this may even be done automatically or semi-automatically as part of a continuous integration setup.`
	`404`	`+> It is a good idea to regularly update to the latest compatible versions of your dependency libraries — this may even be done automatically or semi-automatically as part of a {{glossary("continuous integration")}} setup.`
`405`	`405`	`>`
`406`	`406`	`> Usually library updates to the minor and patch version remain compatible.`
`407`	`407`	> We've prefixed each version with `^` above so that we can automatically update to the latest `minor.patch` version by running: