Be more specific about reproducible builds

Co-authored-by: Zyansheep <[email protected]>
Signed-off-by: Daniel Nathan Gray <[email protected]>

docs/basics/common-threats.md

@@ -78,7 +78,7 @@ There are few ways in which this type of attack might be carried out:
 These sorts of attacks can require a lot of time and preparation to perform and are risky because they can be detected, particularly in open source projects if they are popular and have outside interest. Unfortunately they're also one of the most dangerous as they are very hard to mitigate entirely. We would encourage readers only use software which has a good reputation and makes an effort to reduce risk by:
 
 1. Only adopting popular software that has been around for a while. The more interest in a project the, the greater likelihood that external parties will notice malicious changes. A malicious actor will also need to spend more time gaining community trust with meaningful contributions.
-2. Automated build infrastructure for released binary code reduces the attack surface such as, a compromised developer workstation or breached server. It provides accountability to others involved in the project in that binaries are produced from a central source code repository.
+2. Make sure software you use builds released binaries with widely-used, trusted build infrastructure platforms (i.e. GitHub workflows) as opposed to developer workstations or self-hosted servers. This is in order to reduce the attack surface and give confidence that the binaries produced are in fact produced correctly.
 3. Code signing on individual commits and releases increases an auditable trail of who did what. For example: Was the malicious code in the software repository? Which developer added it? Was it added during the build process?
 4. In open source projects the code should have commit messages which are explain exactly what the associated code does. This makes it easier for external parties to verify and detect if the code doesn't match the description.
 5. The number of contributors or maintainers, a lone developer may be more