Updates to Documentation criteria missing rationale and implementation details (#159)

* Updates to Documentation criteria missing rationale and implementation details

Signed-off-by: CRob <69357996+SecurityCRob@users.noreply.github.com>

* Update OSPS-DO.yaml

adjusted text to attempt to meet Evan's ask

Signed-off-by: CRob <69357996+SecurityCRob@users.noreply.github.com>

* Added OpenEoX lexicon entry and updated criteria

Signed-off-by: Eddie Knight <knight@linux.com>

* simplified DO-15 text

Signed-off-by: Eddie Knight <knight@linux.com>

---------

Signed-off-by: CRob <69357996+SecurityCRob@users.noreply.github.com>
Signed-off-by: Eddie Knight <knight@linux.com>
Co-authored-by: Eddie Knight <knight@linux.com>

Author: SecurityCRob

baseline/OSPS-DO.yaml

@@ -100,15 +100,17 @@ criteria:
       The project documentation MUST include a
       descriptive statement about the scope and
       duration of support.
-    rationale: # TODO
-    # TODO: Integrate with advice from https://endoflife.date/recommendations
+    rationale: |
+      Provide users with clear expecations regarding
+      the project's support lifecycle. This allows
+      downstream consumers to take relevant actions
+      to ensure the continued functionality and
+      security of their systems.
     implementation: |
-      The project should have either a "Support"
-      header in the README, a SUPPORT.md file
-      present in the repo root, or a SUPPORT.eox
-      file in the [OpenEOX format](https://github.com/OpenEoX/openeox/blob/main/schema/schema.json)
-      describing the scope and duration of support
-      for the project's released software assets.
+      In order to communicate the scope and duration of
+      support for the project's released software assets,
+      the project should have a SUPPORT.md or an OpenEoX
+      file in a well known location.
     control_mappings: 
       BPB: R-B-3
       SSDF: PO4.2, PS3.1, RV1.3 
@@ -121,10 +123,18 @@ criteria:
     criterion: |
       The project documentation MUST provide a
       descriptive statement when releases or
-      versions are no longer supported and that
-      will no longer receive security updates.
-    rationale: # TODO
-    implementation: # TODO
+      versions will no longer receive security
+      updates.
+    rationale: |
+      Communicating when the project maintainers
+      will no longer fix defects or security
+      vulnerabilities is crucial for downstream
+      consumers to find alternative solutions or
+      alternative means of support for the project.
+    implementation: |
+      While a machine-readable OpenEoX file is recommended,
+      this may also be communicated in a SUPPORT.md or
+      beneath a Support header in the primary README.md.
     control_mappings: 
       CRA: 1.2c, 2.6
       OC: 4.1.1, 4.3.1
@@ -133,13 +143,24 @@ criteria:
 
   - id: OSPS-DO-15
     maturity_level: 2
-    category: Vulnerability Management
+    category: Documentation
     criterion: |
       The project documentation MUST include a
       description of how the project selects,
       obtains, and tracks its dependencies.
-    rationale: # TODO
-    implementation: # TODO
+    rationale: |
+      Provide information about how the project
+      selects, obtains, and tracks dependencies, 
+      libraries, frameworks, etc. to help downstream 
+      consumers understand how the project operates
+      in regards to third-party components that are
+      required neccessary for the software to function.
+    implementation: |
+      It is recommended to publish this information
+      alongside the projects technical & design
+      documentation on a publicy viewable resource
+      such as the source code repository, project website, 
+      or other channel.
     control_mappings: 
       BPB: A-S-1
       CRA: 2.1

baseline/lexicon.yaml

@@ -138,6 +138,16 @@
     originally been intentional, but a change in
     environment or understanding has made them
     undesirable.
+- term: OpenEoX
+  definition: |
+    An initiative aimed at standardizing the way
+    End-of-Life and End-of-Support information is 
+    exchanged within the software and hardware industries.
+    Covering both vendors and open-source maintainers,
+    OpenEoX strives to provide a transparent, efficient, 
+    and unified approach to managing product lifecycles.
+  references:
+    - https://openeox.org/
 - term: Exploitable Vulnerabilities
   definition: |
     Defects in the software that can be leveraged