What Is Logic Bomb?

A logic bomb is code that lies dormant until a condition is met, then executes a harmful action. The condition may be a date, the absence of a particular account, a specific input, or the completion of a count.

It is distinctive among threats in that it is overwhelmingly an insider technique. It requires the ability to place code where it will run, which usually means legitimate development or administrative access.

The recurring pattern

A developer or administrator anticipating dismissal inserts code that triggers when their account is disabled or when their name disappears from a payroll file. Prosecutions of exactly this scenario recur regularly.

Sometimes the motive is leverage rather than destruction — code that makes the person's continued employment necessary, because systems fail in ways only they understand.

Why it is unusually hard to find

It does nothing until it triggers. Behavioural detection has no behaviour to observe. Testing does not reveal it unless the test happens to satisfy the condition. Antivirus has no signature for code written specifically for one environment.

It may also be legitimate-looking code with a subtle condition — a maintenance routine with a date check, an error handler that deletes rather than logs.

The controls are procedural

Code review by someone other than the author, which is the single most effective measure. Separation of duties, so the person writing code is not the person deploying it.

Version control with attribution, so every change has an author and a reviewer. And restricted production access, so code cannot be modified directly on live systems — which is where this most often happens, because it bypasses every other control.

Departure is the moment of exposure

Where someone with development or administrative access leaves on poor terms, reviewing their recent changes is proportionate. So is checking scheduled tasks, database triggers and automation they created.

Access removal on the day matters more here than in most contexts, because continued access allows the code to be placed after the decision to leave is known.

Detection, where it is possible at all

Reviewing scheduled tasks, triggers and automation for conditions referencing dates, account names or employee identifiers. Comparing deployed code against the version control record, which finds anything inserted directly.

Backups are the practical safeguard. Since prevention is imperfect, recoverability — tested, and held beyond the reach of the person who might trigger it — is what limits the damage.

Third-party and contractor code

The same risk applies to code written by contractors, agencies and vendors, and the relationship ending is the equivalent trigger point. Contract disputes over payment have produced exactly this behaviour.

The protections are the ordinary ones plus source code escrow and the right to review: independent review of delivered code, a build you can reproduce yourself, and access to source for anything business-critical. Without those, a dependency on the supplier’s goodwill is a technical risk rather than a commercial one.

Where to start

Establish whether anyone can modify production code or database logic without a review step. Where they can, this threat is available and undetectable.

See insider threat. GuardsArm runs security risk assessments.