The Business Case for Developer Security Tools

Developers building applications must think holistically about how security principles are applied through the software delivery lifecycle. DevSecOps, which stands for development, security, and operations, integrates security concepts into the development and delivery of applications. This end-to-end approach applies tools, education, policies, and practices at every stage to enable secure applications.

An important part of this approach is to integrate tooling and automation early in the lifecycle, also known as a “shift-left” mindset, without impacting delivery speed. Frequent security testing and scanning is a task expected from a DevOps-oriented team, leading to faster remediation of flaws and errors, a task greatly facilitated by the appropriate DevSecTools.

The benefits of adopting DevSecTools in the software development lifecycle include:

• 5x reduction in security debt: A report shows that security scanning done more than 300 times per year reduces the security debt by 5x.
• 30% quicker response: Reports show that applications scanning security frequently can reduce the time required to fix flaws by a third or more.
• Faster development: Automation along the development lifecycle reduces risk and speeds development, with fewer compliance errors and faster time to remediation.
• Cost savings: Fixing security issues earlier in the development process can avoid significant costs.
• Increase in team-work efficiency: Developer security tooling can close the gap between security engineers and developers, resulting in more efficient work and coordination.

Organizations large and small need to figure out how to invest in security, tools, and education, and to achieve cultural change that embeds security into the development process. Many scenarios of use include integrating security early into the development lifecycle and mitigating the high cost of solving security problems that occur late in the process. It’s likewise common for organizations to turn to DevSecOps to address complex application development processes (e.g., transitioning from monolithic models to microservices). Finally, DevSecOps can be deployed to enable security professionals with limited awareness to protect hundreds or even thousands of applications. And it can serve to integrate policy-driven automation into organizational security strategy.

Dev shops can secure applications as an alternative to implementing security tooling that would secure the development processes instead. Another alternative would be a non-DevSecOps approach where security controls are applied generally after the application has been deployed. Additional alternatives are to use traditional software testing, adapting security processes or structures already in place to “shift-left,” and integrations with third-party tools or add-ons.

• Slowing development/releases during the adoption of DevSec new processes and tools.
• Choosing the solution that fits the organization’s needs is very important. Implementing incorrect tooling can be costly as it may require adding more tools or changing them altogether.
• Developers and security professionals have different priorities and skills; Investment may be required in education, tooling, and cultural change.
• Overcomplexity: There should be a balance between security features and simplicity in the solutions for ensuring adoption and effectiveness within the organization.

30 days: Understand and Position
Review current security practices and tools. Understand how security is handled in the current pipeline process, which security tools are currently in use, and which development security practices are being applied. A third party may be needed for some of this. Also consider how (and if) developers integrate security into the current process, and the risks this integration may pose in the development process (related for example to data, writing secure code, etc.). Then define a plan of action, coordinating with security, engineering, and development teams to propose DevSec tooling, plan training and education, and plot out next steps.

60 Days: Define and Evaluate
Define the higher risk areas and evaluate broader measures to implement a more comprehensive approach. Define actions required to integrate security practices in the development process, including acquisition of tools, human resources, and resources needed for collaboration, training, and adoption across teams.

90 Days: Launch and Assess
Launch the plan in audit mode to evaluate the necessary changes for the transition to enforcement and adoption. At the end of the 90 days, perform an assessment to determine next steps and identify obstacles to an effective roll-out. Finally, confirm a “steering board” to enable continuous improvement of security practices in the organization.

All the information provided in this Gigabrief is discussed in greater detail in the following resources:

• Key Criteria for Evaluating Developer Security Tools
• GigaOm Radar for Developer Security Tools