ROSAENG-64876: Add consolidated weekly security report procedure

[jonseidman]

Summary

Replaces the per-repo weekly Adversary scan notification with one consolidated report across the whole rosa-hyperfleet* family:

• Live repo discovery (gh search repos) — no hardcoded repo list, catches repos added/removed since the last run.
• A parallel Groundwork scan per discovered repo — one RWS pod + rws_goal_task each, all dispatched in the same turn so the whole family completes within the scheduler's 4-hour background-work ceiling.
• Explicit multi-turn state tracking: the task gets woken up as each repo's scan completes and must confirm all repos have reported before ever calling send_response — never posts a partial report.
• A single consolidated Slack report combining:
  • Executive summary for the three highest-criticality repos (rosa-hyperfleet, -api, -kube-applier), each with one cherry-picked, service-risk-framed finding
  • Top 5-10 CRITICAL/HIGH findings aggregated across the whole family (not per-repo)
  • A per-repo severity table with 🔴/🟡/🟢 status
  • Full per-repo results, alphabetically labeled

Companion change

Wired up by openshift-eng/ship-help-bot#649, which adds this file's %include() as the new rosa_hyperfleet_weekly_security_report scheduled task and switches the 6 individual per-repo scan tasks to manual-trigger-only.

Test plan

• Merge alongside/after openshift-eng/ship-help-bot#649
• Manually trigger the new scheduled task and confirm all current rosa-hyperfleet* repos get scanned in parallel, the task waits correctly across multiple completion wake-ups, and the final report matches the structure above

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: 65f1f12a-8334-488c-b92a-2b3994bc7ed4

---

_{Comment @coderabbitai help to get the list of available commands.}

[openshift-ci]

Hi @jonseidman. Thanks for your PR.

I'm waiting for a openshift-online member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[psav]

/ok-to-test

[openshift-ci-robot]

@jonseidman: This pull request explicitly references no jira issue.

Details

In response to this:

Summary

Replaces the per-repo weekly Adversary scan notification with one consolidated report across the whole rosa-hyperfleet* family:

• Live repo discovery (gh search repos) — no hardcoded repo list, catches repos added/removed since the last run.
• A parallel Groundwork scan per discovered repo — one RWS pod + rws_goal_task each, all dispatched in the same turn so the whole family completes within the scheduler's 4-hour background-work ceiling.
• Explicit multi-turn state tracking: the task gets woken up as each repo's scan completes and must confirm all repos have reported before ever calling send_response — never posts a partial report.
• A single consolidated Slack report combining:
• Executive summary for the three highest-criticality repos (rosa-hyperfleet, -api, -kube-applier), each with one cherry-picked, service-risk-framed finding
• Top 5-10 CRITICAL/HIGH findings aggregated across the whole family (not per-repo)
• A per-repo severity table with 🔴/🟡/🟢 status
• Full per-repo results, alphabetically labeled

Companion change

Wired up by openshift-eng/ship-help-bot#649, which adds this file's %include() as the new rosa_hyperfleet_weekly_security_report scheduled task and switches the 6 individual per-repo scan tasks to manual-trigger-only.

Test plan

• Merge alongside/after openshift-eng/ship-help-bot#649
• Manually trigger the new scheduled task and confirm all current rosa-hyperfleet* repos get scanned in parallel, the task waits correctly across multiple completion wake-ups, and the final report matches the structure above

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[jonseidman]

This is associated with Jira https://redhat.atlassian.net/browse/ROSAENG-64876 - will update title

[openshift-ci-robot]

@jonseidman: This pull request references ROSAENG-64876 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the sub-task to target the "5.1.0" version, but no target version was set.

Details

In response to this:

Summary

Replaces the per-repo weekly Adversary scan notification with one consolidated report across the whole rosa-hyperfleet* family:

• Live repo discovery (gh search repos) — no hardcoded repo list, catches repos added/removed since the last run.
• A parallel Groundwork scan per discovered repo — one RWS pod + rws_goal_task each, all dispatched in the same turn so the whole family completes within the scheduler's 4-hour background-work ceiling.
• Explicit multi-turn state tracking: the task gets woken up as each repo's scan completes and must confirm all repos have reported before ever calling send_response — never posts a partial report.
• A single consolidated Slack report combining:
• Executive summary for the three highest-criticality repos (rosa-hyperfleet, -api, -kube-applier), each with one cherry-picked, service-risk-framed finding
• Top 5-10 CRITICAL/HIGH findings aggregated across the whole family (not per-repo)
• A per-repo severity table with 🔴/🟡/🟢 status
• Full per-repo results, alphabetically labeled

Companion change

Wired up by openshift-eng/ship-help-bot#649, which adds this file's %include() as the new rosa_hyperfleet_weekly_security_report scheduled task and switches the 6 individual per-repo scan tasks to manual-trigger-only.

Test plan

• Merge alongside/after openshift-eng/ship-help-bot#649
• Manually trigger the new scheduled task and confirm all current rosa-hyperfleet* repos get scanned in parallel, the task waits correctly across multiple completion wake-ups, and the final report matches the structure above

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[typeid]

@jonseidman shall we remove the other adversary .md then in favor of this one? :) Otherwise it's just gonna lay around.

[jonseidman]

@typeid this PR is paired with openshift-eng/ship-help-bot/pull/649, which added the scheduled single/consolidated weekly scan and changed the individual per-repo scans to manual: https://github.com/openshift-eng/ship-help-bot/blob/bc89aa17263914ddf0abefbaea5a518f3e594309/config/groups/rosa/personas/rosa_hyperfleet.yaml#L136

[jonseidman]

@typeid I'll modify .chai-bot/rosa_hyperfleet_adversary_scan.md to clearly clarify that .md is for the manual scans, and the scheduled weekly scan is configured in .chai-bot/rosa_hyperfleet_weekly_security_report.md.

[jonseidman]

• This PR updated with the manual-scan wording clarification
• ship-help-bot PR #693 - moved the individual repo scans out of the /scheduled/ folder to /rosa_hyperfleet/ to clean up the changes

[typeid]

/lgtm
/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: typeid

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [typeid]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[jonseidman]

/retest