Developers resist fixing vulnerabilities in their code. How will you convince them to prioritize security?

To convince developers to prioritize security, highlight the tangible benefits and potential consequences. Emphasize that fixing vulnerabilities protects user data, maintains customer trust, and prevents costly breaches and legal liabilities. Show that secure code enhances performance and stability. Provide real-world examples of breaches and their fallout. Offer training to improve security skills and integrate security into the development workflow, making it a standard practice. Foster a culture where security is seen as a shared responsibility, and reward efforts to improve code security.

Although more and more developers are concerned about incorporating cybersecurity natively into the applications they create, the truth is that in practice we are very far from the goal. Here are some good practices that could help you improve. 1. Insist on awareness and the importance of creating secure code. 2. Implement ISO 27001 in our company, placing special emphasis on the controls that affect development. 3. If in the short term it is difficult to have secure code and the risks we are assuming are very high, we should not rule out setting up some prevention measure, such as a WAF, to reduce them. Safe development must be an inalienable objective.

We educate the developers on the impact of insecure code on the customer, the development team, and the company. Our application security trainings for developers, highlight the risks of insecure coding practices: i) losing customer confidence, results in damaging company's reputation ii) Fixing the code error, increases productivity for the development and QA teams, resulting in increasing the company's cost. The training also highlights the mitigation methods for those risks.

I love this topic! Rule number 1: speak developer to developers not cyber. It is respectful and contextual. I appreciate that developers need education around information security risk but I think we still need to contextualise it for them. It should be about enablement and help. And we should aim to drive quality as who wants to write poor quality code? Security then becomes part of that conversation and dialogue. Cyber security should also translate the obscure and extrapolated points away from the intangible to something meaningful. I heard once a head of development of a major company say "why would that happen to me". It was too hard and too far from the goals against which they were measured against. Its all about help and context.

Developers are problem solvers at heart. To shift their mindset, we need to clearly articulate why secure coding isn't just another task, but a critical solution. Real-world examples of data breaches hitting headlines are powerful. Show them how a single oversight can snowball into financial loss, tarnished reputations, and even legal consequences. Explain the concept of "security debt"—neglect now leads to exponential headaches later. Make it clear that secure code isn't about hindering them, but rather about building something resilient and trustworthy.

If we take the position of help rather than criticise or overload we have the ability to make change in the development lifecycle. Many years ago studies were done (ack to Sherif and Sherif all those years ago) who showed that collaboration solves problems and conflict. Brining different views together around a common goal, in this instance the SDLC is a very powerful thing. We must also remember that the developer is judged on sprints and features and output. Cyber on stopping things happen or reducing. They can be sometimes diametrically opposed. So come together and figure out what is truely important and information security then becomes subtle, and an enabler.

Too often, security and development teams operate in their own bubbles. We need to change that. Pair programming with security experts is invaluable – it's not about "us vs. them," but about working together to solve problems. This builds shared knowledge and ownership of the code's safety. By integrating security into every stage of development, it becomes less of a hurdle and more of a shared goal.

This is a fundamental point. Simple is NOT easy. Lets wind back even more. I advocate (not exclusively but often) to strip back tooling in the toolchain and think differently. Suddenly we have a clearer playing field than a never ending backlog of vulnerabilities. A metaphor - an amazing toolchain finding many vulnerabilities that we cannot on, or boiling things back to a simpler set of ingredients where we can actually sense what is important. This seems so relevant, but extending the metaphor, I like the phrase in the health sector "there is no money in broccoli". But there is "money in broccoli extract/product". If we translate this to tools / solutions - there is no money for vendors in ripping out complex solutions. Time to think.

Let's be honest, reporting vulnerabilities can be a pain. Clunky systems and unclear processes make it easy for developers to put it off. We need to fix that. Invest in streamlined tools that automate the tedious parts. Make the steps for remediation clear and actionable. The easier it is to address vulnerabilities, the more likely they are to get fixed promptly.

Everyone likes recognition for their efforts. Create a culture where secure coding is celebrated. This could be through formal programs, bonuses, or even gamification elements. Highlight how security skills are highly valued in the industry and essential for career advancement. When developers see that their security efforts are noticed and rewarded, they're more likely to prioritize it.

Let's make security a key performance indicator (KPI). When it's tied to performance reviews and project success, developers have a tangible reason to prioritize it. By aligning security goals with the metrics that matter to them, we weave security into the fabric of their work, not just an afterthought.

Cyber in development lifecycles needs to focus on just that...! Cycles! So if we acknowledge there are continous cycles of development and software production, we as cyber security experts and advisors need to work in a continuous manner. We need to look outside our compliance cycles yearly and to the in between times when developers and environments need our continuous, iterative support. Its so very important.

We can't just expect developers to figure it all out on their own. Provide ongoing training, up-to-date documentation, and access to the right tools. Foster an environment where they feel comfortable asking questions and seeking help. Continuous support reinforces the importance of security and empowers developers to proactively protect their code.

Aunque cada vez son más los desarrolladores que se preocupan por incorporan la ciberseguridad de manera nativa en las aplicaciones que crean, lo cierto es que en la práctica estamos muy lejos del objetivo. Aquí van algunas buenas prácticas que podrían ayudar a mejorar. 1. Insistir en la concienciación y en la importancia de crear código seguro. 2. Implantar la ISO 27001 en nuestra empresa poniendo especial acento en los controles que afectan al desarrollo. 3. Si en el corto plazo resulta complicado disponer de código seguro y los riesgos que estamos asumiendo son muy elevados no debemos descartar montar alguna medida de prevención, como por ejemplo un WAF, para reducirlos. El desarrollo seguro debe ser un objetivo irrenunciable.