Question: How can I get my organization to shift its security left without slowing down our developers?
Scott Gerlach, CSO and co-founder of StackHawk: Ultimately, it requires a mix of people, processes, and technology. Tooling on its own cannot get you there. I typically recommend the following six steps to organizations beginning their journey. When teams apply these steps, they can actually start to shift security left without compromising developer velocity.
1. Involve the Development Team Early in the AppSec Design Process
Developers must be involved in decisions for shift-left to work. Partner with them to:
The AppSec process must be designed to interrupt developers less and help get software out the door.
2. Involve the Security Team Early in the Development Process
Developers should communicate their application’s goals and business significance, along with the type of data it will handle and its intended functionality, to the security team at the start of application design. The security team can then accurately assess risk tolerance and provide guidance on implementing security measures, such as authentication and encryption, before any coding begins.
3. Help Developers Help Themselves
Adopt tooling that helps developers understand what a discovered issue is, why it’s important, and how to reproduce it so they can fix it. The next step is to let developers document security decisions by triaging findings. The goal here is to learn together, not get it absolutely right 100% of the time.
4. Provide Targeted Security Training for Developers
When you allow developers to document decisions, you can use that information to provide targeted training based on patterns within the context of their code and importance to the business.
For example, say Team A repeatedly makes cross-site scripting (XSS) errors in spring boot code. Focus training resources on that instead of generic material.
5. Automate Security Testing in CI/CD
Testing in CI/CD helps ensure that security is integrated into the development process alongside other automated software testing, like unit and integration tests. Start by automating tests for common Web application threats, such as injection attacks, sensitive data exposure, and XSS.
6. Collaborate Among Development, Security, and Operations Teams
Throwing vulnerability reports over a wall to the next team is not collaboration. Applying the steps above sets a foundation for teams to work together effectively to identify potential security risks and develop strategies to mitigate those risks.