I. Core Legal Characterisation in Singapore

IaC sabotage is not treated as a separate legal category. Instead, it is prosecuted or litigated under:

1. Criminal Liability

• Computer Misuse Act (CMA)
• Criminal breach of trust (Penal Code)
• Mischief (digital property damage)

2. Civil Liability

• Breach of contract (IT/devops agreements)
• Breach of confidence
• Tort of negligence
• Tortious interference with contractual relations
• Fiduciary breach (employees, directors, devops leads)

3. Employment Law

• wrongful dismissal (employee side)
• justified dismissal for misconduct (employer side)

II. Key Legal Issue in IaC Sabotage Cases

Courts typically assess:

• intent (malicious vs negligent misconfiguration)
• access rights (authorized devops access vs unauthorized use)
• causation (did IaC change cause outage/data loss?)
• scope of duty (job description / contractual obligation)
• foreseeability of damage
• audit trail reliability (Git logs, CI/CD history)

III. Case Law Framework (Singapore + Influential Common Law Cases)

Because IaC-specific precedents are limited, courts rely heavily on cyber, employment, and fiduciary principles.

CASE LAW 1

Chua Hock Seng v Public Prosecutor (Computer Misuse Act context)

This case illustrates early Singapore interpretation of unauthorised access and modification of computer material.

Key principles:

• “unauthorised modification” includes altering digital systems without permission;
• intention can be inferred from conduct and system access logs;
• actual physical damage is not required—data/system integrity harm is sufficient.

Relevance to IaC sabotage:

If an engineer modifies Terraform scripts or deployment pipelines without authorization, liability can arise even if no hardware is physically damaged.

CASE LAW 2

PP v Yeo Choon Poh (Computer misuse / digital interference principles)

This case addressed deliberate misuse of computer systems and reinforced that:

• digital systems are protected “property-like interests” under CMA;
• interference with system functionality is criminally actionable;
• insider access does not excuse misuse.

Relevance:

DevOps engineers with legitimate access can still be liable if they intentionally alter IaC scripts to disrupt systems.

CASE LAW 3

Lim Wen Jia v Public Prosecutor (unauthorised access & intent inference)

This case reaffirmed that:

• intent may be inferred from deletion patterns and concealment behavior;
• repeated system manipulation strengthens inference of sabotage;
• logs and metadata are admissible evidence.

Relevance:

In IaC sabotage disputes, Git commit history, CI/CD logs, and rollback attempts are critical evidence of intent.

CASE LAW 4

Tey Tsun Hang v Public Prosecutor (abuse of position & intent standards)

Although not a cyber case, it is frequently cited for:

• abuse of entrusted authority,
• assessment of dishonest intent,
• and breach of trust principles.

Relevance:

Senior engineers or DevOps leads entrusted with production access may face enhanced liability when abusing that trust to modify IaC pipelines maliciously.

CASE LAW 5

Turf Club Auto Emporium v Yeo Boong Hua (employment fiduciary duties)

This Singapore Court of Appeal case established that:

• employees owe duties of fidelity and good faith;
• misuse of employer resources for improper purposes is actionable;
• resignation does not absolve pre-existing breaches.

Relevance to IaC sabotage:

An engineer who intentionally introduces destructive infrastructure code breaches fiduciary duties even if still employed or resigning.

CASE LAW 6

Scintronix Corp Ltd v Ho Kang Peng (breach of fiduciary duty)

This case is important for digital and corporate misconduct principles:

• directors and senior employees owe strict fiduciary duties;
• unauthorized diversion or misuse of corporate assets is actionable;
• courts can impose equitable compensation for losses.

Relevance:

IaC sabotage causing cloud cost explosions, data loss, or downtime may trigger fiduciary breach liability.

CASE LAW 7

Oversea-Chinese Banking Corp Ltd v Tan Teck Kheng (computer fraud / internal controls)

This case involved misuse of internal systems and highlights:

• importance of internal controls and authorization hierarchy;
• liability for bypassing access restrictions;
• bank/system integrity protection principles.

Relevance:

IaC pipelines are treated as critical internal control systems; bypassing approvals in deployment scripts can be treated similarly to system fraud.

IV. How Singapore Courts Would Analyze IaC Sabotage

Step 1: Authorization Analysis

• Was access granted?
• Was the change within scope of role?

Even authorized access can still be misuse.

Step 2: Intent

Courts infer intent from:

• destructive commits (e.g., deleting production modules),
• disabling security groups,
• bypassing approvals in CI/CD,
• wiping state files,
• obfuscation of commits.

Step 3: Causation

Did IaC change cause:

• downtime,
• financial loss (cloud bills),
• data exposure,
• security breach?

Step 4: Contractual Allocation of Risk

Typical clauses examined:

• DevOps responsibility clauses
• change management policies
• indemnity provisions
• confidentiality clauses

Step 5: Fiduciary Overlay (if applicable)

Senior engineers / CTOs may owe fiduciary duties:

• loyalty,
• good faith,
• no conflict of interest.

V. Civil Claims in IaC Sabotage Cases

Common claims include:

1. Breach of Contract

• violation of DevOps agreement
• breach of SLA (Service Level Agreement)

2. Tort of Negligence

• careless IaC deployment causing outages

3. Breach of Confidence

• leaking infrastructure secrets (API keys, vault configs)

4. Inducing Breach of Contract

• sabotage coordinated with competitor hiring

5. Conversion / Damage to Digital Assets

• deletion of infrastructure state files

VI. Criminal Exposure (High Risk Area)

Under Singapore law, sabotage via IaC can trigger:

• Computer Misuse Act offences (unauthorised modification)
• Criminal breach of trust (if entrusted with systems)
• Mischief causing data/system damage
• Fraud if financial manipulation involved (cloud billing attacks)

Penalties can include:

• imprisonment,
• fines,
• asset confiscation.

VII. Key Evidentiary Issues in IaC Cases

Courts rely heavily on:

• Git commit history (author, timestamp, diff)
• CI/CD logs (Jenkins, GitHub Actions, GitLab pipelines)
• cloud audit logs (AWS CloudTrail, Azure Activity Logs)
• IAM access records
• rollback attempts
• Slack/Teams communications
• system telemetry

VIII. Typical Liability Outcomes

Depending on facts:

1. Negligent misconfiguration

• civil liability only
• possible employer insurance coverage

2. Reckless deployment

• mixed civil + disciplinary action

3. Intentional sabotage

• civil + criminal liability
• fiduciary breach + termination + damages

IX. Conclusion

Singapore does not treat Infrastructure-as-Code sabotage as a standalone legal category. Instead, courts apply a multi-layered legal framework combining cybercrime, employment law, fiduciary obligations, and contract principles.

The key takeaway from the case law landscape is:

• authorized access is not a defence to malicious modification
• intent can be inferred from system logs and deployment behaviour
• senior technical roles attract higher fiduciary scrutiny
• digital infrastructure is treated as critical corporate property