Improvements on hardening dev environment and downloading

Signed-off-by: David A. Wheeler <[email protected]>

Author: david-a-wheeler

secure_software_development_fundamentals.md

@@ -1222,7 +1222,7 @@ You also need to ensure that your system is not vulnerable to a “dependency co
 1. Use a single feed (e.g., a single repository or registry). If there’s a single source, there’s no opportunity for confusion.
 2. Clearly declare, for each package, where the package must be retrieved from. These are sometimes called “controlled scopes”.
 3. Prioritize feeds so that the most trusted feed(s) are always consulted first, and then less-trusted feeds are only consulted when the more trusted feeds expressly report that the package is not found. Make sure that the less-trusted feeds never override the more-trusted feeds.
-4. Use client-side verification features. One approach is to enforce version pinning to a cryptographic hash value (aka a “digital fingerprint”) of a package. Another approach is integrity verification to verify that a downloaded package is identical to the first time it was downloaded.
+4. Use client-side verification features. One approach is to enforce dependency pinning aka version pinning, that is, requiring that a specific known version be used. This can be enforced by requiring a specific cryptographic hash value (aka a “digital fingerprint”) of a package. Another approach is integrity verification to verify that a downloaded package is identical to the first time it was downloaded.
 
 🔔 Dependency confusion is a special case of 2021 CWE Top 25 #34, *Uncontrolled Search Path Element* ([CWE-427](https://cwe.mitre.org/data/definitions/427.html)). Relying on plugins, libraries, or modules from untrusted sources, and relying on untrustworthy content delivery networks, is considered part of 2021 OWASP Top 10 #8 (A08:2021), *Software and Data Integrity Failures*.
 
@@ -4566,7 +4566,7 @@ What is great about an assurance case is that if someone later wants to know “
 
 ### Harden the Development Environment (Including Build and CI/CD Pipeline) & Distribution Environment
 
-Most attacks occur when a system is deployed, but increasingly attackers are attacking systems during their development and distribution. For our purposes, the “development environment” includes the set of all machines and other infrastructure used to develop the software, including each developer’s systems, version control system(s), build systems, CI/CD pipelines, and so on.  The “distribution environment” is the environment used to distribute the resulting built software, e.g., package registries/repositories, container registries/repositories, and so on. It’s important to secure the development environment and distribution environment against unauthorized access or compromise. This includes protecting them against the insertion of malicious code. Assume that attackers are attempting to subvert any system used for software development and distribution, especially any shared systems.
+Most attacks occur when a system is deployed, but increasingly attackers are attacking systems during their development and distribution. For our purposes, the “development environment” includes the set of all machines and other infrastructure used to develop the software, including each developer’s systems, version control system(s), build systems, CI/CD pipelines, and so on.  The “distribution environment” is the environment used to distribute the resulting built software, e.g., package registries/repositories, container registries/repositories, and so on. It’s important to secure the development environment and distribution environment against unauthorized access or compromise. This includes protecting them against the insertion of malicious code. Assume that attackers are attempting to subvert any system used for software development or distribution, especially any shared systems.
 
 First, minimize privileges. Limit who can control these environments, and by how much. If someone leaves a project and/or organization, remove their privileges; even if they wouldn’t attack, an attacker might acquire their credentials.
 
@@ -4576,14 +4576,21 @@ Where practical, harden the development environment and distribution environment
 
 The build process should be fully scripted/automated. That way builds will be performed predictably each time. Where possible, the build system should provide provenance information, that is, record what components were included in the build and ideally what components were used to perform the build.
 
