Potential fix for code scanning alert no. 22: Uncontrolled command line

[ArshVermaGit]

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

General fix: ensure no user-controlled value reaches command execution unless validated against strict, command-specific rules. Keep command verb/options hard-coded and only allow sanitized data for designated argument positions.

Best concrete fix here:

1. In sentinelops-backend/app/services/local_git_service.py, harden _sanitize_commit_message to reject commit messages that begin with - (after trim), preventing option-like values.
2. In _run_git, add explicit validation for the dynamic commit -m <message> path:
   • Require exactly 3 args when using commit-message mode.
   • Ensure args[2] equals its sanitized form from _sanitize_commit_message.
   • Reject if invalid.
3. Keep existing behavior otherwise unchanged (same endpoints, same git command set, same return shapes).

This addresses both alert variants, since both routes flow through the same commit_and_push -> _run_git path.

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

[ArshVermaGit]

This looks like a sensible, targeted hardening change. Rejecting commit messages that begin with - after sanitization is a good safeguard against option-like input, and adding explicit validation around the commit -m <message> execution path in _run_git makes the command contract much clearer. I like that the fix keeps the command shape tightly constrained (exactly 3 args, sanitized message verification) without changing endpoint behavior or expanding the allowed command surface. Since both alert paths converge through commit_and_push -> _run_git, centralizing the validation here feels like the right place to address it with minimal functional impact.