A featured contribution from Leadership Perspectives, a curated forum for enterprise technology leaders, nominated by our subscribers and vetted by the CIOApplications Editorial Board.

Head of Technology – Security Platform

Changing the culture of Security within Software Development

Software development has gone through a radical transformation over the last decade. Where expectations on engineers and budding developers used to be focused on writing lines upon lines of custom code, the industry has morphed into one of the open communities, sharing and reuse. Surprisingly without a negative connotation; this ecosystem of sharing and collaboration across business units, companies and communities, has led to a drastic uplift in productivity, quality and efficiencies in development times. Standard functionality can now be included with a single line of code, whereas in the past developing your own implementation could have led to thousands of lines of additional custom code. Without a doubt, the open-source movement and related communities of dedicated people have been around for a long time. However, it’s only semi-recently that we’re now seeing major organisations actively onboard and involved. It’s clear that when traditional enterprise software vendors start acquiring companies founded on the concept of open source initiatives, it’s a clear signal of the change in mindset across the industry.

However, this change in culture and business appetite has also created another interesting conundrum; Security. Whereas organisations used to be able to rely on internal scans, tests and reviews; we’re now faced with a world where most custom-developed business applications use some form of open-source library, and by some reports, these libraries contribute to more than half the lines of code in the entire application. External entities possibly write more than half of the code in businesses’ critical applications. What does this mean? How can we now rely on our internal quality teams and existing processes and measures, to effectively assure us of the security of the applications we’re deploying to service our business? Couple this with the fact that codebases are drastically increasing in size, and we’re now left with the daunting task of testing and quality assurance, from both a functional side, as well as the security aspect.

If you then consider the rate of change and release cadence of some of these libraries; we’re stuck in a never-ending cycle of trying to keep up with the rate of change outside, and ultimately inside our critical applications.

The standard approach of internal scanning and reviews is no longer enough. We must now rely on a suite of internal and external toolsets to help us keep the software we develop safe and secure.

Security is often seen as a blocker or hindrance in any software development lifecycle. That must change across the industry to be effective. When engaged as late as possible, and ultimately blamed for unintended delays or missed deadlines, the relationship between the teams writing our business software and customer applications, and the teams tasked with keeping us secure can be fragmented and fragile.

But why is this? The change in mindset with how we develop software has missed the opportunity to embed security right into the very processes we champion within our development teams. While agile methodologies have certainly tried to close this gap, it’s often still not fully embedded or functional across the various required teams. It is often now out of the hands and capabilities of the standard development team; and without the correct supporting tooling, often outside the bandwidth of a businesses’ security team.

However, it’s not all a lost cause. By embedding the secure development mindset into our development teams, we can yet again increase the rate of development and release for business-critical applications. Through proactive training, coaching, and education, we can enable developers to understand common vulnerabilities and pitfalls; and with the use of automated pipelines and third-party library vulnerability scans, we can automatically flag and notify when our applications are unknowingly bundling in flawed external code. There is now a raft of companies and technologies (some even open source) emerging, hoping to fill this gap and assisting in mitigating these issues. By cataloguing and proactively notifying the development teams when they’re unknowingly using potentially vulnerable code, we’re moving this activity to the left, and allowing the final security review teams to focus on other broader potential issues.

Security is everyone’s responsibility, and introducing the correct tooling and process into your organisation can make all the difference. While not a silver bullet, the methods and technologies mentioned can assist in mitigating the exposure to risk this new development mindset has introduced over time. Endeavour to not turn security into a blame game or finger-pointing exercise, instead empower your development teams, quality assurance professionals, and security reviewers to identify and resolve issues proactively. With the right culture, tooling and mindset, security doesn’t have to be the blocker in your release train; instead, it can be partially automated and brought as early as possible in the release cycle to prevent delays or wasted effort.

The articles from these contributors are based on their personal expertise and viewpoints, and do not necessarily reflect the opinions of their employers or affiliated organizations.