Feature/all valid test

Dockerfile

@@ -10,13 +10,13 @@ ARG TEMURIN_APK_KEY_URL=https://packages.adoptium.net/artifactory/api/security/k
 ARG TEMURIN_APK_REPO_URL=https://packages.adoptium.net/artifactory/apk/alpine/main
 ARG TEMURIN_APK_VERSION=temurin-22-jdk
 ARG MAVEN_DEP_PLUGIN_VERSION=3.8.0
-ARG OSCAL_CLI_VERSION=2.2.0
+ARG OSCAL_CLI_VERSION=2.3.1
 # Current public key ID for maintainers@metaschema.dev releases of oscal-cli
 # Static analysis from docker build and push warns this is a secret, it is not
 # and is necessary to cross-ref the Maven GPG key for checking build signatures.
 # https://keyserver.ubuntu.com/pks/lookup?search=0127D75951997E00&fingerprint=on&op=index
 ARG OSCAL_CLI_GPG_KEY=0127D75951997E00
-ARG OSCAL_JS_VERSION=1.4.4
+ARG OSCAL_JS_VERSION=2.0.6
 ARG FEDRAMP_AUTO_GIT_URL=https://github.com/GSA/fedramp-automation.git
 ARG FEDRAMP_AUTO_GIT_REF=feature/external-constraints
 ARG FEDRAMP_AUTO_GIT_COMMIT

documents/adr/0002-git-release-version-strategy.md

@@ -1,10 +1,12 @@
 # 2. Release and Version Strategy Used for Github Tagging
 
-Date: 2021-06-03
+Date: 2021-10-07
 
 ## Status
 
