The message hit the team chat at 9:41 on a Tuesday night: the staging build had failed, and the failure log held something no build log should ever carry — a cloud access token, printed out in full. NyaayaStack, the four-person legal-tech team behind a case-tracking app used by district court practitioners, had just met the problem DevSecOps exists to solve: keeping software safe by wiring checks into the delivery path itself, so that each change is inspected, traceable and fit to ship, instead of waiting on a separate security review that always arrives too late. What happened across the next six days taught them more than any policy document.

The Detail That Gave It Away

Nobody at NyaayaStack had set out to be careless. Like thousands of small teams, they had copied a workflow snippet from a blog post back in 2023 and never revisited it. The snippet used a popular GitHub Action to list changed files on every pull request. It worked, quietly, for two years. What they did not know was that in March 2025 that same action — tj-actions/changed-files — was compromised in a genuine supply-chain incident, and that secrets flowing through it could end up spilled into build logs. CISA’s guidance afterwards was blunt: assume exposure, rotate the credentials.

The token in question gave read access to their object storage — which, for a legal product, meant scanned court filings, client correspondence and identity proofs. For an hour the mood in the room was grim enough that one engineer joked it came close to criminal intimidation under Section 506, though nobody had actually threatened anybody. Joke aside, the obligation matched a lawyer’s after any data incident: act fast, document everything, tell the truth in that order.

What DevSecOps Would Have Caught Earlier

Postmortems are only worth the checks they produce. The team drew up a short list of what a wired-in pipeline would have done for them long before that Tuesday:

• A pre-commit secret scanner on every laptop, so the token never enters git history at all.
• Server-side push protection on the remote, as a second gate that catches what humans miss.
• Actions pinned to full commit SHAs, so a force-pushed tag cannot quietly swap the code they think they are running.
• Per-job permissions, so a leak in one workflow cannot read everything the organisation owns.

Each of those is a small, cheap control. None of them requires hiring a security department. All of them sit inside work the team already does — which is the entire point. Protection stationed where the risk actually lives beats protection parked in an end-of-project review, and India offers a tidy non-software parallel: when courts faced rising threats, Uttar Pradesh moved to raise a dedicated security force for its civil courts. Stationed guards outperform visiting inspectors. Delivery pipelines are no different.

For two days afterwards the team did nothing but forensics. They pulled three months of workflow logs, listed every credential that had passed within reach of the compromised step, and rang the two client firms whose files sat in the affected bucket. The founder, a former litigator, said the exercise felt oddly familiar — the same discipline as preparing a sworn affidavit: dates first, documents second, claims last. By Thursday they could state, in writing, what had and had not been exposed. That statement, dull as it reads, became the centrepiece of every client conversation that followed.

Rotate First, Rewrite Later

The instinct after a leak is to scrub the repository — rewrite history, purge the token from every commit, pretend it never existed. The team’s advisor, a veteran of several such nights, stopped them cold. Order of operations matters: rotate the credential first, because a key in a stranger’s hands is live risk, while the same key sitting in old commits is only potential risk. History rewriting came second, on a quiet Friday, with the old token long dead and every placeholder verified.

One detail genuinely surprised them: on GitHub, push protection can be bypassed, and by default any writer on the repository can do the bypassing. The override is one click, and it lands nowhere the team thought to look. Convenience is a design choice, and it carries a price tag. Knowing this, NyaayaStack added a weekly five-minute review of bypass events — calendar-blocked, done with the morning chai before anyone opens an IDE.

DevSecOps Evidence, Kept Like a Case File

A junior advocate learns early that a case survives on evidence: who filed what, when, and before whom. The team began treating releases the same way. Every build now leaves a record of what went into it. Every exception to a rule names a person responsible and a date when it lapses — the cap is ninety days, taken from a template the team bent to fit their stack. Pre-existing findings, the backlog of old problems, are tracked as ordinary work; they never block a merge, because blocking on ancient debt simply trains people to override the gate, and a gate people override is a gate that has already died.

The rule they settled on is narrow by design: a merge stops only when a finding is new, severe, fixable, and the checker is confident it is neither noise nor a false alarm. Everything else becomes a ticket with a name attached. Since that week, the pipeline has stopped three merges. All three were real problems. Nobody has argued with it yet — which, for any rule in any workplace, is the highest praise going.

Procedure, Not Heroics

Practitioners of law will recognise the pattern underneath all of this. Courts do not stay safe because judges are heroic at spotting forgery; they stay safe because procedure makes forgery hard — registry checks, filing counters, numbered orders, signed copies. The team rebuilt its pipeline in the same spirit and wrote the parallels on the office whiteboard:

1. Every filing gets a stamp — every build gets a record of its inputs and its result.
2. Every exception needs a judge’s order — every gate override needs a name and a reason.
3. Limitation periods end disputes — exception tickets expire after ninety days.
4. Original documents stay in the registry — secrets stay in the vault, never in code.

None of this slows the team down in any way they can feel. Builds still finish while the coffee is still hot. What changed is that shortcuts now leave marks, and marks are exactly what you want when the question “what exactly happened?” arrives — as sooner or later it does in every system, legal or otherwise.

Where the Court Analogy Runs Out

There is a limit, and being honest about it matters. What the team built is delivery-side defence: checks that run while software is being written, built and shipped. Watching a running system for intruders, ranking vulnerabilities across an entire estate, or answering an auditor’s checklist are separate disciplines with separate tooling — excellent things, just not this thing. Readers who want a fuller map of the territory, from definitions to the placed-controls model to supply-chain records, will find an atlas entry that lays out DevSecOps end to end, and it is more careful about boundaries than most vendor copy.

“We stopped treating security as a department that would someday visit us,” the team’s lead wrote in the postmortem, “and started treating it as procedure — the way limitation periods are procedure. It lives in the calendar, it belongs to everyone, and it fails loudly.”

Six Days, Five Habits

The scare had gone quiet by the following Monday. The token was dead within the hour, the history rewrite took an afternoon, and the new checks landed inside a week. What remains is habit, and habit is the true product of that bad Tuesday:

• Mornings start with the roundup of Indian legal developments — followed by a glance at the previous night’s build records.
• Every new dependency and Action gets reviewed before its first run, never after its first failure.
• Secrets live in the platform’s vault; never in code, never in chat, never in a spreadsheet.
• Every gate rule names an owner; every exception names a date.
• The postmortem stays blameless, because the goal is a safer pipeline, not a quieter team.

Small practices often assume this kind of discipline belongs to enterprises with badges and budgets. It does not. It belongs to whoever would be embarrassed, in front of clients and the bar, to explain why a credential sat in a log file for the better part of a year. Courts ask that question of evidence every working day. Clients, quite reasonably, ask it of software too. And the deeper lesson cost nothing: put checks where the work happens, keep exceptions on the record, and treat trust in any control as something earned by watching it behave, month after month, rather than assumed at purchase.