Enhance security guidelines for software supply chain #486

#387 by @JustinCappos has raised good discussion around the difference between assessing the elements a project has authored, and the elements they have imported as dependencies. There is some nuance to how these objectives might be phrased, as noted by David below.

The goals are sensible, but this needs more specifics. What exactly are we expecting people to do? How will they know when they're done? What are the specific examples of the risks you intend to tackle? E.g.: typosquatting, dependency confusion, malicious GitHub Actions, malicious packages, etc.

We discussed this today, and the plan is to open a new issue to discuss this in more detail and work out more specific to address this.

Originally posted by @david-a-wheeler in #387 (comment)

Related existing controls:

DO-06 Publish Dependency Management Policy
BR-05 Use Standardized Dependency Management Tools
QA-02 Publish Software Dependencies
BR-01 Prevent Untrusted Input When Building & Releasing
AC-04 Enforce Least Privilege on CI/CD Pipelines
VM-05 Publish and Enforce a Dependency Remediation Policy
QA-05 Prevent Executables in the Codebase
QA-06 Use Automated Testing in CI/CD Pipelines

Originally posted by @evankanderson in #387 (comment)

TODO

• Establish a consensus in this issue regarding the current and proposed control objectives
• Propose new control objectives in a new PR, with draft assessment requirements
• Refine the specific test requirements to ensure they meet the intent of their respective objectives
• Gather community feedback on the PR