CISA boss: Makers of insecure software are the real cyber villains

Perceived Hypocrisy and Institutional Context

• Some highlight the CISA director’s NSA background (including claims of involvement with offensive units) and see it as ironic to now blame vendors for insecurity.
• Others separate past roles from current arguments and view the critique of vendors and “secure by design” rhetoric as broadly valid, though symbolic pledges are seen as mostly PR.

Who Are the “Villains”? Vendors vs Hackers vs Users

• One camp agrees vendors are primary culprits: insecure-by-default products, slow patching, years-out-of-date dependencies, continued use of memory-unsafe languages, and ignoring hardening features are framed as conscious cost-cutting.
• Others argue criminals and social engineering are still dominant attack vectors, and holding developers morally or even criminally responsible for attackers’ behavior is likened to blaming engineers when someone poisons a coffee pot.
• Several suggest responsibility lies with “software development companies” and their management, not individual coders.

Liability, Regulation, and Professionalization

• Strong support from some for product liability and regulation similar to other industries (auto, aviation, medical), including risk-based certifications and “defective product” framing for insecure software.
• Counterarguments warn of compliance theater, strangling startups, and making open source and small vendors legally untenable; existing safety standards (DO‑178, ISO, etc.) are cited as extremely costly.
• Debate over introducing PE-style “software professional engineers” with legal liability and stamps; some see this as overdue, others as impractical and potentially devastating to open source and innovation.

Secure-by-Design Feasibility and Technical Measures

• Some claim writing secure software is now easier (managed runtimes, ORMs, modern TLS, PaaS, containers), so current insecurity reflects bad choices and legacy tech.
• Critics respond that vulnerabilities also come from protocol design, logic flaws, configuration, integrations, and complex ecosystems; true security requires verification, not just safer languages.
• Several note that OS- and container-level sandboxing (seccomp, SELinux, Kubernetes policies) offers high leverage but isn’t systematically required or guided by CISA/NIST.

Broader Systemic Issues

• Discussion of economic incentives (“move fast and break things”), MTBF vs MTTR thinking, and the reality that software is deeply embedded in safety-critical contexts without matching professional or legal standards.
• General agreement that culture, incentives, and governance—more than pure technical capability—drive today’s security outcomes.