How to Secure Application Development without Impacting Developer Productivity

Summary

“Developers are often asked to take on application security tasks which are not their core skill set, and can sometimes slow down developer velocity. Without the know-how or the motivation, risks quickly mount up. This article explains a different approach to developer security training that keeps developer productivity top of mind. ”

Developer velocity, the speed at which developers can keep moving and get features and updates to launch, is often a key differentiator for today’s organizations. However, at the same time — security is an increasingly crucial part of the Software Development Lifecycle (SDLC), to reduce the risk of data breaches and other cyber attacks that can cause financial loss, reputational damage, and business disruption. 

Unfortunately, these competing goals can sometimes go head to head. After all, developers’ core competency is development — not security, which can cause friction when trying to embed security into the SDLC as part of a strong DevSecOps culture. 

This article looks at how to consider developer experience as a key element of implementing security earlier and more continuously throughout the SDLC, including why traditional methods of developer security training often fail, and what you could do instead. 

Why Include Security in the Software Development Lifecycle?

Incorporating security into the SDLC earlier and more consistently, organizations can proactively find and remediate vulnerabilities earlier in the development process, making sure that their applications are secure and robust. This could be anything from malicious code to vulnerable open source packages, or issues with APIs, containers and cloud deployments, infrastructure, and runtime deployments.

By implementing security early and continuously, organizations can protect their end-users, reduce the chance of a cyber attack, and also minimize the resource effort associated with patching and fixes post-release, or later in the cycle. 

Which Security Tasks are Developers Asked to Handle?

To make security an integrated part of application development, developers are often required to perform a variety of different security tasks. These may include: 

1. Code Review: Evaluating code to identify and fix security vulnerabilities.
2. Static Analysis: Using tools like Static Application Security Testing (SAST) to analyze code for security flaws without executing it.
3. Dynamic Analysis: Testing the running application with technology like Dynamic Application Security Testing (DAST) to find security issues.
4. Dependency Management: Using tools such as Software Composition Analysis (SCA) to ensure that third-party libraries, packages and frameworks are secure.
5. Threat Modeling: Identifying potential threats and vulnerabilities in the design phase.
6. Patch Management: Regularly updating software to fix security vulnerabilities.

While these tasks are crucial, performing them can present a number of different challenges for developers. 

First up, developers are experts at developing! They may not have specialized knowledge in cybersecurity, which means it’s hard for them to identify and address security vulnerabilities efficiently or effectively. Developers are unlikely to have been trained in finding threats and mitigating them, leaving them at a disadvantage. While no developers would leave a vulnerability in their application intentionally — they may not have the skills to mitigate them at the earliest stage. 

As security is not seen as part of a developer’s core competency, some developers may feel a lack of motivation around performing these security-based tasks. They are driven by building new features, functionalities and updates, and could easily see security as a blocker to their velocity and productivity. They may even feel like it’s not their role or it’s not important. 

Finally, developers may perceive security tasks to be add-ons rather than an important part of the development workflow. They want to finish their work, and then add security measures on afterwards — if at all. This means that security is inconsistent and usually ineffective, as it just isn’t a core part of the developer workflow. 

What are the Shortcomings of Traditional Upskilling and Developer Security Training?

Traditionally, organizations have attempted to solve these challenges by providing structured training for their developers, to help them learn the skills necessary, and to change the culture around the importance of embedded security across the SDLC. 

However, this approach is often: 

• Resource-intensive: Developers are already tightly stretched in most organizations, and do not have time to take part in intensive courses and training sessions, and still meet their pressing deadlines. 
• Theoretical: It’s hard to learn in a classroom setting. Without the practical application of fixing vulnerabilities in a hands-on way, developers often forget how to apply the knowledge they have learned in the real world. 
• Ineffective: The forgetting curve suggests that learners forget as much as 90% of what they’ve learned over the first 7 days. With formal training, knowledge retention is difficult, often due to information overload. 

Best Practices for Keeping Developer Velocity and Implementing Developer Security Training

Instead of traditional and formalized training, here are five best-practices to consider when you’re thinking about your own DevSecOps culture: 

1. Integrate security into the developer workflow

By embedding security checks into the development tools and environments that developers already use, organizations can ensure that security becomes a natural part of the development process. Tools such as integrated development environments (IDEs) with built-in security plugins, tools, and remediation advice can provide real-time feedback on security issues as developers write code, making it less of a blocker to developer velocity or productivity.

2. Think about Just-in-Time (JIT) training

The idea behind Just-in-Time training is that developers will receive targeted security training exactly when they need it — when a vulnerability has been found. This kind of training is relevant to what developers are working on, and immediately applicable in their workflow. This helps to improve retention so that developers learn on the job. This approach also allows for micro-learning opportunities, which are far less intrusive and more practical than bi-annual sessions in a classroom. 

3. Make your organizational culture security-first

Remind your teams that everyone is playing for the same side — against the vulnerabilities. Security is not an add-on, it’s a core element of everyone’s job, no matter which department they sit with for lunch. You can create a security-first mindset with security awareness programs, gamified learning experiences, and rewards to recognize secure coding practices where they stand out. Encourage any opportunities for collaboration between AppSec teams and developers, so that the whole development environment is increasingly security-aware.

4. Leverage automation to reduce manual effort

Your development teams already have a lot on their plates, and may resent being asked to add security tasks to their to-do lists, especially if they find themselves doing the same things over and over again. Look for ways to automate where possible, for example onboarding automated tools for code scanning, checking open-source packages, or assessing vulnerabilities. This can offer quick ways for developers to make security checks consistent and secure, without adding manual effort to their workload. 

5. Ensure you implement continuous feedback loops

Your developers want to feel like they are doing a great job. By establishing formal and informal feedback channels, developers will receive feedback on their security practices, allowing them to continuously improve, and making security more of an inherent part of their role. Invite developers to code reviews, security audits, and analyses of incident response procedures, so that they recognize that security is their responsibility, too.

Here’s How Checkmarx Makes Security Easier for Developers

At Checkmarx, we put a strong focus on developer experience to drive security adoption, maintain developer productivity, and build trust. To build a robust DevSecOps workflow, teams need to move away from AppSec teams finding the problems and then bringing them to developers to fix, and instead, bring security into developers’ existing workflows where possible. 

Our developer-focused AppSec features are built around three key pillars: 

1. Prioritizing for the greatest impact: Developers need their time to be valued. We help channel resources to the most critical vulnerabilities — those that will have the greatest impact when fixed. This means we minimize false positives, and we can prioritize risk based on severity, exploitability, and app criticality. 
2. Meeting developers where they live: We work where developers work. We integrate AppSec tasks such as SAST into developers’ existing tooling and workflows, including showing vulnerabilities in the IDE, SCM and feedback tool integration, and decorating pull requests with vulnerability information.
3. Empowering developers with tools and knowledge: As well as guided and auto-remediation to allow developers to act with autonomy, we also provide security training such as personalized secure code training to improve developers’ skills and reduce vulnerabilities over time. 

Looking to empower your developers to act with velocity, productivity, and security best-practices? Learn more by requesting a demo of Checkmarx One.