Continuous Security: The Next AppSec Frontier

We are at the final frontier. No, I’m not talking about space, but rather the next generation of application security in DevOps pipelines. Not that space tourism should go unnoted – space planes and pilotless spaceships like Virgin Galactic and Blue Origin acutely highlight how application security extends beyond the software to the hardware it powers. To get FAA approval, both had to get signoff not just on the safety and security of the hardware, but the software too. Good application security must go beyond analyzing lines of code to include all the things that touch an application to reduce business risk.

With a ratio of one security person to ten DevOps/IT people to 100 developers, it’s easy to see why security teams feel like they need to be everywhere at once. The popular axiom that security is everyone’s responsibility is certainly true, but we also need to be thinking about how it is also to everyone’s benefit. Well-implemented application security programs don’t just decrease cybersecurity risk, but overall business risk, as well, by reducing project delivery and budget risk. But this means that security must find a way to meet development teams where they are—both philosophically (we ship imperfect code every day) and literally in the software development life cycle (SDLC).

As the frequency and severity of cyberattacks continues to increase, CSOs can drive the transition to development-led application security programs where development manages the day-to-day execution of the security program while security continues to manage the strategy. The past year and a half demonstrated that we cannot rely on siloed security teams to protect an organization. Security must find a way to not just have their people embedded in the teams they work with, but also—and more importantly—have their security processes embedded within those teams’ processes.

It is crucial for development and security teams to partner throughout the SDLC, so that your program doesn’t just rely on a binary state of secure or insecure. By implementing processes that map not just to a security risk framework but to the overall business risk profile, teams can make educated decisions with the right information at their fingertips knowing the associated risks and mitigating controls necessary.

There is no Perfect Code and no Perfect AppSec

Many organizations regularly push out tens if not hundreds of releases and updates on a daily basis. This leaves development teams playing AppSec roulette, with almost half (48%) of organizations regularly pushing vulnerable code, and they know it. This happens for a number of reasons:

• 54% of organizations push vulnerable code to meet a critical deadline, with plans to remediate in a later release.
• 49% of organizations push vulnerable code because they believe it holds low risk.
• 45% of organizations publish vulnerable code because vulnerabilities were discovered too late in the cycle to be resolved in time to deploy.

Security needs to work with development to manage security by giving them the right information at the right time. It is not that DevOps teams don’t want to incorporate security; rather, they lack the solutions to manage it in their workflow without creating additional burden or having to suddenly become security experts. With help and guidance from the security team, development teams can push secure releases on the first try, saving time and money along the way.

There’s no doubt that development teams understand security must be an intrinsic part of the development process. Still, deploying secure code is a struggle for development teams, not because they don’t want to, but they don’t have the right tools to not only tell them the security requirements at the right time but to help them make decisions – just as they do with the rest of their code. Consequently, when more security tools are put into their pipeline without delivering the right context, they are often ignored. It becomes just one more data source without actionable information.

Build a CI/CD/CS (Continuous Security) Pipeline

CI/CD is about not just automating the steps to ship code, but being able to continuously, seamlessly deploy changes to meet the most current needs of the business. However, with integration into the SDLC, security scrambles to keep up with the changes teams must make in order to deploy continuous security. This means not only ensuring that code is shipped according to the most current standards no matter what changes about the design, but also that security best practices are being deployed in real-time.

A continuous security mindset allows you to deliver a holistic application security program—end to end, from architecture decisions to on-demand training. Developers should be able to implement policies and adjust these policies to not only meet framework requirements, but overall business requirements in an ever-changing security landscape. Can you imagine being able to automatically adjust your project’s security requirements based on a change in the threat landscape?

Supporting development-led application security execution doesn’t mean the CSO no longer owns application security. When development teams manage the day-to-day responsibility for the security of their code, security teams can keep their focus on overall security strategy. Focusing on collaboration from the beginning gets development and security teams out of just vulnerability management to understand the policies that can prevent incidents and knowing whether or not the code aligns with the organization’s goals and risk tolerance.

The goal, of course, is a mutually beneficial approach to implementing application security. Security can help development teams maintain the flexibility they need to mesh security within the work they are already doing. And in doing so, security still gets centralized governance that arms teams with the knowledge of when processes and protocols are being followed – and when they’re not – and how risk is managed within those parameters.

Without this collaboration, the drag that poorly integrated (or not-at-all integrated) security puts on your development pipeline will leave you in the competitive dust as time-to-market and productivity suffers. So CSOs, are you ready to boldly go where no one has gone before?