Potential fix for code scanning alert no. 16: Uncontrolled data used in path expression

[ArshVermaGit]

Potential fix for https://github.com/ArshVermaGit/SentinelOps-Autonomous-DevOps-AI/security/code-scanning/16

To fix this cleanly without changing functionality, add an explicit “safe path” validation helper in LocalGitService and use it in get_repo_status before any filesystem access. The helper should normalize input, reject empty/option-like values, require absolute normalized paths, and require membership in linked repositories. This makes the security boundary explicit at the sink-side and keeps behavior the same for valid linked repos.

Best concrete fix in shown code:

• File: sentinelops-backend/app/services/local_git_service.py
• Add a method like _validate_repo_path_for_fs_access(self, repo_path: str) -> str near _normalize_repo_path / _is_linked_repo_path.
• Update get_repo_status to call this helper first and return the existing “Path is not linked” error payload when validation fails.
• Keep existing os.path.isdir check and downstream logic unchanged.

No router changes are strictly required for this alert once sink-side validation is explicit.

Suggested fixes powered by Copilot Autofix. Review carefully before merging.

[ArshVermaGit]

This is a clean, pragmatic fix that strengthens things exactly where it matters without overcomplicating the flow. I like that you’re putting the validation right inside LocalGitService—it makes the filesystem access boundary explicit and keeps the responsibility close to the sink. The proposed helper feels well-scoped: normalizing input, rejecting weird/empty or option-like values, enforcing absolute paths, and ensuring the repo is actually linked covers all the right bases. Updating get_repo_status to use it while preserving the existing “Path is not linked” response keeps behavior consistent for valid cases, which is great. Overall, this reads like a thoughtful hardening step that improves safety without changing how things work for normal users.