BUILD-11091: Adds check-sca action for enforcing that SCA is active

[bwalsh434]

Context

We (EngXP) are trying to add enforcement of SonarQube SCA Scanning for GitHub repos in the SonarSource GitHub organization. We first thought of using a quality gate for this, but confirmed with the SCA Product Manager that this is not possible for checking whether a SonarQube project has been scanned by SCA or not (see slack convo).

We decided to go with this alternative solution of having a GitHub Action that is configured as a required check as part of a Ruleset at the SonarSource GitHub org level. This PR implements that check and tests it with GitHub repos that we expect to pass or fail.

• See here the github org ruleset I used to test this

What Changed?

• Implements the check-sca action, which when applied to a GitHub repo, checks if the GitHub repo that makes the commit has ever had its dependencies scanned by SCA in any of the three internal SQ instances (SQC-EU, SQC-US, and SQS-Next). If dependencies have never been scanned for the GitHub Repo's correlating SQ Project in any of the three instances, then the check fails and prevents the PR from being merged

Test Plan

• ✅ Set the SCA Enforcement ruleset to target portkey-admin-automation, which we expect to pass the check
  • Link to Check being triggered in a PR Commit and passing
• ✅ Set the SCA Enforcement ruleset to target peachee-cfamily-sources, which we expect to fail the check
  • Link to Check being triggered in a PR Commit and failing
• ✅ Set the github action in this PR towards the master branch instead of this feature branch
  • Note: Unfortunately, this will cause the action to fail locally on this branch until we merge it in to master the first time. We need the action is live in .github/workflows to be called by the branch ruleset, so this is necessary and the SCA check should succeed on the commit of this PR to master
  • See screenshot at the bottom to see proof that this was passing on this repo before changing the ref from this branch to master:
• Merge PR
• Remove check from ruleset since testing is complete. Ruleset will be created in terraform separately so that we can manage the repo exemptions via IaC.

[hashicorp-vault-sonar-prod]

BUILD-11091

[sonar-review-alpha]

Summary

New check-sca GitHub Action that enforces SonarQube SCA (Software Composition Analysis) has run for a project. This is part of SonarSource's effort to add org-level SCA enforcement via GitHub rulesets, since quality gates cannot check this metric directly.

The action:

• Discovers project keys from multiple config sources (.sonarlint/connectedMode.json, sonar-project.properties, pom.xml, build.gradle(.kts), or derived from the GitHub repo name)
• Polls three SonarQube instances (next, sqc-us, sqc-eu) for the sca_count_any_issue metric with configurable timeout (default 300s) and interval (default 15s)
• Fails if SCA data is missing after polling expires, preventing PR merge
• Authenticates via Vault and provides helpful guidance if Vault access is missing

Includes comprehensive ShellSpec tests, a workflow trigger for pull_request_target and merge_group events, and updates to sonar-project.properties to include the new action in SonarQube scans.

What reviewers should know

Where to start: check-sca/action.yml (action contract), then check-sca/check-sca.sh (core logic), then tests in spec/check-sca_spec.sh.

Key implementation details:

• Project key discovery tries explicit input first, then config files in priority order, finally derives from GITHUB_REPOSITORY. Deduplicates across sources while preserving order.
• Polling runs all SQ instance checks in parallel for each discovered key (lines 189-197 of check-sca.sh). Each check is non-blocking; script succeeds on the first match found.
• Vault credentials are fetched upfront with continue-on-error: true (action.yml:48). Vault failure is graceful—the action exits early with a helpful error message rather than proceeding with missing auth.
• Workflow in check-sca.yml references @master, not the feature branch. Per the author's note, this is intentional—the action must be live in .github/workflows for the branch ruleset to invoke it, so this will fail locally until merged.

Testing: ShellSpec mocks are thorough but simple (shell commands only). No external API calls during tests. Success and timeout paths are covered, plus edge cases like empty measures arrays and HTTP 404s.

Potential review focus:

• Verify project key discovery logic matches your repos' typical config patterns
• Check that the three SQ instance URLs/tokens in Vault are correct for your environment
• Confirm polling timeouts (300s default) are reasonable for your SCA scan latencies

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[Copilot]

Pull request overview

Adds a new check-sca composite GitHub Action + workflow to enforce that SonarQube SCA has run for a repository by polling SonarQube/SonarCloud metrics across the three internal instances.

Changes:

• Added check-sca composite action + bash implementation that discovers candidate project keys and polls Sonar measures for sca_count_any_issue.
• Added ShellSpec coverage for the new script behavior (project key discovery, API polling, main success/timeout).
• Wired the new action into the repo’s Sonar config and introduced a reusable workflow intended to be used as a required check.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
check-sca/check-sca.sh	Implements key discovery + polling logic for SCA verification.
check-sca/action.yml	Composite action wrapper fetching credentials from Vault and invoking the script.
.github/workflows/check-sca.yml	Workflow to run the required SCA check on PRs/pushes.
spec/check-sca_spec.sh	ShellSpec tests for the new check-sca script.
sonar-project.properties	Adds check-sca to Sonar sources for analysis.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[sonar-review-alpha]

Good first action overall — the polling logic, Vault error handling, and step summary are well-structured. Two issues need addressing before merge: the workflow's lack of a checkout step silently voids most of the key discovery logic, and the jq mock in the spec replaces the real filter rather than testing it.

🗣️ Give feedback