Where K-ISMS Collides With GitOps — Six Conflict Points
GitOps stands on the proposition that *git is the single source of truth*. Some K-ISMS controls collide with that proposition directly. Six points and the workarounds.
Last fall a Korean public agency tried to adopt GitOps. Six months later they withdrew. Not for technical reasons — for collision with K-ISMS certification controls.
This post walks the six collision points. Global GitOps material doesn't cover this — it only matters in Korean and Japanese public-sector contexts.
Collision 1 — the approver and the actor cannot be the same person
K-ISMS includes segregation of duties — the person approving a change must not be the person applying it.
The standard GitOps flow:
- Developer opens git PR
- Reviewer approves (merge)
- CD system auto-deploys
The global interpretation: the approver is human and the actor is automation, so SoD spirit is satisfied. The K-ISMS auditor majority interpretation: automation runs under a human's authority, so the same person ends up doing both.
Workaround: require two or more PR approvers, and have one of them manually trigger the deploy. Don't let the machine automate it.
Collision 2 — change records in git alone are insufficient
GitOps assumes git is the single source of truth. Change history lives in git log.
K-ISMS change control: change records must live in an access-controlled separate system in tamper-evident form. Git itself permits force-push, so it's interpreted as tamperable.
Workaround: at git push reception, simultaneously record commit hash and author in a separate append-only audit log. Even if force-push happens, the audit log preserves the original hash.
Collision 3 — sensitive data must not live in git
GitOps puts config in git alongside code. K-ISMS requires sensitive config (DB endpoint, internal IP, auth keys) to live in an access-controlled separate secret store.
Workaround: GitOps repository contains placeholders only, actual values are Vault / KMS references. CD-time injection.
This is nearly standard, but at audit time, each placeholder must be individually verified as pointing to a real key. Without automation, this is several days of work per quarter.
Collision 4 — access revocation must be immediate
K-ISMS — user access revocation must occur within 24 hours of departure.
GitOps — even if a user loses git push permission, commits already pushed remain valid. Auto-deploys triggered after departure from those commits are possible.
Workaround: build into the offboarding process a separate review of that user's commits in the last 24 hours. Or enforce a staging tier where auto-deploy doesn't happen within 24 hours.
Collision 5 — periodic audit reports don't generate from git
K-ISMS — quarterly audit reports of access, change history, and security events.
GitOps's git log alone doesn't automatically produce these reports. The report must prove human review — not raw data dump but a signed audit result.
Workaround: quarterly automatic data dump followed by signed human review. Without automating this workflow, several days of human effort each quarter.
Collision 6 — using external git hosting itself is a control violation
The last and most awkward — K-ISMS requires sensitive assets to remain in-country. GitOps repositories hosted on github.com or gitlab.com SaaS are interpretable as sensitive assets located abroad.
Workaround: GitOps over internal git servers (self-hosted GitLab, Gitea, on-prem Bitbucket). This isn't a workaround. It's the only option.
So is GitOps adoption impossible?
Not impossible. Just don't follow the global GitOps guide as-is. The six workarounds above must enter the initial design. Adding them six months later means disassembling existing GitOps infrastructure.
We've seen one Korean public agency that built the workarounds from day one. Took longer — 8 months vs the typical 6 — but passed audit on the first try.
If you're a security or DevOps lead at a Korean or Japanese public-sector or financial institution evaluating GitOps, the six collision points above are the checklist to run before opening any global GitOps guide. Start without knowing them and you'll discover them during the K-ISMS audit — at which point the only fix is disassembling the GitOps infrastructure you've already built.
Related posts
How Much of "Git Is Risky, SVN Is Safe" Holds Up? An Operations Comparison Table
Security comparisons of Git and SVN mix two separate questions: where the repository runs and what gets replicated to developers. Using official documentation, this post compares five items in a table (internal hosting, local copy scope, per-path read separation, egress, access revocation) and ends with a checklist for a source control security review.
John Baek
Is Git Safe for Government Agencies on an Internal Network? What the Public Record Says
Asked whether Git can run in a closed network at all, I checked the official docs, government announcements, and procurement records. The answer is yes, internal-network Git can be operated safely. Here are the evidence, the two design decisions that make it so, and a question list for security reviews.
John Baek
But We Lock Files Before Editing — Moving from Lock-Based SCM to Concurrent Development
There's a question we get in almost every public-sector meeting. We lock a file before we touch it — so how does your solution work? On the difference between lock-based and branch-merge models, how control survives without locks, and a migration path that doesn't throw away history.
John Baek