feat: use the SCI layer2 module for the cmd CLI

.gitignore

@@ -1,2 +1,5 @@
 docs/versions/devel.md
 .DS_Store
+
+# generated output from go run ./... compile
+checklist.md

README.md

@@ -2,29 +2,26 @@
 
 The Open Source Project Security Baseline (OSPS Baseline) is designed to act as a minimum definition of requirements for a project relative to its maturity level.
 
-All definitions are maintained in YAML format for tandem machine and human readability.
+All definitions are maintained in YAML format using the [Simplified Compliance Infrastructure Layer 2 schema](https://github.com/revanite-io/sci?tab=readme-ov-file#layer-2-controls) for tandem machine and human readability.
 
 ## Baseline Structure
 
-Each entry has the following values:
-
-- **ID**:
-  - Entries are of the form OSPS-_Category_-_Index_ where
-    - *Category* is a two-letter abbreviated form of the categories listed below
-    - *Index* is a sequentially-assigned two-digit number. Numbers are unique within a category but not between categories
-- **Maturity Level**:
-  - Level 1: for any code or non-code project with any number of maintainers or users
-  - Level 2: for any code project that has at least 2 maintainers and a small number of consistent users
-  - Level 3: for any code project that has a large number of consistent users
-- **Family** (see corresponding yaml files for descriptions):
-  - [Access Control](baseline/OSPS-AC.yaml)
-  - [Build & Release](baseline/OSPS-BR.yaml)
-  - [Documentation](baseline/OSPS-DO.yaml)
-  - [Governance](baseline/OSPS-GV.yaml)
-  - [Legal](baseline/OSPS-LE.yaml)
-  - [Quality](baseline/OSPS-QA.yaml)
-  - [Security Assessment](baseline/OSPS-SA.yaml)
-  - [Vulnerability Management](baseline/OSPS-VM.yaml)
+The baseline is a set of Control Families where each Family has a set of Controls.
+
+- [Access Control](baseline/OSPS-AC.yaml)
+- [Build & Release](baseline/OSPS-BR.yaml)
+- [Documentation](baseline/OSPS-DO.yaml)
+- [Governance](baseline/OSPS-GV.yaml)
+- [Legal](baseline/OSPS-LE.yaml)
+- [Quality](baseline/OSPS-QA.yaml)
+- [Security Assessment](baseline/OSPS-SA.yaml)
+- [Vulnerability Management](baseline/OSPS-VM.yaml)
+
+Controls are identified by an ID in the format: `OSPS-${ControlFamilyAbbreviated}`.
+For example, Control ID: `OSPS-AC-01` refers to the Access Control (AC) control family.
+
+Controls are described with these attributes:
+
 - **Title**:
   - A concise statement of the requirement
   - Contains `MUST` or `MUST NOT` and is written in present tense
@@ -33,10 +30,29 @@ Each entry has the following values:
 - **Objective**:
   - A concise statement of the goal of the requirement
   - Written in present tense and describes the desired outcome
-- **Assessment requirement(s)**:
-  - A concise description of how to meet the requirement
+
+Each Control has 1 or more Assessment Requirements. These requirements are
+identified by an ID in the format `OSPS-${ControlFamilyAbbreviated}-${IndexWithinControlFamily}`.
+For example, `OSPS-AC-01.01` refers to the first
+Assessment Requirement in the first Control of the Access Control Family:
+
+> When a user attempts to access a sensitive resource in the project's
+  version control system, the system MUST require the user to complete
+  a multi-factor authentication process.
+
+Each Assessment Requirement has:
+
+- **Text**:
+  - A concise statement of the requirement
+  - Contains `MUST` or `MUST NOT` and is written in present tense
+  - The term before `MUST/NOT` is the subject of the requirement
+  - Terms following `MUST/NOT` describe the required behavior
+- **Recommendation**:
+  - description of how to meet the requirement
   - Written in present tense and describes the steps to take to meet the requirement
-  - May outline recommendations, examples, or best practices
+  - May provide examples and reference best practices
+- **Applicability**:
+  - One or more project maturity levels to which the assessment requirement applies
 
 ## baseline-compiler
 

baseline/OSPS-AC.yaml

@@ -1,4 +1,4 @@
-category: Access Control
+title: Access Control
 description: |
   Access Control focuses on the mechanisms and
   policies that control access to the project's version
@@ -16,7 +16,6 @@ controls:
       Reduce the risk of account compromise or insider threats by requiring
       multi-factor authentication for collaborators modifying the project
       repository settings or accessing sensitive data.
-    family: Access Control
     mappings:
       - reference-id: BPB
         identifiers:
@@ -82,7 +81,6 @@ controls:
     objective: |
       Reduce the risk of unauthorized access to the project's repository by
       limiting the permissions granted to new collaborators.
-    family: Access Control
     mappings:
       - reference-id: CRA
         identifiers:
@@ -135,7 +133,6 @@ controls:
     objective: |
       Reduce the risk of accidental changes or deletion of the primary branch
       of the project's repository by preventing unintentional modification.
-    family: Access Control
     mappings:
       - reference-id: CRA
         identifiers:
@@ -202,7 +199,6 @@ controls:
       Reduce the risk of unauthorized access to the project's build and release
       processes by limiting the permissions granted to steps within the CI/CD
       pipelines.
-    family: Access Control
     mappings:
       - reference-id: CRA
         identifiers:

baseline/OSPS-BR.yaml

@@ -1,4 +1,4 @@
-category: Build and Release
+title: Build and Release
 description: |
   Build and Release focuses on the processes and
   tools used to compile, package, and distribute the
@@ -16,7 +16,6 @@ controls:
       Reduce the risk of code injection or other security vulnerabilities in the
       project's build and release pipelines by preventing untrusted input from
       accessing privileged resources.
-    family: Build and Release
     mappings:
       - reference-id: CRA
         identifiers:
@@ -79,7 +78,6 @@ controls:
       Ensure that each software asset produced by the project is uniquely
       identified, enabling users to track changes and updates to the project
       over time.
-    family: Build and Release
     mappings:
       - reference-id: BPB
         identifiers:
@@ -142,7 +140,6 @@ controls:
     objective: |
       Protect the confidentiality and integrity of project source code during
       development, reducing the risk of eavesdropping or data tampering.
-    family: Build and Release
     mappings:
       - reference-id: BPB
         identifiers:
@@ -218,7 +215,6 @@ controls:
       Provide transparency and accountability for changes made to the project's
       software releases, enabling users to understand the modifications and
       improvements included in each release.
-    family: Build and Release
     mappings:
       - reference-id: BPB
         identifiers:
@@ -297,7 +293,6 @@ controls:
       Ensure that the project's build and release pipelines use standardized tools
       and processes to manage dependencies, reducing the risk of compatibility
       issues or security vulnerabilities in the software.
-    family: Build and Release
     mappings:
       - reference-id: BPB
         identifiers:
@@ -361,7 +356,6 @@ controls:
     objective: |
       All released software assets MUST be signed or accounted for in a
       signed manifest including each asset's cryptographic hashes.
-    family: Build and Release
     mappings:
       - reference-id: SSDF
         identifiers:

baseline/OSPS-DO.yaml

@@ -1,4 +1,4 @@
-category: Documentation
+title: Documentation
 description: |
   Documentation focuses on the information
   provided to users, contributors, and maintainers
@@ -16,7 +16,6 @@ controls:
       Ensure that users have a clear and comprehensive understanding of the
       project's current features in order to prevent damage from misuse or
       misconfiguration.
-    family: Documentation
     mappings:
       - reference-id: BPB
         identifiers:
@@ -81,7 +80,6 @@ controls:
       Enable users and contributors to report defects or issues with the
       released software assets, facilitating communication and collaboration on
       defect fixes and improvements.
-    family: Documentation
     mappings:
       - reference-id: BPB
         identifiers:
@@ -148,7 +146,6 @@ controls:
       Enable users to verify the authenticity and integrity of the project's
       released software assets, reducing the risk of using tampered or
       unauthorized versions of the software.
-    family: Documentation
     mappings:
       - reference-id: BPB
         identifiers:
@@ -225,7 +222,6 @@ controls:
       Provide users with clear expectations regarding the project's support
       lifecycle. This allows downstream consumers to take relevant actions to
       ensure the continued functionality and security of their systems.
-    family: Documentation
     mappings:
       - reference-id: BPB
         identifiers:
@@ -282,7 +278,6 @@ controls:
       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.
-    family: Documentation
     mappings:
       - reference-id: CRA
         identifiers:
@@ -336,7 +331,6 @@ controls:
       dependencies, libraries, frameworks, etc. to help downstream consumers
       understand how the project operates in regards to third-party components
       that are required necessary for the software to function.
-    family: Documentation
     mappings:
       - reference-id: BPB
         identifiers:

baseline/OSPS-GV.yaml

@@ -1,4 +1,4 @@
-category: Governance
+title: Governance
 description: |
   Governance focuses on the policies and
   procedures that guide the project's decision-making
@@ -15,7 +15,6 @@ controls:
       potential contributors, and downstream consumers have an accurate
       understanding of who is working on the project and what areas of authority
       they may have.
-    family: Governance
     mappings:
       - reference-id: BPB
         identifiers:
@@ -83,7 +82,6 @@ controls:
       Encourages open communication and collaboration within the project
       community, enabling users to provide feedback and discuss proposed changes
       or usage challenges.
-    family: Governance
     mappings:
       - reference-id: BPB
         identifiers:
@@ -124,7 +122,6 @@ controls:
       Provide guidance to new contributors on how to participate in the project,
       outlining the steps required to submit changes or enhancements to the
       project's codebase.
-    family: Governance
     mappings:
       - reference-id: BPB
         identifiers:
@@ -189,7 +186,6 @@ controls:
       Ensure that code contributors are vetted and reviewed before being granted
       elevated permissions to sensitive resources within the project, reducing
       the risk of unauthorized access or misuse.
-    family: Governance
     mappings:
       - reference-id: BPB
         identifiers:

baseline/OSPS-LE.yaml

@@ -1,4 +1,4 @@
-category: Legal
+title: Legal
 description: |
   Legal focuses on the policies and
   procedures that govern the project's licensing
@@ -18,7 +18,6 @@ controls:
       Ensure that code contributors are aware of and acknowledge their legal
       responsibility for the contributions they make to the project, reducing
       the risk of intellectual property disputes against the project.
-    family: Legal
     mappings:
       - reference-id: BPB
         identifiers:
@@ -64,7 +63,6 @@ controls:
       Ensure that the project's source code is distributed under a recognized
       and legally enforceable open source software license, providing clarity on
       how the code can be used and shared by others.
-    family: Legal
     mappings:
       - reference-id: BPB
         identifiers:
@@ -130,7 +128,6 @@ controls:
       Ensure that the project's source code and released software assets are
       distributed with the appropriate license terms, making it clear to users
       and contributors how each can be used and shared.
-    family: Legal
     mappings:
       - reference-id: BPB
         identifiers:

baseline/OSPS-QA.yaml

@@ -1,4 +1,4 @@
-category: Quality
+title: Quality
 description: |
   Quality focuses on the processes and
   practices used to ensure the quality and
@@ -16,7 +16,6 @@ controls:
     objective: |
       Enable users to access and review the project's source code and history,
       promoting transparency and collaboration within the project community.
-    family: Quality Assurance
     mappings:
       - reference-id: BPB
         identifiers:
@@ -101,7 +100,6 @@ controls:
       Provide transparency and accountability for the project's dependencies
       while enabling users and contributors to understand the software's direct
       dependencies.
-    family: Quality Assurance
     mappings:
       - reference-id: BPB
         identifiers:
@@ -188,7 +186,6 @@ controls:
       failing status checks, even if arbitrary, because it increases the risk of
       overlooking security vulnerabilities or defects identified by automated
       checks.
-    family: Quality Assurance
     mappings:
       - reference-id: CRA
         identifiers:
@@ -254,7 +251,6 @@ controls:
       Ensure that additional code repositories or subprojects produced by the
       project are held to a standard that is clear and appropriate for that
       codebase.
-    family: Quality Assurance
     mappings:
       - reference-id: CRA
         identifiers:
@@ -321,7 +317,6 @@ controls:
       Reduce the risk of including generated executable artifacts in the
       project's version control system, ensuring that only source code and
       necessary files are stored in the repository.
-    family: Quality Assurance
     mappings:
       - reference-id: CRA
         identifiers:
@@ -374,7 +369,6 @@ controls:
     objective: |
       Ensure that the project uses at least one automated test suite for the
       source code repository and clearly documents when and how tests are run.
-    family: Quality Assurance
     mappings:
       - reference-id: BPB
         identifiers:
@@ -470,7 +464,6 @@ controls:
       Ensure that the project's version control system requires at least one
       non-author approval of changes before merging into the release or primary
       branch.
-    family: Quality Assurance
     mappings:
       - reference-id: BPB
         identifiers:

baseline/OSPS-SA.yaml

@@ -1,4 +1,4 @@
-category: Security Assessment
+title: Security Assessment
 description: |
   Security Assessment encourages practices that
   help ensure that the project is well positioned
@@ -14,7 +14,6 @@ controls:
       the interactions and components of the system to help contributors and
       security reviewers understand the internal logic of the released software
       assets.
-    family: Security Assessment
     mappings:
       - reference-id: BPB
         identifiers:
@@ -90,7 +89,6 @@ controls:
       Provide users and developers with an understanding of how to interact with
       the project's software and integrate it with other systems, enabling them
       to use the software effectively.
-    family: Security Assessment
     mappings:
       - reference-id: BPB
         identifiers:
@@ -152,7 +150,6 @@ controls:
       Provide 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 occurring.
-    family: Security Assessment
     mappings:
       - reference-id: BPB
         identifiers: