TT-16670: use CVE ids in scan report

[olamilekan000]

change updates the OSV scan report generation script to prefer CVE IDs from the aliases field,
falling back to GHSA when a CVE is not available

[probelabs]

This pull request refines the OSV security scanning workflow to enhance the clarity and standardization of vulnerability reports. The primary change involves updating the jq script that processes scan results to prioritize CVE IDs from the vulnerability data's aliases field. If a CVE ID is not available, it gracefully falls back to the default identifier, such as a GHSA ID. Additionally, the workflow is updated to correctly handle the MODERATE severity level, replacing the previous MEDIUM to align with the scanner's output.

Files Changed Analysis

• .github/workflows/osv-path-scan.yml (+5, -5): All modifications are confined to this single workflow file. The changes specifically target the jq commands responsible for parsing the OSV scanner's JSON output and formatting it into a human-readable report.

Architecture & Impact Assessment

• What this PR accomplishes: It improves the security vulnerability reports by using standardized CVE identifiers, which simplifies cross-referencing, research, and triaging of issues. It also ensures the report accurately reflects the severity levels provided by the OSV scanner.
• Key technical changes introduced:
  • The jq query is updated to conditionally select the vulnerability identifier, preferring any alias that starts with CVE-.
  • The logic for calculating the vulnerability score has been made more robust, checking for max_severity before falling back to CVSS scores.
  • The severity filter and report section for medium-level vulnerabilities have been changed from MEDIUM to MODERATE.
• Affected system components: This change directly affects the security reporting step within the CI/CD pipeline. The impact is on the presentation and accuracy of security scan results, with no changes to the scanning execution itself.

Reporting Flow

graph TD
    A[Run OSV Scanner] --> B{Generate osv-results.json};
    B --> C["Parse JSON with jq<br/><b>(Logic updated to prioritize CVE IDs & use MODERATE severity)</b>"];
    C --> D[Generate Formatted Report];
    D --> E[Post Report to GitHub];

Loading

Scope Discovery & Context Expansion

• The scope of this change is narrowly focused on the report generation logic within the osv-path-scan.yml workflow.
• It does not alter how the OSV scan is executed, which packages are scanned, or the criteria for scan failure. The change is purely cosmetic and informational, improving the final report.
• While this change is self-contained, it's worth considering if other security scanning workflows in the repository (e.g., for different ecosystems or using different tools) would benefit from a similar standardization of their report outputs for consistency.

---

Powered by Visor from Probelabs

Last updated: 2026-04-29T15:22:54.227Z | Triggered by: pr_updated | Commit: 13d4a8b

💡 TIP: You can chat with Visor using /visor ask <your question>

[probelabs]

✅ Security Check Passed

No security issues found – changes LGTM.

