Presented by RapidFort & Carahsoft

Federal zero trust programs have concentrated heavily on identities and networks. Agencies verify the user, examine the device and control access to systems.

Avery Lyford believes the next phase must reach deeper—into the software itself.

Lyford, Vice President of Commercial Partnerships at RapidFort, argues that agencies need a zero trust approach to software development and architecture. They must understand where code originated, what components are inside an application and whether those components can be trusted.

That task is becoming more difficult as software development accelerates through AI.

“You’re seeing things happen ten times, 100 times faster,” Lyford said. Organizations cannot solve that challenge by asking security and development teams to work ten or 100 times harder.

“You’ve got to be smarter.”

Automation will be necessary both to build software at that pace and to secure it. The same technology helping developers create applications faster can also help organizations trace components, detect vulnerabilities and apply fixes.

The need begins with a basic change in how software is made.

Modern development is increasingly a process of composition rather than exposition. Developers are less likely to write every line of an application from scratch. Instead, they assemble systems from open-source packages, libraries, frameworks and other reusable components.

That approach allows agencies to develop capabilities faster, but it also creates a supply-chain problem.

A package may present itself as a database, a utility or another familiar building block. The development team must still determine whether the component contains additional code, outdated dependencies or a malicious addition.

Lyford compared the process to prefabricated construction.

An organization may purchase a component that is supposed to be a wall. Before placing it inside a sensitive building, the buyer should confirm that it is actually a wall and does not contain a hidden door.

“You need to know all those building blocks,” Lyford said. “Can you trust them?”

That question is especially important with open-source software.

Open source is foundational to modern development, but free availability does not guarantee security. Lyford compares it to water. Water can be obtained freely from a pond, but most people would not drink it without understanding its quality.

A water utility treats the supply, monitors it and provides confidence that what comes from the tap is safe. Software organizations need a similar approach to open-source components.

They must understand the full source of the code, trace its dependencies and make sure known fixes have been applied.

AI is increasing both the pace of software creation and the number of possible attack vectors. Developers may rely more heavily on packages recommended or assembled through AI tools. Attackers can create malicious components, exploit outdated versions or use tactics such as typo-squatting, in which a dangerous package is given a name that closely resembles a trusted one.

A zero trust software model assumes that a component should not be accepted simply because it is widely used or appears to perform the intended function.

Agencies must verify the foundation before they build on it.

“If you build a building on a bad foundation, you’re going to have a bad building,” Lyford said.

Using cleaner components can also free developers to concentrate on the mission. Teams often spend substantial time returning to applications to patch vulnerabilities and replace unsafe dependencies.

No development organization celebrates patching for its own sake. Its purpose is to deliver capabilities that help the agency accomplish something.

A more secure software foundation reduces the amount of time developers must spend fixing preventable problems and allows them to focus on new mission functionality.

That requires security to move earlier in the development lifecycle.

Traditional cybersecurity has often concentrated on production. Once an application was deployed, security teams monitored networks, searched for attacks and responded to vulnerabilities.

Lyford said agencies now need to “shift left,” bringing security into the development process.

“You can’t test in security at the end,” he said. “You need to design security.”

An application is easier to understand while it is being assembled. Developers can examine individual packages, dependencies and configurations as they add them.

Once all those components have been combined into a complex production system, it may be difficult to take the application apart and determine what is buried inside.

The federal Secure by Design movement captures the general principle, but Lyford argues that agencies and providers need to move beyond the phrase and address the practical work required to execute it.

The building blocks must be secure. Their origins must be traceable. Organizations should know where code was produced, how it entered the application and whether it changed along the way.

“We expect it for everything else,” Lyford said. “Why would you not also expect it for your code?”

Physical supply chains already operate on that principle. Organizations want to know where a product was manufactured, who handled it and whether it was altered during transit. High-security environments apply even more scrutiny to the origins of critical components.

Software supports equally important missions and should receive comparable attention.

Security also cannot stop when the application enters production.

A component considered safe during development may later be found to contain a vulnerability. New attack methods will appear, and adversaries will discover ways to exploit software that previously seemed dependable.

A complete zero trust software architecture must allow the organization to identify new threats, isolate the affected component and protect the system while developers prepare a permanent correction.

That creates a continuous software security lifecycle. Agencies verify components during development, monitor applications after deployment and reassess trust when new information appears.

Zero trust software does not replace identity controls or network security. It expands the model.

Agencies still need to know who is accessing a system and whether the connection is permitted. They must also know whether the system itself was built from dependable components and whether those components remain safe.

In an AI-enabled environment, software can be built, changed and attacked faster than human teams can manually evaluate it. Automation will therefore become essential to maintaining provenance, identifying new weaknesses and applying protections at scale.

The next generation of federal zero trust will be measured not only by who gets through the front door. It will also depend on whether the building was constructed from materials the agency can verify—and whether it can respond when one of those materials is later found to be unsafe.