Open Policy Agent good first issues

This issue requests the addition of unit tests for the `cmmc_maintenance.rego` policy file. The goal is to ensure each of the approximately six boolean rules within this policy is adequately tested with inputs that trigger both true and false conditions, and that the overall compliance report is a populated object even with empty input.

This issue requests the addition of comprehensive unit tests for the `authorization.rego` policy within the AI governance module. The goal is to ensure each of the approximately seven boolean rules is tested with both true and false input cases, and that the overall compliance report behaves as expected, particularly on empty input.

This issue requests the addition of comprehensive unit tests for the `context_validation.rego` policy, which enforces AI governance standards. The tests should cover approximately 10 boolean rules, ensuring each rule can be triggered with both compliant and non-compliant input, and that the overall report is a populated object on empty input.

This issue requests the addition of unit tests for the `soc2_main.rego` policy file. The goal is to ensure that each of the approximately five boolean rules within this policy is exercised with both compliant and non-compliant input, and that the overall compliance report is correctly generated.

This issue requests the addition of comprehensive unit tests for the `gdpr_compliance.rego` policy. The goal is to ensure each of the approximately 21 boolean rules is tested with inputs that make them both true and false, while also verifying the overall compliance report structure.

This issue requests the addition of unit tests for the `sentinel_ansible.rego` policy, which enforces Ansible standards. The tests should cover all five defined violation rules by providing input that triggers each violation and asserting the correct error message. Additionally, compliant input should be tested to ensure no violations are reported, and the compliance report should be verified as a populated object on empty input.

This issue requests the addition of comprehensive unit tests for the `geisa_api.rego` policy file. The tests should cover all 9 defined violation rules by providing input that triggers each violation and verifying the expected message. Additionally, tests for compliant input that result in an empty violation set are required, and the compliance report should be asserted as a populated object for empty input.

This issue requests the addition of comprehensive unit tests for the `sudo_validation.rego` policy within the CIS RHEL 8 benchmark. The goal is to ensure all 14 violation rules are covered with specific test cases that trigger violations and compliant cases that result in no violations, ultimately verifying the policy's correctness.

This issue requests the addition of comprehensive unit tests for the `sudo_validation.rego` policy within the CIS RHEL 9 benchmark. The goal is to ensure all 14 violation rules are covered with specific test cases that trigger them, and also to include compliant test cases where no violations are found. The tests should be placed in `benchmarks/cis/rhel_9/tests/test_sudo_validation.rego` and pass the `opa test` command.

This issue requests the addition of comprehensive unit tests for the `selinux_validation.rego` policy within the CIS RHEL 9 benchmark. The goal is to ensure each of the 13 violation rules is covered with both failing and compliant input cases, and that the overall compliance report functions correctly.

This issue highlights a documentation gap in the AGENTS.md file regarding the `rule_data` defaults mechanism and its priority hierarchy. A review agent incorrectly approved a change that added a vendor-specific build type to global defaults, which should have been a per-deployment configuration. The documentation needs to clarify inclusion criteria for global defaults versus custom configurations to prevent similar mistakes.

This issue identifies misleading documentation in AGENTS.md regarding how collections are registered. The current guidance suggests editing collection files, but collections are actually declared via METADATA annotations in rule files. The proposed change is to update AGENTS.md to accurately reflect this mechanism.

This issue highlights a gap in the review agent's understanding of testing expectations for new collection definitions. The proposed solution is to update the AGENTS.md documentation to explicitly state that new collection definitions themselves do not require new tests, as existing tests cover collection filtering and dependency consistency.

This issue proposes creating a tracking issue in the conforma/policy repository to update a hardcoded reference in the `hack/update-infra-deployments.sh` script. The script currently points to a stale `enterprise-contract` image, and the goal is to update it to its `conforma` equivalent or document why it remains unchanged.

This issue proposes to remove stale generated documentation files (.adoc) that remain in the repository after their corresponding policy packages are deleted. The current CI process does not detect these leftover files. The suggested solution is to clear the entire `packages/` directory before regenerating documentation, as all files within it are generated.

The review agent missed a crucial `effective_on` date for new deny rules, leading to immediate enforcement. This issue proposes adding an explicit checklist item to AGENTS.md to ensure the agent flags missing `effective_on` dates for future policy rule additions.

This issue requests improving the documentation for default values of CVE rule data keys. Currently, defaults are scattered and not clearly presented, leading to potential confusion. The proposed solution involves creating a dedicated section for default values in the CVE package documentation and potentially a cross-cutting reference page for all rule data defaults.

This issue proposes enhancing the generated rule documentation to include clear instructions on how to exclude specific rules from policy evaluation. The goal is to standardize this information across all per-rule documentation pages by updating the `package.template` to automatically include exclusion details using existing rule metadata.

This issue requests documentation updates for the Policy Authoring guide. It needs to detail the expected structure of policy rule results, including fields like 'code', 'msg', 'effective_on', and optional fields. Additionally, it requires documentation for helper functions like `result_helper` that generate correctly formatted results using annotations.

This issue proposes to change the "Code tampering detected" message to something less alarming and more descriptive. The current message is triggered when a trusted artifact input isn't from the pipeline or when an untrusted PipelineTask is in the build chain. The goal is to provide a clearer indication of configuration issues or unlisted tasks.

This issue proposes adding a Conforma policy rule to prevent the direct use of Tekton parameters within `spec.steps[].script` blocks in Task definitions. This is a security measure to mitigate command injection vulnerabilities, as recommended by Tekton documentation. The rule should scan for `$(params.` patterns in script blocks and flag them as violations.

This issue requests comprehensive documentation for using time-based data (`effective_on`) within policy rule data sources. The current documentation is fragmented, and a user-facing guide is needed to explain the general concept, how `most_current()` functions, data structuring for phased changes, and provide concrete examples across various rule types.

This issue requests documentation for using the `policy/lib` helper functions within custom Conforma/EC policies. It aims to clarify available library packages, how to import them, provide usage examples, and explain the relationship between deprecated and new library paths. The goal is to enable users to reuse existing logic instead of reimplementing common patterns.

The `listOfDangerousArtifacts` array is defined within `default-config-inputs.json` but appears to be unused by any existing rules or code. This suggests it might be dead code or an incomplete feature that was never fully implemented.