Change management
Security belongs in the pipeline, not in a human approval. How gittan separates security verification from code quality — and why the result is stronger.
Two separate concerns
Most platforms conflate two things that should be separate:
- Security — does this change introduce vulnerabilities? Are dependencies safe? Is the container image signed? Are secrets exposed? This is verifiable by machines, deterministically.
- Code quality — is the logic correct? Is the design good? Will this be maintainable? This is a judgment call by the development team.
A pull request merges both into one approval button. The reviewer clicks "approve" and that single action is supposed to cover CVE scanning, image provenance, secret detection, and whether the logic is correct. In reality, how many PRs get approved because you trust the person, because you're short on time, or because the diff looked fine at a glance? The deterministic part gets the same treatment as the subjective part — and neither gets done properly.
Gittan separates these concerns. Security verification is deterministic — it has a right answer, it can be automated, and it must not depend on whether someone had time to look. Code quality is subjective — it benefits from human review, but that review is a development practice owned by the team, not a security gate owned by compliance.
The model
Every push to main runs through a gated pipeline. The push is held until every step passes. If any step fails, the push is rejected — the code never reaches main.
The pipeline verifies what machines can verify: known vulnerabilities, leaked secrets, unsigned images, failing tests. It does not try to judge whether the code is "good" — that is the team's domain, supported by their own development process.
If any step fails: push is rejected, main is unchanged, developer sees the failure in their terminal.
What the pipeline enforces
Org owners define mandatory pipeline steps that apply to every repository. These cannot be removed or overridden by team members or repository owners.
| Control | What it does |
|---|---|
| Secret scanning | Detects hardcoded secrets, API keys, credentials in pushed code |
| Dependency scanning | Checks for known vulnerabilities in dependencies |
| Image scanning | Scans built container images for vulnerabilities |
| Image provenance | Signs images at build time, verifies before deployment |
| Policy scanning | Static analysis for security anti-patterns and supply chain hygiene |
| Tests & build | Team-defined: unit tests, integration tests, type checking, linting |
None of these can be bypassed by individual developers. Org-level policies are injected automatically.
Why not pull requests
Pull requests were designed for open source — where you don't trust the contributor. Inside a team, they create a false equivalence between code review and security verification:
- A human reviewer does not find CVEs. No one reads through transitive dependency trees during code review. Automated scanning does, every time, without fatigue.
- Approval is not verification. Clicking "approve" does not prove the container image is signed, that secrets aren't leaked, or that the base image is patched. Those are machine-verifiable properties — and should be verified by machines.
- PRs can be bypassed. Most git platforms allow admin merge, force push, or branch protection exceptions. Gittan's gating runs at the transport layer — there is no admin override.
What about collaboration?
The most common objection is not about security — it's about the social value of pull requests. Sharing what you're working on. Building a shared understanding. Feeling like a team.
That matters. But pull requests became a proxy for team communication — and now the proxy is mistaken for the real thing. If the main way your team shares context is through PR descriptions and review comments, the problem isn't the lack of PRs. It's the lack of conversation.
Talk to each other. Pair on hard problems. Discuss design before writing code, not after. A PR comment thread is a poor substitute for a five-minute conversation — and tying it to a merge gate makes it worse, because now the conversation is also a blocker.
For the visibility and context that teams need beyond conversation, gittan provides tools that work without blocking anyone:
- Branch diffs — push a branch, the team sees the diff in the web UI. Comment inline, discuss approaches, suggest changes.
- Slack notifications — your team channel gets notified when a branch is pushed, when a pipeline passes, and when something breaks. Everyone stays in the loop without checking a dashboard.
- Org changelog — auto-generated from commits and deploys. The team sees what shipped this week without anyone writing a status report.
- Team metrics — push frequency, pipeline pass rate, deploy cadence. Shared visibility into how the team works, not how individuals perform.
These give visibility into what's happening. But they are not a substitute for actually talking to each other — and neither is a pull request.
Separation of duties
The person who writes the code cannot decide whether it passes. That decision belongs to the pipeline, configured by the org's platform team:
| Role | Can do | Cannot do |
|---|---|---|
| Developer | Push code, add repo-level pipeline steps | Skip org policies, bypass pipeline |
| Team lead | Configure team pipeline templates, manage team secrets | Remove org-level enforced steps |
| Org owner | Define org policies, manage enforced steps, audit log access | Push without passing the same pipeline as everyone else |
Even org owners cannot bypass the pipeline. There is no admin merge, no force push to main, no exception mechanism.
Audit trail
Every change is fully traceable:
- Who — authenticated identity (OIDC, no shared accounts)
- What — exact commits pushed, files changed
- When — timestamp of push and pipeline completion
- Verified by — pipeline result: every step, pass/fail, duration
- Policy version — which org policies were active at the time of the push
Audit logs are accessible to org owners via the web UI and API. They cannot be modified or deleted by any user. See Audit log for details.
Compliance mapping
How gittan's gated pipeline model maps to common change management requirements:
| Framework | Requirement | How gittan satisfies it |
|---|---|---|
| ISO 27001 | A.8.32 — Change management | All changes verified by automated pipeline before reaching production. Org policies define mandatory controls. Full audit trail. |
| SOC 2 | CC8.1 — Changes authorized, tested, approved, implemented | Pipeline gating provides automated testing, security verification, and approval. Git history documents changes. Audit log records authorization. |
| NIS2 | Art. 21 — Supply chain security | Mandatory dependency scanning, secret detection, image signing, and provenance verification. Enforced at org level. |
| DORA | Art. 9 — ICT change management | Changes tested and verified before deployment. Security scanning mandatory. All changes logged with actor, timestamp, and outcome. |
We eat our own cooking
Gittan is built on gittan. Every change to the platform goes through the same gated pipeline our customers use — same org policies, same scanning, same enforcement. There is no separate deployment process for the platform itself.
Related
- Audit log — what gets logged, where to find it
- Supply chain — dependency and image scanning
- Pipeline policies — how org-level enforcement works
- Trust — security measures, data processing, sub-processors
Last updated: October 2026