Concerted multilateral efforts are underway to influence and change developer behaviour when it comes to secure software creation.

The idea of baking security into software right from the start of the development lifecycle is going from strength to strength, having gained important buy-in from cybersecurity agencies and vendors in the past year.

Over 250 vendors supplying the US government have now signed a secure-by-design pledge with North America’s CISA, which is hoped will reduce the potential for vulnerabilities in productionised code.

CISA’s local counterpart, the Australian Signals Directorate (ASD), is pushing for similar accountability domestically. In addition to co-authoring secure-by-design papers with the likes of CISA, ASD “embarked on a comprehensive program of work, as part of a wider international effort, to promote and uplift industry and government’s ability to implement secure-by-design” during the most recent financial year, it noted in its recent cyber threat report.

While industry—or at least organisations with significant software engineering functions, such as Australia’s banks—have publicly announced their support for secure-by-design, that support is somewhat more ad hoc than it is among vendors or government agencies. This isn’t necessarily because there’s no mandate on industry to conform. There are bigger barriers at play.

One of these is priorities. A survey from 2022 notes that 63% of businesses prioritised speed-to-market over security, and about 60% of respondents lacked visibility to check the security of their applications before shipping them.

Two years on, it’s apparent that not much has changed. An October survey by KPMG Australia highlights how the fast-paced world of technology is driving rushed decision-making, and causing an imbalance between speed, security and value.

A separate survey in the same month notes an “ongoing struggle to balance thorough security practices with development speed”. But importantly, respondents in this survey were aggrieved with the time needed to test software after it’s already been developed. This issue more or less goes away if teams adopt a secure-by-design mindset and approach. Such survey findings are proof that the time is right for secure-by-design to make its mark, and that organisations should start moving in this direction if they have not started to already.

‘No picnic’

This leads to an important discussion about the bigger barrier to adoption of secure-by-design: while recognised as being a good idea, implementing secure-by-design in increasingly complex software environments is no picnic.

For organisations with low security maturity, implementation may be an even more significant exercise.

This should not serve to discourage organisations from committing. A lot of things in technology are challenging, but that’s what draws many people to work in the industry.

It should also be remembered that, just like no one goes to work to intentionally do a bad job, no developer intentionally sets out to create insecure code. In the absence of time-based and other pressures, developers want to be able to ship the best possible version of code that they can.

It is possible to realise secure-by-design in a meaningful way, if organisations commit to doing several things. They must overhaul security learning pathways for developers, build and verify that security skills are being learned and applied correctly, and foster a positive security culture that provides the guardrails necessary to reduce human error in the software development lifecycle.

The leap of faith

Organisations cannot keep falling back on the same excuses not to start down the path of secure-by-design. Investment in code quality and security integrity must be factored into company budgets.

Specifically, precision education that focuses on coaching developers to produce more secure results with their coding should be factored into training budgets. Secure-by-design skills will not be developed via osmosis: there is a need to continuously upskill and assess the extent to which secure-by-design principles are reflected in code output. This may be supported by specific learning and assessment programs.

A chief consideration when evaluating secure-by-design training courseware and materials is ensuring that it is precise, hands-on and serves as good preparation for real-world coding environments and code security issues that developers will actually encounter in their work day.

The chosen learning platform should also support frequent upskilling, and offer software engineering leaders data-backed insights into where improvements can or need be made to address any knowledge gaps.

Like secure-by-design itself, developer-centric upskilling initiatives are still narrowly focused – with fewer than 4% of developers globally receiving this kind of training, according to recent research. But that would likely change if more organisations were aware of the impact the training had.

When upskilling initiatives are in place in larger organisations, vulnerabilities are reduced by between 47% and 53%. This is a meaningful statistic that warrants broader consideration by software development teams domestically and farther afield.

In addition to upskilling, organisations should implement robust security controls across leaky areas like APIs to ensure there is full transparency over how sensitive data is accessed and handled by software applications. They should also conduct thread modelling during design and major software changes as a non-negotiable; and transparently report on software security risk and mitigation to the board and other executives.

Secure-by-design remains a powerful opportunity to change the course of software development. Giving developers the skills to move forward with higher security standards demanded of modern software development is needed to manage inherent developer-associated risk and move past the current mess of vulnerabilities in software products, towards a future of cleaner and more secure code.