Security starts at the source (code)

There's a lot of talk surrounding security right now. Mainly because some high street names such as Co-op, M&S and Harrods have been attacked

As a result, the shelves have become empty in some stores. It is apparent that the co-op attack at least, was human engineering, where a stressed member of staff (or a number of them) were coerced into giving network permissions to the bad guys... However, it's not always the case. Sometimes it's 'schoolboy' programming errors that allow a back door into the systems.

I worked for Santander for around 20 years. I designed and built the original application and continued as the main developer for a number of years before we built a team, and I headed that as Technical Director. This was my first major application, and it was for a bank. Myself and the developers quickly learned how to code with security at the forefront of our mind, way before cybersecurity teams even existed.

Yet, as a development agency, we would often work with other programming teams for clients, both in-house and external, and when it came to security, these teams often saw it as someone else’s problem. Especially since most big corporations nowadays have a cybersecurity team.

Security starts at code level!

🟨 Why Developers Have Avoided Security

Many developers don’t see security as their job. They focus on delivering features, relying on security teams to catch vulnerabilities later. But this approach is flawed. Security issues ignored during development are harder and costlier to fix later.

Another reason is a lack of training. Most coding courses emphasise frameworks and system design while glossing over secure coding practices. Without proper training, security feels foreign, something more akin to an extra burden rather than an integral part of development.

🟨 The Risk of Ignoring Security

Software vulnerabilities often start in the code itself. Bugs like SQL injection or cross-site scripting don’t originate with security teams, they stem from insecure coding. Expecting security teams to catch every flaw isn’t realistic. They are often stretched thin too, auditing massive codebases while dealing with evolving threats. Developers who ignore security make their jobs even harder.

🟨 So What Would I Expect My Developers To Do?

Security must be a part of the development process, not an afterthought.

Here’s how developers can take ownership:

Write Secure Code: Follow best practices like those outlined by OWASP. Secure coding should be second nature, just like adhering to style guides.

Use Security Tools: Static analysis tools and security tests should be integrated into the development pipelines. Security should be part of the definition of “done.”

Keep Learning: Security threats evolve, and staying informed is key. Training, conferences, and certifications can help keep skills sharp.

Collaborate with Security Teams: Developers and security professionals should work together to address vulnerabilities early and prevent security from becoming a siloed afterthought.

Think Like an Attacker: Every code function should be written with security in mind. If a developer can imagine how their code might be exploited, they can proactively fix weaknesses before they become problems.

At the end of the day, Security is a Shared Responsibility

Security isn’t just for specialists… It’s everyone’s job. When developers embrace security from the start, they help create a safer digital world for users, businesses, and themselves. It’s time to shift security left again and make it a fundamental part of software development.