We have a year to fix security everywhere

Advances in large language models are heightening fears that automated tools will soon be able to find and exploit software vulnerabilities at scale, turning today’s already fragile security posture into a much more dangerous environment. Commenters debate whether traditional responses—patching, memory-safe languages, and formal verification—can keep up, or whether deeper changes are needed, such as microkernel-based systems, aggressive dependency reduction, air‑gapped critical infrastructure, and stricter regulation. Many see strong defensive uses for AI as well, but argue that incentives, governance, and real-world complexity make it unlikely that defenses will advance as fast or be deployed as widely as new automated attacks.

LLMs as Offensive Security Accelerators

  • Several commenters report LLMs finding real vulnerabilities in minutes when pointed at production codebases.
  • Concern that cheap, uncensored local models make “for‑loop attacks” feasible: scanning CT logs, altcoin repos, ecommerce stacks, etc.
  • Fear that the “long tail” of obscure bugs in enterprise software and appliances becomes exploitable at scale.
  • Some think the “year” timeline is too generous; others note we’ve been in a similar “last chance to fix security” mode for decades.

Defensive Uses and Their Limits

  • LLMs can help with fuzzing, property tests, code review, and formal proofs, but defenders face organizational friction: approvals, testing, vendor patches.
  • Asymmetry: attackers need one successful exploit; defenders must manage all risks continuously.
  • Suggestion that future “baseline security” may improve once LLMs have shaken out low‑hanging fruit.

Systems, OS Models, and Attack Surface

  • Strong advocacy for microkernels, capability systems, air‑gaps, data diodes, and minimizing trusted code; Linux/Windows seen as fundamentally too large and ambient‑authority based.
  • Others emphasize practical hardening of what exists: defense‑in‑depth, sandboxing, zero trust, app whitelisting, strict network exposure.

Web, CMS, and Dependency Bloat

  • WordPress, ecommerce platforms, and plugins/modules are frequent examples of fragile security; many recommend static sites or “headless CMS” approaches.
  • Objections: non‑technical users rely on rich platforms; static/JAMstack tooling and Git‑centric workflows don’t yet meet their needs.

Languages, Hardware Mitigations, and C/C++

  • Many endorse memory‑safe languages and hardware features like memory tagging; others argue adoption is far too slow.
  • Recurring “don’t write new C/C++” vs. “C/C++ are fine if you’re careful” debate; RAII in C++ is praised, but language complexity and legacy footguns are criticized.

Regulation, Incentives, and Risk Culture

  • Frequent observation: breaches rarely have serious consequences, so businesses optimize for audits and checkbox compliance, not true resilience.
  • Some call for mandatory breach reporting and liability, similar to financial auditing; others note practical difficulty of detecting and reporting all breaches.

Broader AI and Societal Risks

  • Thread branches into worries about AI‑enabled social engineering, bio risks, terrorism, and “great filter”/ASI scenarios, with strong disagreement on how realistic or imminent these are.