Anyone who works on application security knows developers are inseparable from AppSec programs. Even so, the hardest part is figuring out how to get security on their agenda and actively involve them in preventing and managing vulnerabilities.

Only with their buy-in and active involvement, it is possible to scale an application security program to the level desired by AppSec teams, especially in large enterprises where developers way outnumber security engineers.

We have seen many customer scenarios over the five years we have worked on Kondukto. Hearing the same complaints from various AppSec teams that developers do not react to vulnerabilities on time or do not consider security when they build new applications made us think about the root cause of the problem.

When we looked at the way developers work in those organizations, we realized that security is an afterthought for development teams simply because they do not see anything in it for them.

Almost every job posting for software developers lists writing clean, readable, reusable, bug-free code as a requirement, whereas security is hardly ever mentioned.

It is not a part of their job description, KPI, or differentiator, so why care about it?

So the solution lies mainly in human resources as a change management topic.

To initiate the change, we do not need another tool or a process but a different headspace where developers know they are expected and encouraged to code securely. Creating this culture paves the way for raising security awareness in the development teams more than any tool we’d think of.

For this purpose, just like bridging the gaps between security and development teams, AppSec teams also need to cooperate with human resources teams, CTOs and VPs of Engineering to make sure security is at least an expectation phrased in job descriptions, more favorably a KPI to distinguish good performers from the bad ones.

Bringing in security as a KPI for developers may be alarming for organizations where developers have the final say in most internal decisions. Change management is always challenging, but proper communication and creative solutions can facilitate the process.

If you help them see this as a change in their favor, things will be much easier. So let’s take a look at some arguments we can use.

1. Security is becoming a distinguishing factor that sets a good developer apart from the rest.

It is easy to forget how rapidly roles evolve in the tech world. Just look at the requirements listed in job postings five years ago and now.

All you need is to remind them how the expectations from a developer keep changing over time. Any developer who wants to stay up-to-date in the market needs to start thinking about security.

To encourage them to do so, tracking and measuring secure coding performance in a gamified way helps to create a competitive but friendly atmosphere.

It would be naive to expect companies not to reward developers coding with security in mind to prevent vulnerabilities for the discovery of which they spend significant budgets.

In some cases, the programming languages are replaced with new ones to prevent certain vulnerabilities. This clearly indicates that the developers' capabilities also need to change accordingly. Below is a blog post on how Google eliminated memory-related vulnerabilities in Android by switching from C++ to Rust.

https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html

2. Developers prefer to deal with fewer vulnerabilities if not none.

Vulnerabilities popping up at the latest stages of the software development life cycle is the most annoying for developers since it impedes their workflow.

Almost all developers would prefer not to have any vulnerabilities in their sprint, especially ones they did not create in the first place.

As a crucial part of a successful application security program, threat modeling helps prevent vulnerabilities in advance and frees up time for more innovative work. It also helps improve the security awareness of developers and encourages them to think in a security-friendly way when building applications.

Another benefit of an AppSec program for developers is the ability to discover vulnerabilities earlier in the software development life cycle, allowing for on-the-spot fixes that take much less time than in the later stages of development.

3. Having a metric-based program helps developers to justify their contribution.

Every developer wants to work in an environment where expectations are clear and their effort is appreciated.

From a security perspective, developers are usual suspects for all application vulnerabilities and they can benefit from an AppSec program that lays out how they contribute to the program either by not creating vulnerabilities or by fixing them on time.

With a proper AppSec program that helps create and convey expectations with metrics and SLAs, it is easier for developers to determine if they are living up to the expectations and prevent alleged accusations that they do not do their part in the AppSec program.