Add citation to CNCF guidelines, see if others reviewed

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

Author: david-a-wheeler

secure_software_development_fundamentals.md

@@ -1165,7 +1165,9 @@ There are many important things to consider when selecting reusable software. Fo
 
     2. If the software has a license, make sure that its license is consistent with what you are trying to do. **Beware**: the costs of failing to abide by a license can be extremely steep. Be especially careful if the software is not released with an OSS license, since by definition you will have fewer rights, and in practice there will only be one supplier who will decide what information you can have and how it will change. Make sure you follow the license requirements. If you won’t follow the license requirements, you are not only at legal risk for using it, but you will generally not have the right to use its security updates either.
 
-8. If it is important, what is *your own evaluation* of it? If the software is important to you, and especially if it is OSS, you can download and examine it yourself. Some people are scared of doing this, but there is no reason to be afraid. Even a brief review of software source code, and its changes over time, can give you some insight into the software you are thinking about using. This can be time-consuming, so many will not do this. But if the software you are developing is very important, this is a step worth seriously considering. Doing a thorough evaluation of such software is outside the scope of this course. There are many organizations with expertise in doing code-level security audits for a fee; you may want to engage their services if you want an in-depth review. However, if you decide that you want to do just a brief review, here are things to consider:
+8. Has *someone else reviewed/audited it for security*? This is relatively rare but invaluable when it happens.
+
+9. If it is important, what is *your own evaluation* of it? If the software is important to you, and especially if it is OSS, you can download and examine it yourself. Some people are scared of doing this, but there is no reason to be afraid. Even a brief review of software source code, and its changes over time, can give you some insight into the software you are thinking about using. This can be time-consuming, so many will not do this. But if the software you are developing is very important, this is a step worth seriously considering. Doing a thorough evaluation of such software is outside the scope of this course. There are many organizations with expertise in doing code-level security audits for a fee; you may want to engage their services if you want an in-depth review. However, if you decide that you want to do just a brief review, here are things to consider:
 
     1. When you review the more detailed artifacts (e.g., the source code), is there evidence that the developers were trying to develop secure software (such as rigorous input validation of untrusted input and the use of prepared statements)?
 
@@ -4568,18 +4570,22 @@ What is great about an assurance case is that if someone later wants to know “
 
 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.
+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. Limit the privileges given the environments, for example, if a CI/CD pipeline is given an authentication token, provide a token with the minimum privileges necessary so that if the token is exposed the damage is reduced. If a token is only needed in some cases (such as only when processing certain branches like “main”), only provide the token in those cases.
 
 One simple approach is to have developers use multi-factor authentication (MFA) tokens (aka keys) when accessing development environments. These are hardware devices that prove that the developer possesses the device, and since they are single-purpose they are hard for attackers to subvert. If you must use passwords, ensure they are long and not shared between people.
 
+Consider using “branch protection” or similar, if your version control system supports it, to restrict operations that can occur on certain branches (such as “main”). For example, you can ensure that a merge request/pull request has received human review and that it has passed automated checks before the proposed change can be accepted. Protected branches can also prevent dangerous operations such as force pushes, overwrites of commit histories, and similar changes.
+
 Where practical, harden the development environment and distribution environment so they are harder to attack. In many projects, many or all parts of these environments are hosted elsewhere (often in a cloud); make sure the hosting system you choose has adequate security. Once chosen, consult the documentation for the systems you use and configure them to maximize security, e.g., to minimize privileges granted to others. For example, if you use GitHub, look at the [GitHub documentation on securing your repository](https://docs.github.com/en/code-security/getting-started/securing-your-repository). If you have a GitLab installation, [look at the GitLab documentation on securing your installation (“security”)](https://docs.gitlab.com/ee/security/).
 
-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.
+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. Be careful when logging a build process; often you want to avoid recording in log files any secrets like active authentication tokens.
 
 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/>.
 
+Another source for good ideas on hardening development environments against attack, as well as many other approaches for improving security, are in [Software Supply Chain Best Practices](https://github.com/cncf/tag-security/raw/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) from the Cloud Native Computing Foundation (CNCF).
+
 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:
@@ -4610,6 +4616,8 @@ When distributing:
 
 Note that our earlier discussion about software acquisition discussed distribution problems from the opposite side. That is, when acquiring software you want to ensure that you receive what you were supposed to receive, and when distributing software you want to make it easy for recipients to verify this.
 
+Again, consider the recommendations of Supply chain Levels for Software Artifacts, or SLSA (“salsa”), at <https://slsa.dev/>.
+
 When fielding/deploying:
 
 * Configure your production environment to be secure, including all components you depend on, and keep it updated. For example:
@@ -5183,6 +5191,8 @@ Many others discuss how to develop secure software. This course merely covers th
 
 * OWASP Secure Coding Practices-Quick Reference Guide <https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/migrated_content>
 
+* [Software Supply Chain Best Practices](https://github.com/cncf/tag-security/raw/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) from the Cloud Native Computing Foundation (CNCF)
+
 # Old Mappings
 
 ## OWASP Top 10 and CWE Top 25