[arpitjain099]

GET /api/score takes an optional ?subscription_id= and scopes its "latest completed scan" lookup to it. /api/score/cve-summary, ten lines below in the same file, never reads the query string, and get_cve_summary() has no parameter to take one. The dashboard draws both side by side, so on a shared database they can describe different subscriptions.

get_cve_summary() now takes the same argument get_score() and get_compliance_score() already take, and the scan lookup moves into its own query as in both siblings. Tests cover the SQL and the route; the suite goes 1537 to 1543 locally.

[parthrohit22]

Approved: the CVE summary is now scoped to the same subscription as /api/score, the route validates malformed subscription IDs, and the tests cover the regression and fallback paths.

[parthrohit22]

Thanks for the fix and for covering the regression so carefully. The CVE summary now follows the same subscription scoping contract as /api/score, and the route rejects malformed subscription IDs instead of silently falling back to an unscoped query. The tests cover the scoped path, the default fallback, and the invalid-input case, so I’m comfortable approving this change.

[ritiksah141]

CI seems to be failing, so please fix that and would be good to go from my side.

[arpitjain099]

Thanks for the review, Ritik. All three red checks come down to one dependency finding: pip-audit and Trivy both flag oauthlib 4.0.0 for CVE-2026-49272 (fixed in 4.0.1), and CI Summary just aggregates those two. That advisory was published on 2026-11-05, after dev and the other open PRs last ran green, so dev will show the same failure the moment its CI reruns. This PR changes only the score route, the finding model, and their tests, so it does not touch requirements.txt or any dependency. Since bumping the hash-pinned lockfile is its own change (the way #365 handled the last oauthlib bump), could I please open a separate fix(deps) PR for oauthlib 4.0.1, or leave it to Dependabot? Happy to do whichever you prefer.