Who’s responsible for application security? It’s ultimately on the business. More specifically, it’s on the executives and board members that run the business. Still, there must be resources within the organization who not only lead the charge but also get stuff done. It’s complicated, and every situation is different, but this “get stuff done” component is where the answer lies.

Reality is teaching us that security is on everyone’s shoulders — some more than others. Security problems usually start when software is created or updated. This means that developers absolutely must be involved in the process. There’s simply not enough time, money, or people to ensure application security is addressed after the fact. Getting developers involved in application security is like the manufacturing of an automobile or the building of a home. Engineering issues must be addressed from the start and throughout the process until the project is completed. Finding problems after the fact is something that can and likely will happen, but it needs to be minimized at all costs.

This is where the concept of shifting left comes into play. What shifting left means is that security is “shifted left” or upstream. Developers are then empowered to do what’s necessary with security when it’s most needed to ensure positive application security outcomes. Developers can perform security testing with the process being practically invisible to them. With the proper tools, team members can find and resolve the issues as they come up in the beginning and throughout the software development lifecycle, rather than being reactive and hoping they’re uncovered by someone…eventually.

Shifting application security left is the only feasible way to scale security in the enterprise. There are often a lot of developers yet very few security staff. This can create challenges that end up facilitating application security oversights with the potential for incidents and breaches. You can successfully implement the shift-left model into your software development efforts by focusing on two things:

Automating the process

By this, I mean automating the security testing process. If a lot of work and effort are required, developers are going to find and go down the path of least resistance which likely won’t include any sort of security testing. However, when security testing is made easy, there’s no handholding or babysitting of tools required. Developers are held to a higher standard with these security responsibilities. They can integrate security scans into their existing processes, and as vulnerabilities come up, they can gain confidence in their tools, knowing that false positives are minimized and accuracy is maximized. An important part of this relies on scans being fast and comprehensive. This means having the ability to perform partial scans when needed so that full site re-scans don’t impede progress, especially for certain websites that are constantly updating.

Integration with existing tools

Here, I’m referring to integrating security testing capabilities into continuous integration/continuous delivery (CI/CD) pipelines, i.e., tools, processes, and workflows. For example, the ability to trigger re-tests within JIRA given a certain severity or impact of a vulnerability. Or, being able to resolve, retest and then reopen vulnerability issues that still exist. Integration can also include the ability to do partial scans so that you can minimize the scope required of follow-up testing. Facilitating quick retests rather than having to run full scans again can maximize the turnaround time in this process where timing is so crucial.

I’m not much for fads when it comes to security. New ones start every day, it seems, and they tend to cloud the essence of what needs to be done. I don’t think shifting left falls into this category. It’s legitimate. It’s necessary. Do what you can to make it happen. Your future self will thank you for it.

Kevin Beaver, CISSP, is an independent information security consultant, writer, and professional speaker with Atlanta, GA-based Principle Logic, LLC. With over 33 years in IT and 27 years in security, Kevin specializes in vulnerability and penetration testing, security program reviews, and virtual CISO consulting work to help businesses uncheck the boxes that are creating a false sense of security. He has written 12 books on security, including the best-selling Hacking For Dummies and The Practical Guide to HIPAA Privacy and Security Compliance. Kevin has written over 1,300 articles on security and regularly contributes to TechTarget’s SearchSecurity.com and Ziff Davis’ Toolbox.com. He has a bachelor’s in Computer Engineering Technology from Southern College of Technology and a master’s in Management of Technology from Georgia Tech. In his free time, Kevin enjoys road racing his Mazda Miata in the Spec Miata class with the Sports Car Club of America (SCCA), riding dirt bikes, and snow skiing.