How to Embed Application Security into DevOps

TL;DR

Embed application security directly into developers’ existing tools and automated workflows so testing becomes iterative and scales across more applications. Security teams should define policies, establish guardrails, and help developers automate against them, because separate tools and end-stage scans cannot keep pace with frequent code changes, microservices, dependencies, containers, and expanding software supply chains.

Transcript

No? Okay, now? Better. Okay, great. Hopefully you can hear me now. Um, I'll go ahead and get started. I wanna thank y'all for, um, sticking with me and, and joining me in the afternoon on, uh, after a long, busy week. Appreciate your perseverance. Um, so I'm here to, to talk about DevSecOps, basically. Um, I am a, um, senior security evangelist at ... Read More

Key Insights

• Application security is difficult because security teams can find vulnerabilities but depend on development teams to remediate them. When each group uses separate tools and processes, collaboration becomes harder, findings are disconnected from coding work, and the overall security program struggles to scale.
• The security team’s scalable role is to advocate for security, develop policies, establish guardrails, and help developers automate against those guardrails. Security specialists cannot remain the people who physically run every scan because developers substantially outnumber security personnel.
• Modern development environments use containers, orchestrators such as Kubernetes, smaller code components, source code managers, and Agile methods. These changes increase delivery speed while introducing application-to-application communication, APIs, dependencies, and other attack surfaces that older application security workflows were not designed to manage.
• Source code management enables teams to divide a monolithic application into smaller pieces that multiple developers can work on concurrently. Version control prevents contributors from overwriting one another’s changes, allowing development teams to increase velocity and deliver smaller increments of business value more frequently.
• Microservices require application security to become iterative because developers may change and release small units of code in a day, a week, or an hour. Testing only after multiple contributions are merged creates reconciliation problems and cannot match the cadence of the development workflow.
• Application coverage matters more than concentrating exclusively on scan efficacy for mission-critical systems. One customer believed it scanned about 90 percent of its applications by scanning roughly 200, then discovered it had 1,000 applications, illustrating how unknown or overlooked systems can remain exposed.
• Attackers can enter through an overlooked application rather than directly targeting a mission-critical one, then traverse across the environment. Security teams therefore need visibility across the application portfolio instead of limiting testing to systems already classified as the most important.
• Developer tooling can become a central security control when security processes are embedded where developers already work. Understanding source code management, issue tracking, continuous integration, and broader lifecycle platforms helps security teams communicate in development terms and incorporate testing into automated delivery processes.

Questions & Answers

Q: How can security teams scale application security through developers?

Security teams can scale application security by embedding policies, guardrails, and automated testing into the tools and workflows developers already use. Rather than having security specialists physically run every scan, the security function should advocate for secure practices and help developers automate against defined controls. This model recognizes that developers outnumber security staff and are responsible for remediating identified vulnerabilities.

Q: Why should application security be embedded into developer tools?

Application security should be embedded into developer tools because separate security and development systems make collaboration and remediation difficult. Developers work inside source code management, issue tracking, continuous integration, and delivery environments. Integrating security into those environments connects findings to normal coding work, makes testing more iterative, and helps security controls keep pace with frequent software changes.

Q: How do microservices change application security testing?

Microservices divide applications into smaller units that can be changed and delivered much more frequently than traditional monolithic applications. A developer may complete and move code toward production within a day, a week, or an hour. Security testing must therefore become iterative and align with each change, because testing only after multiple contributions are merged creates timing and reconciliation challenges.

Q: Why is end-stage security testing insufficient for DevOps?

End-stage testing is insufficient because modern development teams continuously work on smaller pieces of code and move them toward production quickly. If security waits until several developers’ contributions have been merged, findings arrive after the relevant work has progressed and must be traced back through combined changes. An iterative security process fits the development cadence more closely and supports earlier remediation.

Q: What role should security professionals have in DevSecOps?

Security professionals should act as advocates who define policies, establish guardrails, and help development teams automate security requirements. Their role should move beyond manually operating every scanner. Because there are more developers than security specialists, scalable security depends on enabling developers to apply controls during their existing workflows while the security team provides direction, standards, and support.

Q: Why should security teams inventory all applications before scanning?

Security teams need an accurate application inventory because perceived testing coverage can be misleading. One customer believed it scanned about 90 percent of its applications because it tested roughly 200, but then discovered that the organization had 1,000 applications. Without knowing the full portfolio, teams may leave many systems untested while incorrectly assuming that their application security program has broad coverage.

Q: Why is scanning only mission-critical applications risky?

Scanning only mission-critical applications is risky because attackers may choose an easier, overlooked entry point and then traverse across the environment. A program focused narrowly on finding every vulnerability in a small set of important systems can miss exposed applications elsewhere. Broader coverage is therefore necessary to address the open windows that may provide access to more valuable systems.

Q: How does source code management support faster development?

Source code management allows a monolithic application to be divided into smaller pieces that different developers can work on at the same time. When contributors check their work back in, version control helps prevent them from overwriting one another. This parallel approach increases development velocity and shortens the path to business value, while also requiring security testing to operate more frequently.

Summary & Key Takeaways

• Application security teams can identify vulnerabilities, but developers are responsible for remediation. Separate tools make that collaboration difficult and prevent security programs from scaling. A more effective operating model places security inside development workflows, where security specialists define policies and guardrails while developers use automation to apply them throughout their normal work.

• Modern development breaks monolithic applications into smaller components that many people can change concurrently. Source code managers provide version control and prevent contributors from overwriting one another’s work. This structure accelerates delivery, but it also creates more frequent production changes, application-to-application interactions, orchestrators, APIs, dependencies, and attack surfaces that security programs must address.

• Traditional testing performed after code is merged or near the end of delivery does not align with rapid, iterative development. Security must become similarly iterative, automated, and embedded. Teams should understand which source management, issue tracking, continuous integration, and delivery tools developers use, then integrate policies and testing into those established environments and processes.