Add links to 2021 OWASP Top 10 ossf#7

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

Author: david-a-wheeler

secure_software_development_fundamentals.md

@@ -1788,7 +1788,7 @@ You need to check whether or not a request is authorized in absolutely every cas
 
 Of course, if something requires authorization, that means there should first have been some kind of authentication to ensure that the request was from whom they claimed to be. Thoroughly check how you handle authentication, and where practical, use well-respected services, libraries, or frameworks to do it.
 
-🔔 Inadequate authentication is such a common mistake that *Broken Authentication* is 2017 OWASP Top 10 #2, 2021 CWE Top 25 #14, and 2019 CWE Top 25 #13. It is [CWE-287](https://cwe.mitre.org/data/definitions/287.html), *Improper Authentication*. *Missing Authentication for (specifically a) Critical Function* is 2021 CWE Top 25 #11 and 2019 CWE Top 25 #36 ([CWE-306](https://cwe.mitre.org/data/definitions/306.html)).
+🔔 2021 OWASP Top 10 #7 is *Identification and Authentication Failures*. Inadequate authentication is such a common mistake that *Broken Authentication* is 2017 OWASP Top 10 #2, 2021 CWE Top 25 #14, and 2019 CWE Top 25 #13. It is [CWE-287](https://cwe.mitre.org/data/definitions/287.html), *Improper Authentication*. *Missing Authentication for (specifically a) Critical Function* is 2021 CWE Top 25 #11 and 2019 CWE Top 25 #36 ([CWE-306](https://cwe.mitre.org/data/definitions/306.html)).
 
 We will later discuss various tools for verification. While tools can help find some problems, they are often *less* effective at finding authentication and authorization problems, because the tools don’t usually have enough information to determine *what is acceptable* and *what is not*. It helps to have tests that verify unauthorized requests are rejected, of course. But the most effective approach is ensuring that absolutely every input path is quickly authenticated and authorized where appropriate, so that manual review can easily assure reviewers that all cases are covered.
 
@@ -3616,7 +3616,9 @@ A tricky problem in testing is when a resource is not available. If the test req
 
 From a security perspective, it is important to include tests for security requirements. In particular, test both “what should happen” and “what should not happen”. Often people forget to test *what should not happen* (aka negative testing). For example, where it applies, you should have a test to check “Can I read/write *without* being authorized to do so?” (the answer should be “no”) and “Can I access the system with an *invalid* certificate or no certificate at all?” (again, that should fail). It is very common for programs’ security to fail because they don’t properly check for authentication (2017 OWASP Top 10 #2) or authorization (2017 OWASP Top 10 #5), so make sure you have tests for that!
 
-One approach to developing software is called t*est-driven development* (TDD). To over-summarize, in TDD the tests for a new capability are written before the software to implement the capability. This has some advantages, in particular, it encourages writing useful tests that actually check what they are supposed to check, and it also encourages developing testable software. One potential problem with TDD is that many TDD practitioners fail to write *negative* tests. Some TDD guidance even argues that you should only write tests for the new capability and nothing else. This is terrible guidance, because sometimes some things should simply *never* be allowed to happen, and you still need to test for them. You can definitely write secure software using TDD, but you must include negative tests (tests for what the software must *not* do) if you apply TDD.
+One approach to developing software is called *test-driven development* (TDD). To over-summarize, in TDD the tests for a new capability are written before the software to implement the capability. This has some advantages, in particular, it encourages writing useful tests that actually check what they are supposed to check, and it also encourages developing testable software. One potential problem with TDD is that many TDD practitioners fail to write *negative* tests. Some TDD guidance even argues that you should only write tests for the new capability and nothing else. This is terrible guidance, because sometimes some things should simply *never* be allowed to happen, and you still need to test for them. You can definitely write secure software using TDD, but you must include negative tests (tests for what the software must *not* do) if you apply TDD.
+
+🔔 2021 OWASP Top 10 #7 is *Identification and Authentication Failures*. Inadequate authentication is such a common mistake that *Broken Authentication* is 2017 OWASP Top 10 #2, 2021 CWE Top 25 #14, and 2019 CWE Top 25 #13. It is [CWE-287](https://cwe.mitre.org/data/definitions/287.html), *Improper Authentication*. *Missing Authentication for (specifically a) Critical Function* is 2021 CWE Top 25 #11 and 2019 CWE Top 25 #36 ([CWE-306](https://cwe.mitre.org/data/definitions/306.html)). *Broken Access Control* (including authorization failures) is 2017 OWASP Top 10 #5.
 
 #### Test Coverage