People, process, technology: How to shift security testing left successfully
The benefits of shift-left security are clear. It puts security testing in the hands of the engineers who write the code, enabling vulnerability fixes to occur before software hit production. This provides fixers with faster feedback loops on vulnerabilities found, as well as ensuring more efficient time to feature delivery and cohesive teamwork between security and development teams. With all the benefits that come with shifting API and web application security left, it’s no wonder that 57 percent of security team members have either already shifted their security strategy left or are planning to do so this year, according to a GitLab survey.
So, how do organizations implement a shift-left security strategy successfully? The answer lies in the popular three-legged stool analogy: assessing the process, people, and technology behind this major organizational change, and how they all can work together interdependently.
Automation challenges unpacked -- Part 2: Process complexity
In my last article about automation challenges, I covered how to manage endpoint diversity -- all of the people, systems and devices that execute tasks within an end-to-end automated process. In this piece, I’ll focus on process complexity, which is closely intertwined with endpoint diversity.
Many organizations share the ambitious goal of automating their processes as much as possible. However, in reality, processes are often automated “locally,” or within a single software system, team, or group of devices. To execute a process, you need to coordinate the execution of all of its tasks, based on a certain logic. Most processes -- even if they sound simple -- follow a more complex logic than the straightforward series of steps involved in a confined local process.