Fix markdownlint warnings

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

Author: david-a-wheeler

.github/linters/.markdown-lint.yml

@@ -10,6 +10,9 @@ MD049: false # MD049/emphasis-style
 MD012: false # MD012/no-multiple-blank
 MD001: false # MD001/heading-increment/header-increment
 
+# For the moment, disable
+MD024: false # MD024/no-duplicate-heading/no-duplicate-header
+
 # We enforce "no duplicate headers" so hypertext links to sections will have
 # unique anchor names to refer to.
 # MD024: false # MD024/no-duplicate-heading/no-duplicate-header

secure_software_development_fundamentals.md

@@ -2083,7 +2083,7 @@ If it matters, make sure you process your data by using an environment you can t
 
 Which leads us to a useful rule-of-thumb: *whenever given a choice, try to use the more trusted data.*
 
-An example might help. Many systems, when sent a password reset request, send an email to confirm the password reset. At one time GitHub would ask an untrusted user for their email address. If that matched an email address in their database, ignoring upper/lower case distinctions using the rules of English, GitHub would send the password reset to the email address *as provided by the attacker*. This was a terrible idea. Email standards do not guarantee that the local part of the email address (the part before the **@** symbol) is case insensitive (see [IETF RFC 5321 section 2.3.11](https://tools.ietf.org/html/rfc5321#section-2.3.11)). By converting the email address to lower case, there is no guarantee that the reset would be sent to the correct email address. Many email systems do ignore upper/lower case distinctions, but they might not use English! In some Turkic email systems, the local part of the email address would normalize to a *different* distinct email account than the original account. For example, **[email protected]** would normalize to **mı[email protected]** (using a dotless i), which would be a different email account from **[email protected]** (which uses a dotted i). This led to an exploitable vulnerability (GitHub Security, [*Password reset emails delivered to the wrong address*](https://bounty.github.com/researchers/jagracey.html), 2016).
+An example might help. Many systems, when sent a password reset request, send an email to confirm the password reset. At one time GitHub would ask an untrusted user for their email address. If that matched an email address in their database, ignoring upper/lower case distinctions using the rules of English, GitHub would send the password reset to the email address *as provided by the attacker*. This was a terrible idea. Email standards do not guarantee that the local part of the email address (the part before the **@** symbol) is case insensitive (see [IETF RFC 5321 section 2.3.11](https://tools.ietf.org/html/rfc5321#section-2.3.11)). By converting the email address to lower case, there is no guarantee that the reset would be sent to the correct email address. Many email systems do ignore upper/lower case distinctions, but they might not use English! In some Turkic email systems, the local part of the email address would normalize to a *different* distinct email account than the original account. For example, **MIKE@example.org** would normalize to **mıke@example.org** (using a dotless i), which would be a different email account from **mike@example.org** (which uses a dotted i). This led to an exploitable vulnerability (GitHub Security, [*Password reset emails delivered to the wrong address*](https://bounty.github.com/researchers/jagracey.html), 2016).
 
 This attack seems subtle, but this is a clear violation of our basic rule of thumb: if you have more trusted data available, try to use *that* more trusted data! For example, if you have a password reset request, and you want to send an email to confirm that the originally-confirmed user authorized it, you should send the reset email to exactly the *already confirmed* email address in your database. You have already confirmed that is the correct email address, so you can place more trust in it. This simple rule - *try to use the more trusted data* -  will avoid many subtle attacks without you even realizing it.
 
@@ -4894,7 +4894,7 @@ You must tell others, publicly, how to send vulnerability reports… and this in
 
 In one sense this requirement is easy. Decide what your reporting convention is, and make that information easy to find. Here are some common conventions:
 
-1. Many companies and projects support an email address of the form **security@example.com** or **abuse@example.com**.
+1. Many companies and projects support an email address of the form **security@example.com** or **abuse@example.com**.
 
 2. A common convention in OSS projects is to provide this information in a file named **SECURITY.md** in the repository’s root or **docs/** directory. Sites such as GitHub will highlight this file if present and encourage their creation. Add a link from your **README.md** file to this **SECURITY.md** file.
 

toc.md

@@ -1,3 +1,307 @@
+# secure-sw-dev-fundamentals: Secure Software Development Fundamentals courses (from the OpenSSF Best Practices WG)
+
+## Highlights
+
+## Details
+
+# SECURITY
+
+# Part I: Requirements, Design, and Reuse
+
+# Course Introduction
+
+## Introduction
+
+## A Note from the Author
+
+## Motivation
+
+### Motivation: Why Is It Important to Secure Software?
+
+### Motivation: Why Take This course?
+
+# Security Basics
+
+## What Do We Need?
+
+### What Does “Security” Mean?
+
+### Security Requirements
+
+### What Is Privacy and Why It Is Important
+
+### Privacy Requirements
+
+## How Can We Get There?
+
+### Risk Management
+
+### Development Processes / Defense-in-Breadth
+
+### Protect, Detect, Respond
+
+### Vulnerabilities
+
+# Design
+
+## Secure Design Basics
+
+### What Are Security Design Principles?
+
+### Widely-Recommended Secure Design Principles
+
+### Least Privilege
+
+### Complete Mediation (Non-Bypassability)
+
+### The Rest of the Saltzer & Schroeder Design Principles
+
+### Other Design Principles
+
+# Reusing External Software
+
+## Supply Chain
+
+### Basics of Reusing Software
+
+### Selecting (Evaluating) Open Source Software
+
+### Downloading and Installing Reusable Software
+
+### Updating Reused Software
+
+# Part II: Implementation
+
+# Basics of Implementation
+
+### Implementation Overview
+
+# Input Validation
+
+## Input Validation Basics
+
+### Input Validation Basics Introduction
+
+### How Do You Validate Input?
+
+## Input Validation: Numbers and Text
+
+### Input Validation: A Few Simple Data Types
+
+### Sidequest: Text, Unicode, and Locales
+
+### Validating Text
+
+### Introduction to Regular Expressions
+
+### Using Regular Expressions for Text Input Validation
+
+### Countering ReDoS Attacks on Regular Expressions
+
+## Input Validation: Beyond Numbers and Text
+
+### Insecure Deserialization
+
+### Input Data Structures (XML, HTML, CSV, JSON, & File Uploads)
+
+### Minimizing Attack Surface, Identification, Authentication, and Authorization
+
+### Search Paths and Environment Variables (including setuid/setgid Programs)
+
+### Special Inputs: Secure Defaults and Secure Startup
+
+## Consider Availability on All Inputs
+
+### Consider Availability on All Inputs Introduction
+
+# Processing Data Securely
+
+## Processing Data Securely: General Issues
+
+### Prefer Trusted Data. Treat Untrusted Data as Dangerous
+
+### Avoid Default & Hardcoded Credentials
+
+### Avoid Incorrect Conversion or Cast
+
+## Processing Data Securely: Undefined Behavior / Memory Safety
+
+### Countering Out-of-Bounds Reads and Writes (Buffer Overflow)
+
+### Double-free, Use-after-free, and Missing Release
+
+### Avoid Undefined Behavior
+
+## Processing Data Securely: Calculate Correctly
+
+### Avoid Integer Overflow, Wraparound, and Underflow
+
+# Calling Other Programs
+
+## Introduction to Securely Calling Programs
+
+### Introduction to Securely Calling Programs - The Basics
+
+## Calling Other Programs: Injection and Filenames
+
+### SQL Injection Vulnerability
+
+### SQL Injection: Parameterized Statements
+
+### SQL Injection: DBMS (Server) side vs. Application (client) side
+
+### SQL Injection: Alternatives to Parameterized Statements
+
+### OS Command (Shell) injection
+
+### Other Injection Attacks
+
+### Filenames (Including Path Traversal and Link Following)
+
+## Calling Other Programs: Other Issues
+
+### Call APIs for Programs and Check What Is Returned
+
+### Handling Errors
+
+### Logging
+
+### Debug and Assertion Code
+
+### Countering Denial-of-Service (DoS) Attacks
+
+# Sending Output
+
+### Introduction to Sending Output
+
+### Countering Cross-Site Scripting (XSS)
+
+### Content Security Policy (CSP)
+
+### Other HTTP Hardening Headers
+
+### Cookies & Login Sessions
+
+### CSRF / XSRF
+
+### Open Redirects and Forwards
+
+### HTML **target** and JavaScript **window.open()**
+
+### Using Inadequately Checked URLs / Server-Side Request Forgery (SSRF)
+
+### Same-Origin Policy and Cross-Origin Resource Sharing (CORS)
+
+### Format Strings and Templates
+
+### Minimize Feedback / Information Exposure
+
+### Avoid caching sensitive information
+
+### Side-Channel Attacks
+
+# Part III: Verification and More Specialized Topics
+
+# Verification
+
+## Basics of Verification
+
+### Verification Overview
+
+## Static Analysis
+
+### Static Analysis Overview
+
+### Software Composition Analysis (SCA)/Dependency Analysis
+
+## Dynamic Analysis
+
+### Dynamic Analysis Overview
+
+### Fuzz Testing
+
+### Web Application Scanners
+
+## Other Verification Topics
+
+### Combining Verification Approaches
+
+# Threat Modeling
+
+## Threat Modeling/Attack Modeling
+
+### Introduction to Threat Modeling
+
+### STRIDE
+
+# Cryptography
+
+## Applying Cryptography
+
+### Introduction to Cryptography
+
+### Symmetric/Shared Key Encryption Algorithms
+
+### Cryptographic Hashes (Digital Fingerprints)
+
+### Public-Key (Asymmetric) Cryptography
+
+### Cryptographically Secure Pseudo-Random Number Generator (CSPRNG)
+
+### Storing Passwords
+
+### Transport Layer Security (TLS)
+
+### Other Topics in Cryptography
+
+# Other Topics
+
+## Vulnerability Disclosures
+
+### Receiving Vulnerability Reports
+
+### Respond To and Fix the Vulnerability in a Timely Way
+
+### Sending Vulnerability Reports to Others
+
+## Miscellaneous
+
+### Assurance Cases
+
+### Harden the Development Environment (Including Build and CI/CD Pipeline) & Distribution Environment
+
+### Distributing, Fielding/Deploying, Operations, and Disposal
+
+### Artificial Intelligence (AI), Machine Learning (ML), and Security
+
+### Formal Methods
+
+## Top Vulnerability Lists
+
+### OWASP Top 10
+
+### CWE Top 25
+
+## Concluding Notes
+
+### Conclusions
+
+# Part IV: Supporting Materials Not Part of the Course
+
+# Glossary
+
+# Further Reading
+
+# Old Mappings
+
+## OWASP Top 10 and CWE Top 25
+
+### OWASP Top 10 (2017 edition)
+
+### CWE Top 25 (2019 edition)
+
+# References
+
 # Part I: Requirements, Design, and Reuse
 
 # Course Introduction