Security findings
Vulnerabilities and policy violations surfaced by pipeline scans, tracked per repo and per team.
How findings are created
Every push runs through platform-level scanning: secret scanning, dependency vulnerability scanning, container image scanning, and policy compliance checks. When a scanner finds something, it produces a finding — attached to the repo, visible to the team, and tracked over time.
What blocks vs. what advises
Not everything is equal. Some findings are too dangerous to let through:
| Scan | Severity | Effect |
|---|---|---|
| secret-scan | any | blocks push |
| dep-scan | CRITICAL | blocks push |
| dep-scan | HIGH | advisory — reported, doesn't block |
| policy-scan | any | advisory — reported, doesn't block |
Hardcoded secrets always block — there is no bypass. CRITICAL CVE blocking can be temporarily overridden via an org-level emergency bypass (1, 4, or 24 hours, audit-logged). This is for genuine emergencies — a production hotfix that can't wait for an upstream patch.
Where to find them
Repo level: each repo's Security tab shows its current findings. This is where developers see what needs attention in their repo.
Team level: the team Security view aggregates findings across all repos the team owns. Team leads use this to track overall security posture without digging into every repo individually.
Reachability analysis
Not every CVE is exploitable. A vulnerability in a function your code never calls is noise, not risk. gittan's dependency scanner includes LLM-based reachability analysis: for each vulnerability, it finds which source files import the affected package, then analyzes whether the vulnerable code path is actually reached and whether user-controlled input flows into it.
Reachability changes how findings are classified:
| Reachability | Fix available | Action |
|---|---|---|
| Reachable | yes | blocks push |
| Reachable | no | warning |
| Not reachable | any | info — tracked, not blocking |
| Unknown (LLM unavailable) | any | falls back to severity-based classification |
Each finding in the scan output shows its reachability verdict — "reachable", "not reachable", or "reachability unknown" — along with a confidence level and explanation. When the LLM is unavailable, the scanner falls back to severity-only classification (CRITICAL blocks, everything else warns).
Finding lifecycle
Findings are created by scan results and cleared when the underlying issue is resolved — dependency upgraded, secret removed, base image patched. There's no manual dismiss button. Fix the issue, push again, and the finding disappears.
This is deliberate. A "dismiss" button trains teams to click away problems. If a finding is a false positive, the right fix is an allowlist in the scanner config, not a UI checkbox.