Update docs/Concise-Guide-for-Developing-More-Secure-Software.md

Co-authored-by: j-k <[email protected]>
Signed-off-by: David A. Wheeler <[email protected]>

docs/Concise-Guide-for-Developing-More-Secure-Software.md

@@ -35,6 +35,5 @@ Here is a concise guide for all software developers for secure software developm
 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. **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).
 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).
->>>>>>> 093b41f3f1db32b9ea1e8f67f612768428578713
 
 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).