Who Should Own and Fund a DevSecOps Program?

TL;DR

DevSecOps needs clearly assigned ownership, funding, and shared participation across security, development, operations, and DevOps teams. Security should be built into organizational practices, automation, tooling, and development workflows, rather than added after deployment. Success also depends on selecting tools that help teams release secure software without reinforcing security’s reputation as an isolated, checklist-driven blocker.

Transcript

Hello, and welcome to this RSA Conference virtual session on DevSecOps: Whose Job Is It Anyway? I am your host, Brenna Dobbins of RSA Conference. During the session, all participants will be in listen-only mode. At the close of the presentation, we will conduct a question and answer session. Throughout the presentation, if you have a question, plea... Read More

Key Insights

• Shared responsibility is not a substitute for ownership because a DevSecOps program still needs a clearly accountable party. If everyone is responsible while nobody owns the program, and separate groups dispute who should pay, the initiative is unlikely to succeed.
• Security is frequently treated as an organizational add-on that reviews applications late in the delivery process. DevSecOps instead places security within development or DevOps teams and incorporates it into automation, tools, and everyday software delivery practices.
• Security teams are often perceived as slowing delivery because they arrive with checklists and controls that other teams may not connect to business value. Improving collaboration requires security practitioners to understand the business and develop solutions that genuinely help developers and delivery teams.
• DevSecOps tool selection and tool operation can belong to different groups. The security team may choose a security product, while development, operations, or DevOps teams are expected to use it, creating unresolved questions about ownership, workflow fit, and funding.
• Cybersecurity has gained attention in boardrooms because major breaches have produced visible consequences for organizations and executives. The panel nevertheless questions whether this increased attention has made security sufficiently important within every business or resolved practical resource and ownership problems.
• Security resources are insufficient for many organizations because effective programs require both skilled people and appropriate tools. Alan Shimel argues that only a handful of Fortune 100 organizations possess the resources needed to perform security well entirely by themselves.
• Secure software delivery is more achievable when security is built in rather than bolted on. This means integrating security organizationally as well as embedding it in automation and tooling, rather than waiting until an application has already reached deployment.
• Open source is a security consideration because organizations widely use it and the panel identifies it as connected to recent security incidents. DevSecOps tool evaluation therefore needs to account for the software components that development teams actually rely on when building applications.

Questions & Answers

Q: Who should own a DevSecOps program?

A DevSecOps program should have a clearly identified owner even though security responsibilities are shared across security, development, operations, and DevOps teams. The session warns that declaring everyone responsible does not establish accountability. The organization must explicitly determine who manages the program, coordinates participating teams, makes tool decisions, and addresses funding rather than allowing each group to point elsewhere.

Q: Why is shared responsibility alone insufficient for DevSecOps?

Shared responsibility is insufficient because responsibility does not automatically establish ownership, decision authority, or a budget. A project can involve many teams while still failing if nobody is accountable for its operation and each group expects another to pay. DevSecOps therefore needs both broad participation and a defined owner who can coordinate decisions, tools, funding, and secure software delivery.

Q: How should security be integrated into software development?

Security should be built into the development process through organizational integration, automation, and tooling. The panel contrasts this model with treating security as a separate function that reviews an application after development or deployment. Placing security within development or DevOps teams helps make security part of normal delivery work and supports the goal of releasing more secure software.

Q: Why do development teams see security as a blocker?

Development teams may see security as a blocker because security has traditionally been associated with slowing processes, arriving late, and presenting checklists whose value is not clearly understood. The panel notes that expediency can take priority over security. To improve the relationship, security practitioners need to understand the business and create solutions that help developers rather than remaining organizationally isolated.

Q: Who should pay for DevSecOps tools?

The session does not prescribe one universal budget owner, but it argues that funding must be resolved explicitly. Security teams often select the tool, while development, operations, and DevOps teams perform the daily use. If every group expects another to pay, the program lacks a workable foundation. Ownership, purchasing authority, operational responsibility, and budget responsibility should therefore be clarified together.

Q: How should an organization select DevSecOps tools?

An organization should evaluate DevSecOps tools according to who will select them, who will use them, and how they support the release of secure software. The security team may lead tool selection, but development, operations, and DevOps teams often operate the tools. Selection must therefore consider practical workflow needs, organizational responsibilities, and an agreed funding source rather than security requirements alone.

Q: How can a company create a DevSecOps security culture?

A company can create a DevSecOps culture by making security a shared role across the IT team while preserving clear program ownership. Security practitioners should understand business and developer needs, integrate with delivery teams, and provide solutions that help their colleagues. The organization should also embed security in automation and tooling, clarify budgets, and move beyond an isolated checklist-based approach.

Q: Why should security be built in instead of added later?

Built-in security connects security work to development teams, DevOps practices, automation, and tooling from within the delivery process. Adding security after an application is developed or deployed preserves organizational separation and can reinforce the belief that security merely delays delivery. The panel presents early organizational and technical integration as a better foundation for helping teams release more secure software.

Summary & Key Takeaways

• DevSecOps addresses a persistent organizational problem: security may be described as everyone’s responsibility while nobody receives clear ownership or budget authority. When security, development, operations, and DevOps teams each expect another group to fund or manage the work, the program lacks the accountability required to succeed.

• Traditional security is often separated from the IT delivery process and introduced only after an application has been developed or deployed. The panel advocates building security into development teams, organizational structures, automation, and tooling so that secure software delivery becomes part of the normal workflow rather than a final checkpoint.

• A successful DevSecOps culture requires security practitioners to understand business and developer needs while changing their reputation as checklist-driven blockers. Organizations must determine who owns the program, establish how tools will be evaluated and funded, and promote shared participation without confusing collective responsibility with accountable ownership.