-Accepted
+Deprecated
+
+(**NOTE:** FedRAMP deprecated this ADR retroactively in favor of [ADR #10](./0010-semantic-versions-only.md). See ADR #10 for further details on the current version methodology as part of the FedRAMP Automation Team's release strategy.)
 
 ## Context
 

documents/adr/0010-semantic-versions-only.md

@@ -0,0 +1,46 @@
+# 10. Replace Spock Versions with Semantic Versions in Release Strategy
+
+Date: 2021-10-07
+
+## Status
+
+Accepted
+
+## Context
+
+In the past, the FedRAMP Automation Team implemented [the versioning methodology of the Spock Framework](https://spockframework.org/spock/docs/2.0/known_issues.html#_groovy_version_compatibility). Staff documented this versioning methodology in [ADR #2](https://github.com/GSA/fedramp-automation/blob/247f99a0e3a2cfa6b9e78dd7c18836cf008115b2/documents/adr/0002-git-release-version-strategy.md). In 2024, the FedRAMP Automation Team received significant positive feedback from the community to transition from this methodology to [Semantic Versioning](https://semver.org/) as part of its release strategy and updated [the automate.fedramp.gov website](https://automate.fedramp.gov/about/release/) accordingly. They also socialized with the community that the update page on the website, not the previous ADR and outdated developer documentation, is the canonical source for the release strategy and other documents.
+
+This decision record is to document the following possible solutions and implications.
+
+### Possible Solutions
+
+Below is a list of possible versioning solutions that will or will not support this strategy.
+
+1. Do nothing
+1. Continue Spock Versioning and revert Semantic Versioning change
+1. Continue Semantic Versioning change and completely deprecate Spock versioning
+
+#### Do Nothing
+
+If FedRAMP does nothing, the strategy and processes will stay as-is. The documentation about the release strategy and versioning methodology and the practice of using them in releases will contradict one another. Internal staff and external stakeholders will continue to receive conflicted guidance and releases. The misalignment may cause confusion about future releases. Despite less effort, it has significant downsides in risk when compared to Options 2 and 3.
+
+#### Continue Spock Versioning and Revert Semantic Versioning Change
+
+FedRAMP can change the developer documentation, standard operating procedures in the wiki, and the website to continue to use Spock versioning and revert the decision to use Semantic Versioning. This option would require similar effort to Option 3. However, this option will likely alienate community stakeholders receptive to the change.
+
+#### Continue Semantic Versioning Change and Completely Deprecate Spock Versioning
+
+FedRAMP can change the developer documentation, standard operating procedures in the wiki, and the website to finalize the removal of Spock versioning and fully commit to the decision to use Semantic Versioning. This option would require similar effort to Option 2 but with better community support for a popular transition that is not yet complete.
+
+## Decision
+
+FedRAMP has decided to move forward completely with the Semantic Versioning transition and completely deprecate the Spock versioning approach.
+
+1. FedRAMP will use Semantic Versioning, as is the preference of the community.
+2. The official, normative release guidance for FedRAMP Automation data, documentation, and tools is the [release guidance on automate.fedramp.gov](https://automate.fedramp.gov/about/release/), not developer documentation in this repository.
+
+## Consequences
+
+What becomes easier or more difficult to do because of this change?
+It will be easier for developers to automate handling version updates based on SemVer rules.
+It will be easier for developers to automate handling version updates based on SemVer rules.

features/fedramp_extensions.feature

@@ -3,7 +3,134 @@ Feature: OSCAL Document Constraints
 @style-guide
 Scenario Outline: Validating OSCAL constraints with metaschema constraints
   Then I should verify that all constraints follow the style guide constraint
-
+
+@integration
+Scenario Outline: Documents that should be valid are pass
+  Then I should have valid results "<valid_file>"
+Examples:
+| valid_file     |
+| ssp-all-VALID.xml |
+# | ../../../content/awesome-cloud/xml/AwesomeCloudSSP1.xml |
+# | ../../../content/awesome-cloud/xml/AwesomeCloudSSP2.xml |
+
+@full-coverage
+Scenario: Preparing constraint coverage analysis
+Given I have loaded all Metaschema extensions documents
+And I have collected all YAML test files in the test directory
+When I extract all constraint IDs from the Metaschema extensions
+And I analyze the YAML test files for each constraint ID
+
+@full-coverage
+Scenario Outline: Ensuring full test coverage for "<constraint_id>"
+Then I should have both FAIL and PASS tests for constraint ID "<constraint_id>"
+Examples:
+| constraint_id |
+#BEGIN_DYNAMIC_CONSTRAINT_IDS
+  | address-type |
+  | attachment-type |
+  | authorization-type |
+  | categorization-has-correct-system-attribute |
+  | categorization-has-information-type-id |
+  | cia-impact-has-adjustment-justification |
+  | cia-impact-has-selected |
+  | cloud-service-model |
+  | component-type |
+  | control-implementation-status |
+  | data-center-alternate |
+  | data-center-count |
+  | data-center-country-code |
+  | data-center-primary |
+  | data-center-us |
+  | deployment-model |
+  | fedramp-version |
+  | fully-operational-date-is-valid |
+  | fully-operational-date-type |
+  | has-authenticator-assurance-level |
+  | has-authorization-boundary-diagram |
+  | has-authorization-boundary-diagram-caption |
+  | has-authorization-boundary-diagram-description |
+  | has-authorization-boundary-diagram-link |
+  | has-authorization-boundary-diagram-link-href-target |
+  | has-authorization-boundary-diagram-link-rel |
+  | has-authorization-boundary-diagram-link-rel-allowed-value |
+  | has-cloud-deployment-model |
+  | has-cloud-deployment-model-remarks |
+  | has-cloud-service-model |
+  | has-cloud-service-model-remarks |
+  | has-configuration-management-plan |
+  | has-data-flow |
+  | has-data-flow-description |
+  | has-data-flow-diagram |
+  | has-data-flow-diagram-caption |
+  | has-data-flow-diagram-description |
+  | has-data-flow-diagram-link |
+  | has-data-flow-diagram-link-href-target |
+  | has-data-flow-diagram-link-rel |
+  | has-data-flow-diagram-link-rel-allowed-value |
+  | has-data-flow-diagram-uuid |
+  | has-federation-assurance-level |
+  | has-fully-operational-date |
+  | has-identity-assurance-level |
+  | has-incident-response-plan |
+  | has-information-system-contingency-plan |
+  | has-network-architecture |
+  | has-network-architecture-diagram |
+  | has-network-architecture-diagram-caption |
+  | has-network-architecture-diagram-description |
+  | has-network-architecture-diagram-link |
+  | has-network-architecture-diagram-link-href-target |
+  | has-network-architecture-diagram-link-rel |
+  | has-network-architecture-diagram-link-rel-allowed-value |
+  | has-published-date |
+  | has-rules-of-behavior |
+  | has-security-impact-level |
+  | has-security-sensitivity-level |
+  | has-separation-of-duties-matrix |
+  | has-system-id |
+  | has-system-name-short |
+  | has-user-guide |
+  | import-profile-has-available-document |
+  | import-profile-resolves-to-fedramp-content |
+  | information-type-800-60-v2r1 |
+  | information-type-has-availability-impact |
+  | information-type-has-confidentiality-impact |
+  | information-type-has-integrity-impact |
+  | information-type-system |
+  | interconnection-direction |
+  | interconnection-security |
+  | inventory-item-allows-authenticated-scan |
+  | inventory-item-public |
+  | inventory-item-virtual |
+  | marking |
+  | missing-response-components |
+  | party-has-name |
+  | privilege-level |
+  | prop-response-point-has-cardinality-one |
+  | resource-has-base64-or-rlink |
+  | resource-has-title |
+  | responsible-party-is-person |
+  | responsible-party-prepared-by |
+  | responsible-party-prepared-by-location-valid |
+  | responsible-party-prepared-for |
+  | responsible-party-prepared-for-location-valid |
+  | role-defined-authorizing-official-poc |
+  | role-defined-information-system-security-officer |
+  | role-defined-prepared-by |
+  | role-defined-prepared-for |
+  | role-defined-system-owner |
+  | scan-type |
+  | security-level |
+  | security-sensitivity-level-matches-security-impact-level |
+  | user-has-authorized-privilege |
+  | user-has-privilege-level |
+  | user-has-role-id |
+  | user-has-sensitivity-level |
+  | user-has-user-type |
+  | user-privilege-level |
+  | user-sensitivity-level |
+  | user-type |
+#END_DYNAMIC_CONSTRAINT_IDS
+
 @constraints
 Scenario Outline: Validating OSCAL documents with metaschema constraints
   Given I have Metaschema extensions documents
@@ -67,6 +194,8 @@ Examples:
   | has-authorization-boundary-diagram-description-PASS.yaml |
   | has-authorization-boundary-diagram-link-FAIL.yaml |
   | has-authorization-boundary-diagram-link-PASS.yaml |
+  | has-authorization-boundary-diagram-link-href-target-FAIL.yaml |
+  | has-authorization-boundary-diagram-link-href-target-PASS.yaml |
   | has-authorization-boundary-diagram-link-rel-FAIL.yaml |
   | has-authorization-boundary-diagram-link-rel-PASS.yaml |
   | has-authorization-boundary-diagram-link-rel-allowed-value-FAIL.yaml |
@@ -93,6 +222,8 @@ Examples:
   | has-data-flow-diagram-description-PASS.yaml |
   | has-data-flow-diagram-link-FAIL.yaml |
   | has-data-flow-diagram-link-PASS.yaml |
+  | has-data-flow-diagram-link-href-target-FAIL.yaml |
+  | has-data-flow-diagram-link-href-target-PASS.yaml |
   | has-data-flow-diagram-link-rel-FAIL.yaml |
   | has-data-flow-diagram-link-rel-PASS.yaml |
   | has-data-flow-diagram-link-rel-allowed-value-FAIL.yaml |
@@ -119,6 +250,8 @@ Examples:
   | has-network-architecture-diagram-description-PASS.yaml |
   | has-network-architecture-diagram-link-FAIL.yaml |
   | has-network-architecture-diagram-link-PASS.yaml |
+  | has-network-architecture-diagram-link-href-target-FAIL.yaml |
+  | has-network-architecture-diagram-link-href-target-PASS.yaml |
   | has-network-architecture-diagram-link-rel-FAIL.yaml |
   | has-network-architecture-diagram-link-rel-PASS.yaml |
   | has-network-architecture-diagram-link-rel-allowed-value-FAIL.yaml |
@@ -183,12 +316,18 @@ Examples:
   | responsible-party-prepared-by-PASS.yaml |
   | responsible-party-prepared-by-location-valid-FAIL.yaml |
   | responsible-party-prepared-by-location-valid-PASS.yaml |
+  | responsible-party-prepared-for-FAIL.yaml |
+  | responsible-party-prepared-for-PASS.yaml |
+  | responsible-party-prepared-for-location-valid-FAIL.yaml |
+  | responsible-party-prepared-for-location-valid-PASS.yaml |
   | role-defined-authorizing-official-poc-FAIL.yaml |
   | role-defined-authorizing-official-poc-PASS.yaml |
   | role-defined-information-system-security-officer-FAIL.yaml |
   | role-defined-information-system-security-officer-PASS.yaml |
   | role-defined-prepared-by-FAIL.yaml |
   | role-defined-prepared-by-PASS.yaml |
+  | role-defined-prepared-for-FAIL.yaml |
+  | role-defined-prepared-for-PASS.yaml |
   | role-defined-system-owner-FAIL.yaml |
   | role-defined-system-owner-PASS.yaml |
   | scan-type-FAIL.yaml |
@@ -215,114 +354,3 @@ Examples:
   | user-type-PASS.yaml |
 #END_DYNAMIC_TEST_CASES
 
-@full-coverage
-Scenario: Preparing constraint coverage analysis
-Given I have loaded all Metaschema extensions documents
-And I have collected all YAML test files in the test directory
-When I extract all constraint IDs from the Metaschema extensions
-And I analyze the YAML test files for each constraint ID
-
-@full-coverage
-Scenario Outline: Ensuring full test coverage for "<constraint_id>"
-Then I should have both FAIL and PASS tests for constraint ID "<constraint_id>"
-Examples:
-| constraint_id |
-#BEGIN_DYNAMIC_CONSTRAINT_IDS
-  | address-type |
-  | attachment-type |
-  | authorization-type |
-  | categorization-has-correct-system-attribute |
-  | categorization-has-information-type-id |
-  | cia-impact-has-adjustment-justification |
-  | cia-impact-has-selected |
-  | cloud-service-model |
-  | component-type |
-  | control-implementation-status |
-  | data-center-alternate |
-  | data-center-count |
-  | data-center-country-code |
-  | data-center-primary |
-  | data-center-us |
-  | deployment-model |
-  | fedramp-version |
-  | fully-operational-date-is-valid |
-  | fully-operational-date-type |
-  | has-authenticator-assurance-level |
-  | has-authorization-boundary-diagram |
-  | has-authorization-boundary-diagram-caption |
-  | has-authorization-boundary-diagram-description |
-  | has-authorization-boundary-diagram-link |
-  | has-authorization-boundary-diagram-link-rel |
-  | has-authorization-boundary-diagram-link-rel-allowed-value |
-  | has-cloud-deployment-model |
-  | has-cloud-deployment-model-remarks |
-  | has-cloud-service-model |
-  | has-cloud-service-model-remarks |
-  | has-configuration-management-plan |
-  | has-data-flow |
-  | has-data-flow-description |
-  | has-data-flow-diagram |
-  | has-data-flow-diagram-caption |
-  | has-data-flow-diagram-description |
-  | has-data-flow-diagram-link |
-  | has-data-flow-diagram-link-rel |
-  | has-data-flow-diagram-link-rel-allowed-value |
-  | has-data-flow-diagram-uuid |
-  | has-federation-assurance-level |
-  | has-fully-operational-date |
-  | has-identity-assurance-level |
-  | has-incident-response-plan |
-  | has-information-system-contingency-plan |
-  | has-network-architecture |
-  | has-network-architecture-diagram |
-  | has-network-architecture-diagram-caption |
-  | has-network-architecture-diagram-description |
-  | has-network-architecture-diagram-link |
-  | has-network-architecture-diagram-link-rel |
-  | has-network-architecture-diagram-link-rel-allowed-value |
-  | has-published-date |
-  | has-rules-of-behavior |
-  | has-security-impact-level |
-  | has-security-sensitivity-level |
-  | has-separation-of-duties-matrix |
-  | has-system-id |
-  | has-system-name-short |
-  | has-user-guide |
-  | import-profile-has-available-document |
-  | import-profile-resolves-to-fedramp-content |
-  | information-type-800-60-v2r1 |
-  | information-type-has-availability-impact |
-  | information-type-has-confidentiality-impact |
-  | information-type-has-integrity-impact |
-  | information-type-system |
-  | interconnection-direction |
-  | interconnection-security |
-  | inventory-item-allows-authenticated-scan |
-  | inventory-item-public |
-  | inventory-item-virtual |
-  | marking |
-  | missing-response-components |
-  | party-has-name |
-  | privilege-level |
-  | prop-response-point-has-cardinality-one |
-  | resource-has-base64-or-rlink |
-  | resource-has-title |
-  | responsible-party-is-person |
-  | responsible-party-prepared-by |
-  | responsible-party-prepared-by-location-valid |
-  | role-defined-authorizing-official-poc |
-  | role-defined-information-system-security-officer |
-  | role-defined-prepared-by |
-  | role-defined-system-owner |
-  | scan-type |
-  | security-level |
-  | security-sensitivity-level-matches-security-impact-level |
-  | user-has-authorized-privilege |
-  | user-has-privilege-level |
-  | user-has-role-id |
-  | user-has-sensitivity-level |
-  | user-has-user-type |
-  | user-privilege-level |
-  | user-sensitivity-level |
-  | user-type |
-#END_DYNAMIC_CONSTRAINT_IDS