10 Software Security Practices Built for the Next 250 Years

OPINION

This Cybersecurity Awareness Month’s theme, “Securing the Next 250,” asks us to look beyond vulnerabilities and consider what will make our digital systems resilient for generations.

When I testified before Congress with my L0pht colleagues in 1998, we warned that insecure software could put the systems society depended on at risk. Technology has changed dramatically since then, but the fundamental security questions remain familiar. Where does untrusted data enter? What authority does a component have? Who owns the risk, and how do we know a control worked?

We cannot predict the technology stack of 2276, but we can establish practices that make software trustworthy as technology evolves. These 10 are a good place to start.

Make security part of the architecture.

Secure by designshould describe how a system is engineered, beginning with secure defaults, approved patterns, clear trust boundaries, and controls that make insecure outcomes difficult. When security is introduced near the end of development, it must work against decisions already embedded in the architecture, while built-in controls become part of how the system operates and evolves.
Maintain an accurate picture of what you have. Every organization needs a continuously updated inventory of its applications, open source dependencies, development tools, AI models, and external services, along with clear ownership for critical systems. When a serious vulnerability emerges, teams should be able to determine quickly where the affected component is running, what it can reach, and who is responsible for addressing it.
Verify every line of code. Code should earn trust whether it was written by an employee, generated by an AI assistant, or obtained from a third party. Our research found that 44% of AI-generated coding tasks introduced a known vulnerability, which means organizations adopting these tools need independent security testing that operates at the same speed as development and verifies code before it reaches production.
Make the secure path the easiest path. Developers work under constant pressure to ship, so security controls that produce excessive noise, delay builds, or pull people away from their normal tools will eventually be bypassed. Organizations should put precise feedback, approved components, and validated fixes directly into repositories, pipelines, and coding workflows, making the secure approach the most efficient way to complete the work.
Match security speed to development speed. AI is turning software insecurity into a throughput problem because teams can now produce and change code faster than manual review can follow. Testing, policy enforcement, and remediation therefore need to operate continuously across the development life cycle, with automation handling repeatable work and people concentrating on the complex decisions that require business context and judgment.
Control what enters the software supply chain. Modern applications are assembled from large volumes of code that organizations did not write, and each dependency introduces another relationship that must be understood and maintained. Teams should evaluate components when they enter a build, record their provenance, detect malicious or abandoned packages, and plan for safe upgrades, since an inventory alone cannot prevent risky software from being introduced.
Pay down security debt before it comes due. Veracode’s research found that security debt now affects 82% of organizations, leaving an expanding reservoir of vulnerabilities that have remained unresolved for more than a year. As AI-powered discovery compresses years of vulnerability research into months, leaders need to fund remediation as an ongoing engineering function, define expectations for addressing the highest-risk flaws, and track whether new risk is accumulating faster than teams can remove it.
Measure the risk you remove. Most security programs can report how many vulnerabilities they found and closed, yet those activity measures do not show whether the organization has become safer. More useful measures include how long critical, exploitable flaws remain exposed, whether fix capacity is keeping pace with incoming risk and how quickly teams can reduce exposure in applications tied to sensitive data or essential business operations.
Threat-model the entire AI system. An AI agent includes far more than the model because its identity, permissions, tools, memory, data, runtime, and network access all contribute to what it can ultimately do. Organizations should authorize sensitive actions where they occur, constrain what compromised components can reach, include the runtime in data-flow analysis, and retain enough evidence to determine what the agent did when something goes wrong.
Preserve human accountability. Every important application and accepted risk needs an accountable owner, supported by evidence of the controls applied, tests performed, and decisions made throughout the software life cycle. As machines assume a larger role in writing and modifying code, people must retain enough understanding to challenge the output, recognize unexpected behavior, and demonstrate that reasonable precautions were taken.

Cybersecurity Practices That Can Adapt

The next 250 years will bring technologies that we cannot name today, although the systems built with them will still have inputs, privileges, dependencies, and consequences. Lasting security will come from disciplined engineering, continuous verification, and clear responsibility, supported by people who understand how complex systems fail and know how to question the assumptions behind them.

That hacker mindset has served the industry well, and we need to keep teaching it to developers, defenders, and the next generation of security researchers. The tools and architectures will continue to change, while our responsibility to build systems worthy of trust will endure.