+Build, verification, and distribution processes (including CI/CD pipelines) often bring in many other reusable software components. Make sure you apply the good practices discussed in the course sections on (1) [Selecting Reusable Software](#selecting_reusable_software) and (2) [Downloading and Installing Reusable Software](#downloading_and_installing_reusable_software).
+
 Supply chain Levels for Software Artifacts, or SLSA (“salsa”), is a security framework being developed as a checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure. At the time of this writing it is still in development, but you should consider its recommendations. SLSA is being developed under the Open Source Security Foundation (OpenSSF). To learn more, see the SLSA home page at <https://slsa.dev/>.
 
-If an attacker manages to subvert the build process, the subverted results are often difficult to detect. A strong countermeasure to this attack is a verified reproducible build. A build is reproducible “if given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts” (as defined in [“Definitions” from the Reproducible Builds project](https://reproducible-builds.org/docs/definition/)). A reproducible build is also called a deterministic build. A verified reproducible build is simply a build that’s been independently verified to be a reproducible build. Verified reproducible builds make attacking the build process much harder, because the attacker must then subvert multiple independent build processes to succeed.
+If an attacker manages to subvert the build process, the subverted results are often difficult to detect. A strong countermeasure to this attack is a verified reproducible build. A build is reproducible “if given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts” (as defined in [“Definitions” from the Reproducible Builds project](https://reproducible-builds.org/docs/definition/)). A reproducible build is also called a deterministic build. A verified reproducible build is simply a build that’s been independently verified to be a reproducible build. Verified reproducible builds make attacking the build process much harder, because the attacker must then subvert multiple independent build systems to successfully subvert building the software.
+
+Many builds are reproducible without any changes, however, some are not. The first step in creating a reproducible build is often to verify that if you do the same build twice on the sam system it produces the same result (a *repeatable* build). Using a container image (like a Docker image) or virtual image for the environment can help create a consistent environment for performing reproducible builds. Here are some common challenges in creating reproducible builds:
+
+* The build result may include date/timestamps. If they can’t be easily removed, a common solution is to use the last modification of something (usually the source code) to set the date/timestamps in any result (using mechanisms such as the `SOURCE_DATE_EPOCH` environment variable).
+* Some values can be in an “arbitrary” order (e.g., due to parallel execution). A common solution is to sort the results (e.g., lexicographically).
 
-Many builds are reproducible without any changes, however, some are not. The first step in creating a reproducible build is often to verify that if you do the same build twice it produces the same result (a repeatable build). One common problem is that the build result may include date/timestamps; if they can’t be easily removed, a common solution is to use the last modification of something (usually the source code) to set the date/timestamp (using mechanisms such as the SOURCE_DATE_EPOCH environment variable). Another common problem is that some values can be in an “arbitrary” order (e.g., due to parallel execution); a common solution is to sort the results (e.g., lexicographically). More information on how to create reproducible builds is available; see [“Documentation” from the Reproducible Builds project](https://reproducible-builds.org/docs/).
+More information on how to create reproducible builds is available; see [“Documentation” from the Reproducible Builds project](https://reproducible-builds.org/docs/).
 
 😱 STORY TIME: Subversion of SolarWinds Orion’s Build System
-Orion is an enterprise network management software suite from SolarWinds that includes performance and application monitoring as well as network configuration management. In 2020 a threat actor intruded into its build system and modified it so that built versions of Orion would include malicious code. This subverted built system was then signed by the legitimate SolarWinds code signing certificate. This subversion was very damaging; the US government’s Cybersecurity & Infrastructure Security Agency (CISA) even issued an emergency directive (“[Emergency Directive 21-01]](https://www.cisa.gov/emergency-directive-21-01)” from CISA). Many security countermeasures couldn’t work in this case; “review code” didn’t work (the change was inserted by the build system and thus not seen by its developers), “check for signatures” didn’t work (it was legitimately signed), and monitoring for problems did not work for a while (because in many organizations this was the monitoring system). (For more information, see [Alert AA20-352A](https://www.cisa.gov/emergency-directive-21-01) from CISA and “[Preventing Supply Chain Attacks like SolarWinds](https://linuxfoundation.org/blog/preventing-supply-chain-attacks-like-solarwinds/)” by David A. Wheeler.)
+Orion is an enterprise network management software suite from SolarWinds that includes performance and application monitoring as well as network configuration management. In 2020 a threat actor modified the Orion build system so that built versions of Orion would include malicious code. This subverted built system was then signed by the legitimate SolarWinds code signing certificate. This subversion was very damaging; the US government’s Cybersecurity & Infrastructure Security Agency (CISA) even issued an emergency directive (“[Emergency Directive 21-01]](https://www.cisa.gov/emergency-directive-21-01)” from CISA). Many security countermeasures couldn’t work in this case; “review code” didn’t work (the change was inserted by the build system and thus not seen by its developers), “check for signatures” didn’t work (it was legitimately signed), and monitoring for problems did not work for a while (because in many organizations this was the monitoring system). For more information, see [Alert AA20-352A](https://www.cisa.gov/emergency-directive-21-01) from CISA and “[Preventing Supply Chain Attacks like SolarWinds](https://linuxfoundation.org/blog/preventing-supply-chain-attacks-like-solarwinds/)” by David A. Wheeler.
 
 🔔 Hardening the CI/CD pipeline against unauthorized access, malicious code, or system compromise is part of 2021 OWASP Top 10 #8 (A08:2021), *Software and Data Integrity Failures*.