diff --git a/docs/basics/common-threats.md b/docs/basics/common-threats.md
index daeced24cb..7155300cb8 100644
--- a/docs/basics/common-threats.md
+++ b/docs/basics/common-threats.md
@@ -81,9 +81,7 @@ These sorts of attacks can require a lot of time and preparation to perform and
 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 audit, especially if the code doesn't match the description.
-5. The number of contributors or maintainers, a lone developer may be more
-susceptible to being coerced or forced into adding malicious code by an external party.
-6. Economical pressure that would occur if a company was involved with negligent behavior that enabled malicious code to be added. This may very well mean software developed by "Big Tech" has more scrutiny than a lone developer who doesn't answer to anyone.
+5. Noting the number of contributors or maintainers a program has. A lone developer may be more susceptible to being coerced into adding malicious code by an external party, or to negligently enable undesirable behavior. This may very well mean software developed by "Big Tech" has more scrutiny than a lone developer who doesn't answer to anyone.
 
 ## Privacy From Service Providers