Safety

AI-generated text

From Damage Control to Early Design: Embedding Security in Software Creation

The security conversation has shifted from preventing attacks to detecting and containing them, a dynamic Tim O’Brien compares to the opening of The Empire Strikes Back.

From Damage Control to Early Design: Embedding Security in Software Creation

Tim O’Brien observes that the language of the security industry has moved away from stopping threats toward measuring detection windows, response times, and mean time to remediate. That framing emphasizes damage control over active prevention.

A cinematic analogy: defending a lost base

O’Brien uses a well‑known film scene to illustrate the current posture: a frozen‑planet underground base facing unstoppable mechanical walkers. The defenders focus on getting a broken ship running so they can escape rather than mounting a counterattack. The image (with an image assist credited to Anthropic) reflects his view that today’s InfoSec conversation often aims to slow an attack just long enough to survive.

How the situation arose

Security teams have frequently been handed completed systems and asked to defend them, rather than participating in the architectural decisions. As development choices shifted — new stacks like Node.js, different relational databases, or the adoption of large language models — security was often given the task of retrofitting protections.

At the same time, developers are producing far more code, sometimes aided by AI, than in prior years. That pace makes it unrealistic to treat security as an afterthought that can catch up later.

"Machine speed" and automated coordinated attacks

O’Brien explains that “machine speed” means automated agent networks can perform reconnaissance, assemble exploit chains, and coordinate attacks in seconds. He gives concrete examples:

  • One agent finds a zero‑day in FFmpeg and stores it privately.
  • Another scrapes the team’s LinkedIn and X accounts and identifies who will be on vacation.
  • A third logs a nightly load balancer latency spike as cover for an attack.
  • A fourth analyzes past incident reports and estimates a 30‑minute detection window.

What once required a dedicated red team and weeks of planning can now be continuous background processing: interconnected agents (named examples include Nanobot, Picobot, Hermes, or OpenClaw) gather data, update shared memory, and a coordinating agent decides when to strike.

O’Brien’s practical warning: if you run a website, avoid posting travel plans publicly.

Current defenses and their limits

Most industry responses remain defensive: tighten npm signing, fund Maven repositories, support projects like Akrites through the Linux Foundation, and add more scanners to CI pipelines. These efforts are valuable, but O’Brien argues they are insufficient on their own.

The essential transformation is to bring security into software creation. That means security professionals should influence tech stack choices and early design decisions — for example, having an informed position on React, Vite, Tomcat, Node.js, and databases — because those choices determine the attack surface that automated agents will exploit.

Practical implications

  • Security should stop being only a support function that reviews finished software; it must participate in architecture and design.
  • Continue supporting package and repository security projects, but pair those with earlier involvement in development workflows.
  • Operational hygiene matters: limit publicly available information that automated reconnaissance agents can use.

Conclusion

O’Brien’s core message is that information security needs to transition from late‑stage inspection and faster incident response toward being present at the moment systems are designed and composed. Meaningful risk reduction in an era of AI‑accelerated threats requires embedding security into the building process, not just improving scanners and response teams.