Architecture Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/osv-path-scan.yml:65-67	The `jq` script for generating report lines has grown significantly in complexity, making it difficult to read, debug, and maintain. The logic for selecting a vulnerability ID (preferring CVEs) and finding a score from multiple fallback locations is now condensed into a single, hard-to-parse line. This approach is not scalable for future modifications and is a maintainability risk. 💡 Suggestion To improve maintainability, this complex `jq` logic should be made more readable. Rewrite the `jq` command to be a multi-line script with comments, using a YAML block scalar (`|`). This would significantly improve readability without introducing new language dependencies. Breaking down the logic with intermediate variables (`as $var`) and using string interpolation `\($var)` instead of concatenation will also improve clarity. 🔧 Suggested Fix .results[]? | .packages[]? as $pkg | ($pkg.vulnerabilities // [])[]? as $vuln | select($vuln.database_specific.severity == $sev) | # Prefer CVE alias, fallback to main ID ( ($vuln.aliases // []) | map(select(startswith("CVE-")))[0] // $vuln.id ) as $vuln_id | # Find the best score from multiple possible locations ( [$pkg.groups[] | select(.ids | contains([$vuln.id]))][0].max_severity // $vuln.database_specific.max_severity // $vuln.database_specific.cvss.score // $vuln.database_specific.cvss3_score // "0" | if . == "" then "0" else . end ) as $score | # Get fixed version info ( [$vuln.affected[]?.ranges[]?.events[]?.fixed | select(. != null)] | unique | join(",") // "unknown" ) as $fixed_versions | # Get summary ( $vuln.summary // $vuln.details | split("\n")[0] | sub("^[ ]+"; "") ) as $summary | "- (\($vuln_id)) (score: \($score), affects: \($pkg.package.name)@\($pkg.package.version), fixed: \($fixed_versions)): \($summary)"

✅ Security Check Passed

No security issues found – changes LGTM.

\n\n

Architecture Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/osv-path-scan.yml:65-67	The `jq` script for generating report lines has grown significantly in complexity, making it difficult to read, debug, and maintain. The logic for selecting a vulnerability ID (preferring CVEs) and finding a score from multiple fallback locations is now condensed into a single, hard-to-parse line. This approach is not scalable for future modifications and is a maintainability risk. 💡 Suggestion To improve maintainability, this complex `jq` logic should be made more readable. Rewrite the `jq` command to be a multi-line script with comments, using a YAML block scalar (`|`). This would significantly improve readability without introducing new language dependencies. Breaking down the logic with intermediate variables (`as $var`) and using string interpolation `\($var)` instead of concatenation will also improve clarity. 🔧 Suggested Fix .results[]? | .packages[]? as $pkg | ($pkg.vulnerabilities // [])[]? as $vuln | select($vuln.database_specific.severity == $sev) | # Prefer CVE alias, fallback to main ID ( ($vuln.aliases // []) | map(select(startswith("CVE-")))[0] // $vuln.id ) as $vuln_id | # Find the best score from multiple possible locations ( [$pkg.groups[] | select(.ids | contains([$vuln.id]))][0].max_severity // $vuln.database_specific.max_severity // $vuln.database_specific.cvss.score // $vuln.database_specific.cvss3_score // "0" | if . == "" then "0" else . end ) as $score | # Get fixed version info ( [$vuln.affected[]?.ranges[]?.events[]?.fixed | select(. != null)] | unique | join(",") // "unknown" ) as $fixed_versions | # Get summary ( $vuln.summary // $vuln.details | split("\n")[0] | sub("^[ ]+"; "") ) as $summary | "- (\($vuln_id)) (score: \($score), affects: \($pkg.package.name)@\($pkg.package.version), fixed: \($fixed_versions)): \($summary)"

\n\n ### Performance Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/osv-path-scan.yml:66-68	The `jq` expression to find `max_severity` for a vulnerability involves iterating through all of the package's groups (`$pkg.groups[]`). This nested search is performed for every vulnerability, leading to inefficient O(N*M) complexity where N is the number of vulnerabilities and M is the number of groups. For large projects with many dependencies and vulnerabilities, this can significantly slow down the report generation step. 💡 Suggestion Optimize the lookup by pre-calculating a map of vulnerability IDs to their `max_severity` once per package. This changes the lookup from a slow O(M) search to a fast O(1) map access for each vulnerability. The overall `jq` script should be modified to build this map before processing the vulnerabilities. 🔧 Suggested Fix ((($pkg.groups // []) | map(select(.ids) | .ids[] as $id | {($id): .max_severity}) | add // {})) as $group_severities | ($pkg.vulnerabilities // [])[]? as $vuln | select($vuln.database_specific.severity == $sev) | "- (" + (((($vuln.aliases // []) | map(select(startswith("CVE-")))[0])) // $vuln.id) + ") (score: " + (($group_severities[$vuln.id] // $vuln.database_specific.max_severity // $vuln.database_specific.cvss.score // $vuln.database_specific.cvss3_score // "0") | if . == "" then "0" else . end) + ", affects: \($pkg.package.name)@\($pkg.package.version), fixed: \([$vuln.affected[]?.ranges[]?.events[]?.fixed | select(. != null)] | unique | join(",") // "unknown")): \($vuln.summary // $vuln.details | split("\n")[0] | sub("^[ ]+"; ""))"

Quality Issues (1)

Severity	Location	Issue
🔴 Critical	.github/workflows/osv-path-scan.yml:97	A hardcoded commit SHA has been introduced, which will cause the created GitHub Check Run to always be associated with a static commit ('8888ebe...') instead of the actual commit that triggered the workflow. This will lead to incorrect reporting and make it difficult to trace scan results back to the correct code change. 💡 Suggestion The commit SHA should be retrieved dynamically from the GitHub Actions context. Please revert this line to use `${{ github.sha }}` to ensure the check is associated with the correct commit. 🔧 Suggested Fix --arg sha "${{ github.sha }}" \

---

Powered by Visor from Probelabs

Last updated: 2026-04-29T15:22:46.198Z | Triggered by: pr_updated | Commit: 13d4a8b

💡 TIP: You can chat with Visor using /visor ask <your question>