Secure code starts with a training commitment to development teams

It's been two years since the PCI Security Standards Council updated its software security guidelines, bringing software security best practices in line with modern software development. 

While aimed principally at the banking and finance industry, the guidelines are often held aloft as an example of where software development and security are headed more broadly. 

Almost all companies today are under pressure to encourage rapid, innovative feature development that lands in customers' hands faster while prioritising security. 

DevSecOps is the current gold standard for achieving this kind of secure software development. The primary goal of DevSecOps is to break down barriers and encourage open collaboration between development, operations, and security teams so that all of them can contribute to the creation of new applications and organisations can deploy new apps with secure, working, and efficient code. 

A thriving DevSecOps process helps to secure code from the start of production rather than patching and debugging it at the most expensive stage: after code has already been committed. However, moving to an efficient DevSecOps program isn't always easy, requiring both an operational and a cultural change for most companies..

The 2022 update to PCI security guidelines brought DevSecOps firmly into the minds - and operations - of some of the finance sector's largest players. But PCI - like other publishers of best-in-class cybersecurity guidelines - also tends to be influential beyond its immediate target industry sector.

The 'North Star' they've set has placed financial and eCommerce operators at the forefront in terms of their ability to produce rapid, high-quality, and secure code for customers' benefit. 

To emulate that in other sectors will require a serious commitment to developer education and to verification that those skills have been taken onboard, as well as renewed focus on creating a security culture that places development teams at the heart of code-level vulnerability reduction.

Exemplars of secure code

In organisations without a strong DevSecOps focus, responsibilities often remain separate and security is left too late in the process to be effective. Developers are responsible for writing line after line of code to create software to power customer-facing services, while AppSec specialists have the unenviable position of testing the lion's share of this code at the finish line, either with scanning tools or manual code review.

Through their work, AppSec specialists tend to find the same bugs and relatively straightforward security issues that we've known how to fix for years, such as SQL injection, cross-site scripting, and session management weaknesses. In other words, security practitioners spend their time finding and fixing code violations that developers themselves have had the power to fix for years, except that security has not been made a priority in their process – especially now, in the age of agile development where feature delivery at speed is king, and security is the elephant in the room that could halt release progress altogether.

This situation only perpetuates a flawed software development lifecycle, where developers with little security awareness operate in a negative security culture, producing insecure code, which then has to be scanned, assessed and fixed well after it was initially written. 

To shift the needle, organisations should look to those organisations that have implemented the PCI DSS guidelines as exemplars of secure code creation. 

At a practical level, work has to be from the ground up: getting development teams engaged with security best practices, empowering them with the knowledge to efficiently code securely, in addition to creating and maintaining a positive security culture in the workplace.

Getting knowledge to stick

We've established that developers are an integral—yet frequently underutilised—part of reaching a state of software security excellence. 

This is especially relevant to more than just PCI DSS compliance. It is crucial that developers understand the broader picture of PCI DSS 4.0 - even if they are not subject to it - in terms of what they can control and integrate as part of their default approach to a software build.

The onus isn't just on developers to improve their security skills; their employers also need to play a part. When it comes to developers, so many secure coding training programs don't seem to cater to their needs, ways of working, or even their day-to-day jobs in any tangible capacity. Not all training is created equal, and not all training is going to result in software that is more secure.

Agile, customisable training methods that appeal directly to the developers' problem-solving traits can be utilised to foster success in forward-thinking organisations that are willing to try less conventional approaches to developer education. A bite-sized, gradual learning process using agile upskilling methods makes it far easier to remember and apply in context, and it absolutely must be in the languages and frameworks used every day.

The right training is seamless, not like a lecture, and highly relevant to the work done every day. This kind of hands-on training is an upskilling opportunity—a career move that only benefits developers who are serious about stopping vulnerabilities and working with the rest of the team to produce a higher standard of code.