Fix health endpoint scanner availability checks

[Trishanthsai]

Linked issue

Closes #9

What this PR does

Updated the /health endpoint to check whether semgrep, osv-scanner, and gitleaks are available on the system. The endpoint now returns the availability of each scanner and reports the status as degraded when one or more scanners are missing.

Type of change

• Bug fix

ML tier (if applicable)

• Not ML-related

---

Changes

Backend

• Added scanner availability checks using shutil.which()
• Added scanner status information to the /health response
• Added degraded status when any scanner is unavailable

---

Testing

How did you test this?

Ran the backend locally and verified the /health endpoint response in the browser. Confirmed that scanner availability is reported correctly and the status changes to degraded when scanners are not installed.

Checklist

• No new console.error or unhandled Python exceptions introduced

---

Anything reviewers should focus on

Health status logic and scanner availability checks.

[ionfwsrijan]

@sasidaran-99 Tests fail.

[Trishanthsai]

Hi @ionfwsrijan will look into this and will update

[ionfwsrijan]

Hey @Trishanthsai! The core logic looks good. shutil.which() is the right approach and the degraded status works correctly. A few things before this can be merged:

1. Breaking change: ok field removed — the original /health returned {"ok": True}. Your new response only returns status and scanners, which silently breaks anything checking for ok. Either keep it for backwards compatibility:

return {
    "ok": True,
    "status": status,
    "scanners": scanners,
}

...or confirm nothing in the frontend depends on it and document the shape change in the PR description.

2 Frontend piece is missing — the issue spec included a warning banner in the UI when status is "degraded". That's not in this PR. Either add it here or open a separate follow-up issue for it. Either is fine, just needs tracking.

Fix these and this is good to merge!

[Trishanthsai]

Hi @ionfwsrijan,

I've restored the ok field in the health endpoint response for backward compatibility and pushed the update.

For the frontend warning banner when the health status is degraded, I couldn't find any existing health-check integration in the UI. Since the current issue is focused on the backend health endpoint, I suggest tracking the UI banner as a separate follow-up issue unless you'd prefer it to be included in this PR.

Thanks!

[ionfwsrijan]

@Trishanthsai That LGMT as well. You may raise a followup issue. Also pls resolve the merge conflicts with the main

[Trishanthsai]

Hi @ionfwsrijan,

I've resolved the merge conflicts with main. The PR now shows no conflicts with the base branch.

It looks like the remaining workflow is awaiting maintainer approval. Could you please approve/re-run it when you get a chance?

Also, I'll raise a follow-up issue for the frontend degraded-status warning banner as discussed.

Thanks!

[Copilot]

Pull request overview

This PR updates the FastAPI backend /health endpoint to report whether required CLI scanners are present on PATH, and to surface a degraded health state when one or more scanners are missing. This supports more accurate operational readiness checks before running scans.

Changes:

• Add shutil.which() checks for semgrep, osv-scanner, and gitleaks.
• Include per-scanner availability in the /health response.
• Add a derived status field (ok vs degraded) based on scanner availability.

---

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