diff --git a/docs/Concise-Guide-for-Developing-More-Secure-Software.md b/docs/Concise-Guide-for-Developing-More-Secure-Software.md
index 862d76d7..c1ad37de 100644
--- a/docs/Concise-Guide-for-Developing-More-Secure-Software.md
+++ b/docs/Concise-Guide-for-Developing-More-Secure-Software.md
@@ -33,6 +33,6 @@ 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 source packages have only version-controlled source, and rebuild all source to create production package(s)**. E.g., if you use autotools, don't include a generated `configure` file in a source package, but instead ask recipients to build it (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).
+27. **If a source code (unbuilt) package is released, it should only include version-controlled source, and users should rebuild its contents 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 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).
 
 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).