This article is based on reporting originally published on MeriTalk in 2018, covering the Federal government’s evolving approach to DevSecOps adoption.
From DevOps to DevSecOps: Why the Shift Matters
As Federal agencies adopt DevOps practices to shorten development cycles and increase deployment frequency, security must be woven into every phase of the process—from design and coding through testing, release, and ongoing operations. Treating security as a final gate before deployment is no longer viable when releases happen continuously.
DevSecOps—a natural evolution of DevOps—addresses this gap directly. Where DevOps combines development and operations into a unified workflow, DevSecOps adds a third, equally important pillar: security. The goal is to break down the traditional silos between development, security, and operations teams so that all three work collaboratively and continuously throughout the software development lifecycle (SDLC). It is both a cultural philosophy and an engineering practice, emphasizing automation, continuous monitoring, and shared responsibility for security outcomes.
Federal Agencies Are Already Embracing DevSecOps
Several major Federal departments were reported to be leading the way in rethinking how they develop and secure applications. The Departments of Homeland Security and Veterans Affairs, along with the General Services Administration and the Environmental Protection Agency, were cited as agencies actively breaking the traditional mold of DevOps to incorporate stronger security practices. Elizabeth Lawler, then Vice President of DevOps Security at CyberArk, highlighted these agencies’ efforts in a piece published by MeriTalk.
The Department of Agriculture (USDA) also moved to formalize its DevSecOps posture, seeking external support as it entered Phase II of its IT Modernization Centers of Excellence (CoEs). In a solicitation released in late July 2018, USDA sought assistance across cloud adoption, infrastructure optimization, data center consolidation, application migration, cloud portfolio management, and explicit DevSecOps support—signaling that DevSecOps had become a procurement-level requirement, not just a technical aspiration.
The Federal Software Factory Approach
One of the most significant architectural shifts accompanying DevSecOps adoption in the Federal space is the move toward a software factory model. Adam Clater, then Chief Architect with Red Hat U.S. Public Sector, described this trend:
“The Federal government has gotten very savvy about software development. What I’m beginning to see in the Federal government, at least in large programs where it is available, is a move to the concept of software factory development.”
— Adam Clater, Chief Architect, Red Hat U.S. Public Sector
A software factory is a unified platform on which software is created, complete with end-to-end automation covering code scanning, testing, and operations. Rather than assembling these capabilities ad hoc for each project, the factory standardizes the pipeline so security and quality controls are consistent and repeatable. Whether owned by the agency or a contractor, the key benefit is rigorous standardization that enables both scalability and improved security posture.
DevSecOps Is a Cultural Change, Not Just a Toolchain
One of the most important—and frequently underestimated—aspects of DevSecOps is that it is fundamentally a cultural transformation. For many agencies, a DevSecOps kickoff meeting may be the first time development, security, and operations teams have ever sat in the same room together. That convergence alone can have a profound impact on communication and shared ownership of outcomes.
Clater offered four practical recommendations for agency managers building DevSecOps programs:
- Start small and build iteratively. Resist the temptation to transform everything at once. Begin with a small, focused team to learn how your organization needs to adapt before scaling the model. Early iterations surface cultural and process friction while the cost of change is still manageable.
- Celebrate success openly. Recognizing wins—even small ones—builds momentum and reinforces the behaviors that DevSecOps depends on, including cross-team collaboration and transparency.
- Fail fast and learn continuously. This is not a license for the initiative to fail; it is permission for developers to commit code, discover it doesn’t meet requirements, and fix it the following day. Small, daily improvements compound into meaningful progress. A constrained footprint and tight feedback loops make course corrections cheap and fast.
- Build organizational adaptability, not just cloud adoption. Technology—especially cloud infrastructure—evolves constantly. Measure success by how well your teams and processes can absorb change, not simply by how many workloads you have migrated to the cloud.
Security Vulnerability Testing Lags Behind Emerging Threats
Even as agencies mature their DevSecOps practices, the fundamental challenge remains: security testing of known vulnerabilities consistently lags behind the emergence of new threats. A report by FreeForm Dynamics and CA Technologies, titled Integrating Security Into The DNA of Your Software Lifecycle, identified behavioral analytics and machine learning as two technologies expected to help close this gap.
“Today security testing of vulnerabilities always lags behind known threats, increasing the requirement for continuous testing throughout the entire software lifecycle. Machine learning (ML) and behavioral analytics may enable more prescriptive lifecycle vulnerability testing. But beyond this, ML could also soon make it possible for apps to be able to make decisions on sensitive data access in real time, essentially helping improve the security of the app as it is being used.”
— Integrating Security Into The DNA of Your Software Lifecycle, FreeForm Dynamics and CA Technologies
The implication for DevSecOps practitioners is clear: static, point-in-time security testing is insufficient. Continuous security validation—integrated directly into the CI/CD pipeline—is the only approach that keeps pace with a threat landscape that evolves faster than any release cycle.
You Cannot Buy DevSecOps—You Have to Build It
Perhaps the most important principle for agency leaders to internalize is one articulated by Booz Allen Hamilton analysts Jimmy Pham and Bill Ott in their examination of DevSecOps myths: you cannot simply procure DevSecOps. It is a methodology, not a product.
Agencies can and should invest in supporting tools—continuous integration platforms, release management systems, static and dynamic code analysis tools—but the tools only enable the capability. It is the cross-functional delivery teams, empowered to collaborate and empowered to own quality and security outcomes, who make DevSecOps real. They are the engine of continual improvement in what is ultimately a cultural and paradigm shift.
Key Takeaways for DevOps Practitioners and Agency Leaders
- DevSecOps integrates security as a continuous, shared responsibility rather than a final checkpoint before deployment.
- The software factory model provides a standardized, automated platform that bakes security and quality controls into every build.
- Cultural change—getting development, security, and operations teams collaborating—is as critical as any technical implementation.
- Start with small, iterative pilots; fail fast; and measure adaptability rather than just feature delivery.
- Machine learning and behavioral analytics are emerging capabilities for continuous, prescriptive vulnerability testing, though their maturity and adoption in Federal environments should be evaluated carefully.
- Tools enable DevSecOps; empowered, cross-functional teams make it work.