Security is a pipeline step, not a product tier

On most git hosting platforms, security scanning is a premium feature. GitHub's Advanced Security costs extra per committer. GitLab's security dashboards are Ultimate-tier only. The message is clear: security is for enterprises that can afford it. Everyone else gets to hope for the best.

This is backwards. Security is not a feature you upsell. It is a baseline that every team needs, regardless of size or budget. A startup with 4 developers is just as vulnerable to a dependency with a known CVE as a bank with 4,000.

Three tiers, clearly separated

gittan's security model has three distinct levels. We are explicit about what each one does, because blurring them creates false confidence.

• ‣ Scanning and reporting — every push, every team. Dependency scanning, license compliance, container image analysis, secret detection. Runs on every push because the org's policies say it runs. Findings go into the team's report, tracked across pushes, visible in the dashboard. This is the baseline. It is included on every plan.
• ‣ Blocking — critical CVEs only. A critical vulnerability in a production dependency blocks the push. The pipeline fails. The code does not land on main. High and below go to the report, not the gate — because blocking on high creates constant friction on CVEs that are usually not exploitable, which drives routine overrides. The rubber-stamp problem, on security.
• ‣ Reachability analysis — available for teams that want it. Is the CVE actually reachable in your code? Full reachability analysis is computationally heavy. It is available as a deeper analysis option, not included in the base tier. Baseline security — scanning, reporting, blocking on critical — is never behind a paywall. Deeper analysis is for teams that need it.

Why critical-only blocking

The instinct is to block on everything. Every CVE is a risk, so block them all. In practice, this creates a wall of red that developers learn to override. A high-severity CVE in a transitive dev dependency that is not reachable in production is not worth blocking a hotfix for. But if the gate blocks it, someone will find a way around the gate — and once the bypass habit forms, the gate stops being trusted.

We block on CVSS critical severity. This is a blunt proxy — not every critical CVE is actively exploited, and not every exploited CVE is rated critical. But it captures the highest-risk findings at near-zero build cost, and the reachability analysis layer adds precision by checking whether the vulnerable code path is actually reached. Everything else goes to the report — scanned, tracked, visible, but not blocking.

The one safe exception

A no-exception block sounds principled until a critical CVE drops with no upstream patch. Now every push in the org is blocked — including the unrelated hotfix your team needs to ship. Unlike a :latest tag, which is always within your control to fix, an unpatched CVE is not.

So the CVE gate has one exception mechanism: a time-boxed, org-level emergency bypass, activated by an admin. The admin records a reason, selects a duration (1, 4, or 24 hours), and the bypass auto-expires. When it lapses, the gate re-fires. This is not a silent skip — it is an audit-logged, time-limited decision. It ties to the vouch-vs-measure distinction from our gated push model: the team owns the decision and is on record for it, rather than silently skipping a check.

Reports that accumulate

A single scan tells you what is wrong right now. What you need is a picture that builds over time: is this team's security posture improving or degrading? Are the same issues recurring? Are findings being addressed or ignored?

gittan maintains security reports per team and per organization. Every pipeline run contributes. A vulnerability that appeared three weeks ago and is still present looks different from one that was introduced and fixed the same day. The report is a timeline, not a snapshot.

Security is a team concern

In many organizations, security is someone else's problem. The security team runs quarterly audits, produces a report, hands it to development, and waits. Development triages against their backlog, deprioritizes most findings, and the cycle repeats.

This does not work. Security findings that are not surfaced to the team that owns the code, continuously, in the tool they already use, will be ignored. Not because the team does not care, but because the feedback loop is too slow and too removed from daily work.

gittan puts security findings in the team's report, updated on every push. The team sees their security posture the same way they see their team metrics — as a continuous signal, not a quarterly surprise. When security is part of the daily workflow instead of a separate process, it actually gets addressed.