diff --git a/docs/Concise-Guide-for-Developing-More-Secure-Software.md b/docs/Concise-Guide-for-Developing-More-Secure-Software.md
index 3ff6c553..0bab6320 100644
--- a/docs/Concise-Guide-for-Developing-More-Secure-Software.md
+++ b/docs/Concise-Guide-for-Developing-More-Secure-Software.md
@@ -33,6 +33,7 @@ Here is a concise guide for all software developers for secure software developm
 24. **Continuously improve**. Improve scores, look for tips, & apply as appropriate.
 25. **Manage succession**. Have clear governance & work to add active, trustworthy maintainer(s).
 26. **Prefer memory-safe languages**. Many vulnerabilities involve memory safety. Where practical, use memory-safe programming languages (most are) and keep memory safety enabled. Otherwise, use mechanisms like extra tools and peer review to reduce risk.
-27. **Ensure production websites only load assets from your own domains**. _Linking_ to other domains is fine, but where practical, don't directly load assets such as JavaScript, CSS, and media (including images) from domains you do not control. If you do, your site might be subverted if that other domain is subverted, so investigate the risks before doing so. See the [subverted polyfill.io revelation in 2024](https://blog.qualys.com/vulnerabilities-threat-research/2024/06/28/polyfill-io-supply-chain-attack).
+27. **If a source code (unbuilt) package is released, it should only include content from the version control system (VCS), and source package users should rebuild to create production (built) package(s)**. E.g., if autotools is used, if a source package is released it should _not_ include a generated `configure` file, while recipients should ignore pre-generated files like `configure` and instead rebuild from source (e.g., with `autoreconf`). This eliminates a malware-hiding mechanism, as illustrated by an attack on [xz utils](https://access.redhat.com/security/cve/CVE-2024-3094).
+28. **Ensure production websites only load assets from your own domains**. _Linking_ to other domains is fine, but where practical, don't directly load assets such as JavaScript, CSS, and media (including images) from domains you do not control. If you do, your site might be subverted if that other domain is subverted, so investigate the risks before doing so. See the [subverted polyfill.io revelation in 2024](https://blog.qualys.com/vulnerabilities-threat-research/2024/06/28/polyfill-io-supply-chain-attack).
 
 We welcome suggestions and updates! Please open an [issue](https://github.com/ossf/wg-best-practices-os-developers/issues/) or post a [pull request](https://github.com/ossf/wg-best-practices-os-developers/pulls).