The Security Exception That Was Only Meant to Last a Week

작성자

카테고리:

← 피드로
DEV Community · Serguey Shinder · 2026-09-05 개발(SW)

Serguey Shinder

The request was reasonable and the deadline was real. A supplier integration had to go live on the Monday, the standard authentication route needed a change on their side that would take a fortnight to arrange, and somebody proposed a temporary exception: a shared credential, broader permissions than the design called for, and a firewall rule opened wider than we would normally accept. It was documented, it was approved by the right people, and it carried an expiry date two weeks out. Three years later I found it still in place, still working perfectly, and by then nobody in the building could tell me why it existed.

Temporary security exceptions do not get removed because removing them is the one task with no natural trigger. The integration works. Nothing fails, nothing alerts, no customer complains. The person who requested it moved teams, the person who approved it left, and the ticket that recorded the two-week expiry closed itself the day the change went in, because in our tooling the change was the deliverable and the reversal was somebody’s future good intention. The organisation had a clear process for granting exceptions and no process whatsoever for ending them.

What made me uncomfortable was not the individual rule. It was realising we had no idea how many there were. Every audit finding, every deadline, every vendor who could not quite meet the standard had produced its own small permanent deviation, and none of them appeared anywhere as a set. Our security posture on paper was the policy. Our security posture in reality was the policy minus an unknown number of exceptions accumulated over a decade, and the gap between those two things was invisible to everyone, including the people responsible for it.

So exceptions now expire in the system that enforces them, not in a document that describes them. Where that is technically impossible, the review date goes on a calendar owned by a named team, and the exception register gets read out in full at a quarterly meeting where somebody has to say aloud, this is still open, and here is why. It is a tedious meeting. It is also the only mechanism I have found that reliably produces removals.

Nothing in this industry is as permanent as a temporary measure that works.

– Serguey Shinder

원문에서 계속 ↗