Trusted Insider Access

## Read the scenario precisely A contractor with legitimate commit rights changed two lines in a batch job and approved their own change. Nothing was broken into. That single fact determines which half of your control set is relevant and which half is irrelevant, and an interviewer is listening for whether you can tell them apart. ## The controls that were never in play Every authentication and attribution control confirms that the actor is who they claim to be. The contractor *is* who they claim to be. Multi-factor authentication passed honestly. A signed commit, if required, would carry a valid signature over hostile content, because signing answers who vouches for a change and not what the change does. If the pipeline produced a provenance attestation, it is accurate: this artifact was built by this builder from this repository at this commit. Provenance closes the gap between reviewed source and shipped artifact; here the source itself carries the change, so there is no gap to close. Reproducible builds reproduce it. Dependency scanning has nothing to say, because no dependency changed. Saying this out loud is most of a good answer. Candidates who reach for stronger authentication have not noticed that the attack satisfies every authentication precondition by construction. ## Failure one: separation of duties on a privileged path Self-merge means the only content-inspecting control in the system was removed by the person the control exists to check. The requirement is not that every change needs two people — that rule collapses under its own weight — but that changes to a defined set of high-consequence paths do. Define the set by what the code can reach: anything with production write credentials, anything that moves money, anything that issues or handles keys, anything that produces a released artifact. For those paths the approver must be someone other than the author, and ideally someone from the owning team rather than whoever is available. The corollary that gets forgotten: emergency and break-glass merges must be *possible*, because a rule with no escape hatch gets routed around permanently. They should simply be loud — recorded, alerted on, and reviewed the next working day. ## Failure two: blast radius The reason two lines were enough is that the job already had the authority. It runs nightly with standing write access to the ledger, so whoever controls its code controls the ledger. Reducing that is often more tractable than reducing who can edit the code: - **Narrow the identity.** The job should hold the smallest write scope that its function requires, short-lived rather than standing, and issued at run time rather than stored. - **Constrain by invariant.** A reconciliation job that can only propose entries which a separate service validates against invariants — totals balance, no entry outside a bounded range, no entry against a closed period — turns an arbitrary write into a constrained one. - **Split the change from the run.** Deploying a change and letting it touch production are two events. An approval gate on the production run, held by a different group than the code owners, gives you a second human in the loop even when the code path had only one. ## Failure three: no independent detection If the only system that knows what the ledger should say is the system that writes it, you have no detection at all. The compensating control is an independent recomputation — a separate reconciliation against source records, run by a different service with read-only access — plus alerting on merges into the privileged path list and on runs that touch unusual volumes or accounts. These are detective controls, and they matter precisely because the preventive ones can be bypassed by an authorised person. ## The evidence problem Afterwards, the commit history is your account of what happened, and it is only as strong as your confidence in the identity behind it. A malicious contractor and a stolen contractor session produce identical history. If your investigation and your response — is this a person you dismiss, or an account you disable and a credential you rotate — depend on which one it was, then commit authorship alone cannot settle it. You need corroboration from a different system: session and device records, network origin, the timing against the person's working pattern, and where the stakes justify it, an out-of-band conversation with the human. Build that expectation before you need it; reconstructing it during an incident is how organisations end up accusing the wrong person. ## Contractor lifecycle The last thread is access shape. Contractor access should be scoped to the repositories the engagement requires, time-bounded to the engagement, and reviewed when it changes. Standing broad commit rights that outlive the work is a common finding, and it converts an ordinary staffing event into a supply chain exposure. ## What a strong answer sounds like Name the actor position and what it neutralises; name separation of duties on a defined privileged path rather than everywhere; reduce the job's standing authority; add an independent recomputation as the detective layer; and be explicit that provenance, signing and multi-factor address a different threat entirely.