Let's blame the dev who pressed "Deploy"

Original Article ↗ Hacker News Discussion ↗

A recent global outage triggered by a faulty CrowdStrike update on Windows machines has reignited debate over how critical infrastructure should be secured and who should be held responsible when things fail. Commenters argue that “checkbox” compliance, cyber‑insurance requirements, and management pressure to adopt endpoint security everywhere have created fragile, tightly coupled systems where a single update can ground flights or disrupt 911 services. Many contend that blame should not fall on the individual engineer who hit deploy but on organizational incentives, risk‑shifting contracts, and an immature software engineering culture that grants developers limited authority while expecting them to absorb none or all of the responsibility.

Use of EDR on “dumb” displays & compliance culture

  • Debate over whether airport/check‑in displays should run endpoint security:
    • One side: if an outage of the display causes chaos, it’s mission‑critical and should be monitored like any other networked endpoint.
    • Other side: systems could be isolated, locked‑down, and simplified instead of running heavyweight EDR that itself becomes a failure point.
  • Several commenters say EDR everywhere is often driven less by regulation and more by:
    • Cybersecurity insurance checkboxes.
    • PCI‑DSS and similar audits.
    • Corporate/consultant “best practice” and lowest‑friction audit passing.
  • Others argue that any networked device can be a lateral‑movement foothold, so telemetry/EDR is justified even on seemingly low‑risk machines.

Critical infrastructure, connectivity, and vendor terms

  • CrowdStrike’s own terms disclaim use in aircraft navigation, life‑support, etc.; some see this as standard boilerplate, others as ironic given real‑world deployments.
  • Disagreement on whether critical infrastructure should avoid internet‑connected systems altogether:
    • One camp: critical infra should be offline or on separate networks.
    • Another: large, distributed systems (traffic control, networks) inherently need wide connectivity; perfect isolation is unrealistic.
  • Some note that even air‑gapped systems get EDR pushed onto them, driven by the same checkbox/“do it everywhere” mentality.

Blame, responsibility, and process failure

  • Broad agreement that “blame the dev who pressed deploy” is shallow:
    • If one person can brick thousands of machines with a single action, the system and processes are defective.
  • Dispute over how much responsibility individual developers should bear:
    • Some argue developers must own the consequences of their code, push back on unsafe timelines, and be willing to say “no.”
    • Others stress that developers lack real authority, are overruled by managers, and work under time/cost pressure; responsibility should follow decision‑making power and compensation.
  • Comparisons to licensed professions (structural engineers, doctors):
    • Some see software as too under‑defined and fast‑moving for similar liability models.
    • Others note we already have safer languages and methods, but organizations won’t pay for them.

Blameless culture vs punishment

  • Several criticize the article (and broader discourse) as ragebait focusing on CEOs vs devs instead of systemic improvement.
  • Support expressed for blameless postmortems: assume good intent, analyze information, tools, and processes that allowed failure, rather than scapegoating individuals.