Overcoming Cultural and Contracting Barriers to Speed and Security

Original broadcast 8/20/25

Presented by Second Front Systems & Carahsoft

On the contracting side, Conner points out that government acquisition has traditionally been shaped by years of training that favor well-defined, long-term projects. The dominant model often demands firm fixed-price contracts with fully scoped deliverables. While this approach transfers risk to the contractor, it undermines the agility that DevSecOps is designed to provide. The methodology thrives in environments where teams can adapt to change, manage evolving requirements, and iterate quickly—conditions that rigid contracts don’t support.

The good news, Conner says, is that the right contracting mechanisms already exist. Options like Small Business Innovation Research (SBIR) programs, Strategic Funding Increases (STRATFI), Tactical Funding Increases (TACFI), other transaction authorities (OTAs), and Cooperative Research and Development Agreements (CRADAs) all allow for more collaborative, flexible development. These vehicles make it possible to co-develop features with agency partners, deliver capabilities at speed, and adjust course as needed.

The challenge is that these mechanisms are underutilized. Conner attributes this to a mix of scrutiny, regulatory burdens, and fear of stepping outside the comfort zone. Acquisition professionals may worry about making the wrong call, or about the perception of risk in using nontraditional pathways. As a result, the big, slow integration contracts remain the default in many cases, even when faster, more adaptive options are available.

Leadership, Conner argues, has a key role to play in changing this dynamic. Senior leaders need to signal clearly that they want fewer massive, multi-year integration contracts and more small, calculated bets that deliver quick wins. This tone from the top, combined with concrete examples of success, can create a “flywheel effect”—once one organization demonstrates rapid, secure delivery using flexible contracts, others will follow.

On the cultural side, Conner sees another set of hurdles. Many security personnel are still oriented toward discrete, static environments. They’re used to managing hardware and software inventories in fixed configurations and producing compliance documentation—often in the form of PDFs or spreadsheets—that is outdated as soon as it’s generated. In cloud-native, ephemeral environments, this mindset is a mismatch.

The heart of DevSecOps is constant change. Code, infrastructure, and configurations are updated continuously. In this environment, security cannot be a snapshot in time; it must be a continuous process. Conner believes there’s a significant opportunity for upskilling security teams to overcome the fear, uncertainty, and doubt that comes with dynamic systems. By providing real-time risk insights and building familiarity with continuous monitoring, agencies can align security practices with the realities of modern development.

This shift also requires a change in how risk is understood. Instead of viewing systems as isolated assets, security teams need to evaluate risk in terms of mission outcomes. The focus should be on whether a capability can deliver its intended function securely and reliably, not just whether individual components meet compliance standards. This outcome-based approach aligns security goals with operational priorities, ensuring that risk management supports, rather than delays, mission delivery.

For Conner, continuous insight into risk posture is “table stakes.” It’s not enough to know the vulnerabilities present at a single point in time. Leaders need a steady, accurate view of how their systems are operating, how they’re changing, and what those changes mean for security. Modern platforms can provide this visibility, but only if agencies are willing to adopt them and integrate them into their processes.

When asked how success should be measured, Conner returns to the idea of outcomes. Delivering a secure end product is important, but delivering it iteratively—so that it’s already in use and delivering value while continuing to improve—is even better. This responsiveness to change, coupled with ongoing security assurance, is what separates DevSecOps from traditional development approaches.

Ultimately, Conner’s message is one of opportunity. The government has the tools, the contracting authorities, and the technological capabilities it needs to deliver secure software at speed. What’s required now is a willingness to change how people work—embracing flexibility in acquisition, empowering leaders to take calculated risks, and upskilling security personnel for a continuous delivery world.

If agencies can overcome these cultural and contracting barriers, Conner believes they can fully realize the promise of DevSecOps: delivering mission-critical capabilities faster, more securely, and with the adaptability to meet evolving needs. And in a world where both threats and opportunities emerge rapidly, that adaptability may be the most important capability of all.

Key Takeaways

• Cultural inertia and rigid contracting practices are bigger obstacles to DevSecOps adoption than technology.

• Flexible acquisition vehicles like OTAs, SBIRs, and CRADAs are available but underused.

• Continuous, outcome-focused risk insight is essential for secure, agile delivery.