[BUG] _parse_remote_url fails for SSH remotes with non-git usernames

[NicklasNielsen]

Summary

apm audit --ci --policy org fails to discover the org policy when the git remote
uses a non-standard SSH username (anything other than git).

Steps to reproduce

1. Have a git remote of the form <user>@<host>:<org>/<repo>.git where <user> is not git
2. Run apm audit --ci --policy org

Expected behaviour

The org and host are extracted correctly and the org policy is discovered from <org>/.github/apm-policy.yml.

Actual behaviour

_parse_remote_url returns None because it guards with
if url.startswith("git@"), so _auto_discover returns:

"Could not determine org from git remote"

Root cause

In discovery.py, _parse_remote_url assumes the SSH username is always git:

if url.startswith("git@"):
    host_part, path_part = url.split(":", 1)
    host = host_part.replace("git@", "")

Environment (please complete the following information):

• OS: Windows
• Python Version: 3.13.3
• APM Version: 0.12.2

[danielmeppiel]

Triage assessment

Confirmed real bug. Reviewed by three persona experts (supply-chain security, auth, python-architect) against main (cb83c89) in an isolated worktree.

Verdict

Dimension	Assessment
Real bug?	Yes -- src/apm_cli/policy/discovery.py:672 hardcodes url.startswith("git@"), so any SCP-like SSH URL with a non-git username (enterprise-user@ghe.corp.com:org/repo.git, SSH-config aliases with custom User, legacy ADO git-AzureDevOps@vs-ssh.visualstudio.com:...) returns None.
Security-relevant?	Yes -- fail-open governance bypass. _auto_discover returns outcome="no_git_remote", which audit.py:438 and outcome_routing.py:36-43 explicitly treat as fail-open ("not a failure"). apm audit --ci exits 0 with org-policy enforcement silently skipped. No warning is emitted.
Severity	Low -- requires a non-standard local SSH remote (no remote exploit), but the bypass is unintentional for any GHE/SSH-alias user.
Fix complexity	Small -- regex change + 5-6 new tests + (optionally) a loud warning on the silent-skip path.

Two latent bugs surfaced during review

1. Same git@ hardcoding exists in src/apm_cli/models/dependency/reference.py:675 (_parse_ssh_url uses r"^git@([^:]+):(.+)$"). Should be fixed in the same PR or a follow-up.
2. ADO SSH org extraction is wrong even when the prefix matches. For git@ssh.dev.azure.com:v3/myorg/myproject/myrepo, parts[0] returns "v3" instead of "myorg" (discovery.py:677-678). The HTTPS branch happens to work because https://dev.azure.com/org/... puts the org at index 0, but ADO SSH paths are v3/<org>/<project>/<repo>. This is a pre-existing latent bug independent of [BUG] _parse_remote_url fails for SSH remotes with non-git usernames #1159 -- worth a follow-up issue.

Recommended fix

The codebase already has the correct generic SCP regex at src/apm_cli/cache/url_normalize.py:27-31 (_SCP_LIKE_RE). Reuse it rather than inventing a third ad-hoc parser.

# Sketch (not implemented):
_SCP_REMOTE_RE = re.compile(r"^[a-zA-Z0-9_][a-zA-Z0-9_.+-]*@(?P<host>[^:/]+):(?P<path>.+)$")

# In _parse_remote_url, replace the startswith("git@") block:
m = _SCP_REMOTE_RE.match(url)
if m:
    host = m.group("host")
    path_part = m.group("path")
    parts = path_part.rstrip("/").removesuffix(".git").split("/")
    # ADO-aware: ssh://...azure.com paths start with "v3/<org>/..."
    if host.endswith("dev.azure.com") and parts and parts[0] == "v3" and len(parts) > 1:
        return (parts[1], host)
    if parts and parts[0]:
        return (parts[0], host)
    return None

Test coverage gaps to lock the fix

tests/unit/policy/test_discovery.py:46-95 (TestParseRemoteUrl) currently only covers git@ SSH. Add cases for:

• Non-git SSH user: myuser@github.com:org/repo.git
• GHE custom user with hyphen/digits: enterprise-user1@ghe.corp.com:team/repo.git
• ADO SSH (with the v3/ fix): git@ssh.dev.azure.com:v3/myorg/proj/repo
• ssh:// scheme already handled by the urlparse branch -- assert it still works with non-git user.
• Bare hostname (no @) should remain None -- ambiguous with relative paths.

Process consideration: silent skip is the deeper defect

Even after the parse fix, the broader UX issue remains: when org auto-discovery returns None for any reason (e.g. detached HEAD, no remote at all), apm audit --ci silently skips org-policy enforcement. Consider:

• Emitting a [!] warning when running with --ci and outcome == "no_git_remote".
• Letting policy.fetch_failure_default=block cover this outcome too (currently audit.py:446 only honors it for malformed / cache_miss_fetch_fail / garbage_response).

This is out of scope for #1159 but worth a separate discussion -- it determines whether the bug class "auto-discovery returns None" is loud or silent in CI.

Can we fix it?

Yes, low risk. Scope:

• 1 file changed in src/ (discovery.py), ~10 lines.
• 1 test file changed (test_discovery.py), +5-6 cases.
• Optional: same fix to reference.py:675 and a new test there.
• Optional follow-up issue for ADO v3/ org extraction and for the silent-skip UX.

Happy to take this if assigned. Thanks for the clear repro and root-cause pointer.