Enhancement of SA rationales and implementation details (#166)

* Enhancement of SA rationales and implementation details <title> Signed-off-by: CRob <[email protected]> * Update baseline/OSPS-SA.yaml Co-authored-by: Puerco <[email protected]> Signed-off-by: CRob <[email protected]> * Update baseline/OSPS-SA.yaml Co-authored-by: Puerco <[email protected]> Signed-off-by: CRob <[email protected]> * Moved some content into lexicon entries Signed-off-by: Eddie Knight <[email protected]> * Update baseline/OSPS-SA.yaml Co-authored-by: Ben Cotton <[email protected]> Signed-off-by: CRob <[email protected]> --------- Signed-off-by: CRob <[email protected]> Signed-off-by: Eddie Knight <[email protected]> Co-authored-by: Puerco <[email protected]> Co-authored-by: Eddie Knight <[email protected]> Co-authored-by: Ben Cotton <[email protected]>
ossf · Jan 28, 2025 · db0dc7c · db0dc7c
1 parent 9ae5930
commit db0dc7c
Show file tree

Hide file tree

Showing 2 changed files with 76 additions and 4 deletions.
diff --git a/baseline/OSPS-SA.yaml b/baseline/OSPS-SA.yaml
@@ -71,8 +71,26 @@ criteria:
       protect against attacks on critical code
       paths, functions, and interactions within
       the system.
-    rationale: # TODO
-    implementation: # TODO
+    rationale: |
+      Provides project maintainers an understanding of how
+      the software can be misused or broken allows them
+      to plan mitigations to close off the potential of 
+      those threats from occuring.
+
+      Providing downstream consumers with this threat model
+      can assist them in understanding the security capabilities
+      or gaps that exist within the project and allows them 
+      to apply their own additional controls and mitigations.
+    implementation: |
+      Threat modeling is an activity where the project
+      looks at the codebase, associated processes and 
+      infrastructure, interfaces, key components and 
+      "thinks like a hacker" and brainstorms how the 
+      system be be broken or compromised.
+
+      Each identified threat is listed out so the project
+      can then think about how to proactively avoid or 
+      close off any gaps/vulnerabilities that could arise.
     control_mappings: 
       BPB: B-S-8
       CRA: 1.2j, 1.2k
@@ -89,8 +107,29 @@ criteria:
         assessment to understand the most likely and
         impactful potential security problems that
         could occur within the software.
-    rationale: # TODO
-    implementation: # TODO
+    rationale: |
+      Performing a security assessment informs both project 
+      members as well as downstream consumers that the 
+      project understands what problems could arise within
+      the software.
+
+      Understanding what threats could be realized helps
+      the project manage and address risk.  This information
+      is useful to downstream consumers to demonstrate
+      the security accumen and practices of the project.
+    implementation: |
+      Security assessments can take many forms in a spectrum
+      ranging from informal to highly rigourous.  At its most 
+      basic, a security assessment lists potential threats, 
+      estimates the likelihood/probability of those threats
+      occuring and the the possible consquences/impact if those
+      threats do occur.
+
+      Software that is deployed into highly-regulated spaces
+      would benefit from more formal risk management practices
+      such as [NIST SP 800-171](https://csrc.nist.gov/projects/risk-management/about-rmf), 
+      [ENISA's Risk Management Framework](https://www.enisa.europa.eu/topics/risk-management), 
+      or a methodolgy such as [OpenFAIR](https://www.opengroup.org/open-fair).
     control_mappings: 
       BPB: B-W-8, S-G-1
       CRA: 1.1, 2.2

diff --git a/baseline/lexicon.yaml b/baseline/lexicon.yaml
@@ -13,6 +13,18 @@
     Code provided by an external source that is
     executed by a system without validation or
     restriction.
+- term: Attack Surface Analysis
+  definition: |
+    Attack Surface Analysis is about mapping out what parts of a system need to
+    be reviewed and tested for security vulnerabilities. The point of Attack
+    Surface Analysis is to understand the risk areas in an application, to make
+    developers and security specialists aware of what parts of the application
+    are open to attack, to find ways of minimizing this, and to notice when and
+    how the Attack Surface changes and what this means from a risk perspective.
+    
+    See OWASP's Attack Surface Analysis Cheat Sheet for more information.
+  references:
+    - https://cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.html
 - term: Automated Test Suite
   definition: |
     A collection of pre-written test cases that, when invoked,
@@ -228,6 +240,27 @@
     maintained in a separate repository.
     Subprojects may be compiled into the primary
     project or used as standalone components.
+- term: Threat Modeling
+  definition: |
+    Threat modeling is an activity where the project
+    looks at the codebase, associated processes and 
+    infrastructure, interfaces, key components and 
+    "thinks like a hacker" to brainstorm how the 
+    system be be broken or compromised.
+
+    Each identified threat is listed out so the project
+    can then think about how to proactively avoid or 
+    close off any gaps/vulnerabilities that could arise.
+
+    Examples of threat modeling methodologies include
+    the Shostack "4 Questions" model, STRIDE, and
+    tools such as the Elevation of Privilege Threat
+    Modeling Card Game or Threat Dragon.
+  references:
+    - https://github.com/adamshostack/4QuestionFrame
+    - https://owasp.org/www-community/Threat_Modeling_Process
+    - https://www.microsoft.com/en-us/download/details.aspx?id=20303
+    - https://owasp.org/www-project-threat-dragon
 - term: Version Identifier
   definition: |
     A label assigned to a specific release of the