When regulations aren’t enough

Pieter Danhieux at Secure Code Warrior explains why “Secure by Design” has emerged as mission critical for software development

 

The use of artificial intelligence (AI) in software development has reached a point of near-universal adoption: nearly all technology companies rely on AI coding assistants in some capacity. Increased productivity/time-to-market has emerged as the primary benefit driver of these assistants, as cited by 72 percent of tech company engineering leaders and platform team members.

 

This impression may turn out to be somewhat dubious, as a recent study reveals that when open-source developers use AI assistants, they actually work 19 percent slower than they do without them.

 

But there are more immediate – and impactful – concerns about the connection between AI-assisted software development and security: Sixty-three percent of developers say writing secure code is difficult, and 67 percent admit to knowingly shipping code with vulnerabilities. Clearly, too many developers lack the expertise to create safe code, and AI only further elevates risks by frequently introducing vulnerabilities within coding cycles. After Google released its coding assistant, Gemini CLI, in June, a security company named Tracebit published research revealing that the tool was susceptible to prompt injections, which could cause undetectable arbitrary code execution.

 

It doesn’t help that the regulatory landscape remains murky. The EU Artificial Intelligence Act prohibits “unacceptable” risk while regulating high-risk AI systems. But the current White House administration considers federal regulations that hinder AI development/deployment as “onerous” and is seeking to remove them.

 

All of which simply adds to confusion among developers and their organisations. Current regulations and guardrails are not strong enough to keep teams with minimum security awareness or capabilities from generating suspect, AI-enabled code. Subsequently, we must be cautious with AI, as it can dramatically accelerate the production of faulty code and increase the likelihood of hidden bugs, vulnerabilities and technical debt if handled poorly. The use of unmonitored AI tools (a.k.a. “shadow AI”), for instance, is adding $200,000 to the global average cost of a breach (which currently amounts to $4.44 million), according to IBM.

 

Organisations should seek to avoid such financial burdens, not to mention counterproductive and time-consuming fixes. That’s why they need to implement and enforce the principles of “Secure by Design” (SbD) throughout the software development lifecycle (SDLC).

 

SbD requires ongoing cooperation between security teams and developers. In the spirit of a proactive partnership, they work together with a “security-first” mindset, realising it is in no one’s best interest to apply protective measures when applications are already in production. By prioritising defence at the very beginning of the SDLC, they tip the scales in their favour by making it very difficult for hackers to gain an edge.

 

To ensure the success of an SbD initiative, security leaders and development managers must work to include the following components: education and code review.

 

Education

Organisations must invest in comprehensive, continuous learning pathways to upskill the security knowledge and capabilities of developers, enabling them to implement effective protective practices from the outset. When they identify suspect AI-generated code throughout the SDLC, they make significant strides toward product defence that exceeds whatever regulatory requirements are out there.

 

As with any vocational training programme, presenters should focus on hands-on sessions so participants are engaged with scenarios that reflect what they’re dealing with every day on the job. The sessions should also be flexible, based on agile learning concepts that foster continuous improvement while accommodating developers’ schedules. 

 

Code review

Security leaders need to assess the effectiveness of educational efforts in light of whether developers can reliably review generated and third-party code components for flaws that leave products vulnerable to potential authentication or access control exploits and other compromises. With right-fit tools and learning modules incorporated into their workflows, they will acquire a level of observability to track code origin, contributor identities and insertion patterns to remove flaws before they have a chance to do any harm.

 

Successful organisations understand that it is never wise to passively wait for good things to happen. It doesn’t work in business. And it never works in security either.

 

So instead of waiting for clear direction in the form of regulatory guidance and guardrails, they should proactively launch their own SbD initiative, one in which optimal education and code review drive success. With this, development teams will ensure that protection remains a top priority throughout the SDLC, and cyber-criminals are shut out of the process. 

 

---

 

Pieter Danhieux is CEO and Co-founder of Secure Code Warrior

 

Main image courtesy of iStockPhoto.com and Vadim Shechkov