In the world of software development, there are plenty of opportunities for things to go wrong. Time-to-market pressure means software security can be sidelined or considered too late on in the software development lifecycle (SDLC). Yet at the same time, the number of new vulnerabilities making their way into production is rising. While usually written with the best intentions in mind, regulations can often make things worse, perpetuating silos and encouraging individuals to focus on specific output rather than broader business outcomes. If anything, it can end up making everything less, not more secure. Is it possible that isolating roles and providing a checklist of things to consider distracts the organization from the real purpose . . . to build more secure products and protect customer data.
While regulatory compliance is obviously important, it’s imperative not to lose focus on fostering a security-first mindset in everyone involved in the SDLC, to break down these silos and improve outcomes. That will only come from continuous security awareness and education that has to include bespoke role-based training for development teams.
Risk on the rise
It’s no great secret that cyber-risk is surging due to developer practices. Much of this can be traced back to the use of open-source components to meet insatiable business and market demands for new products and features. According to an estimate by Sonatype, developers last year made 3.1 trillion requests for these third-party components from Java, JavaScript, Python and .NET ecosystems. Yet while accelerating time to value, they can also introduce the risk of malware and vulnerabilities.
According to research, 1.2 billion vulnerable dependencies were downloaded every month in 2022. If they make their way into production, these bugs could be exploited by bad actors at a later date with significant financial and reputational repercussions. A Linux Foundation study claims that the average application development project contains 49 vulnerabilities across 80 direct dependencies. But indirect or transitive dependencies account for the majority of project vulnerabilities and are much harder to track and fix.
Alongside the challenge of mitigating the risk of buggy open source components, SDLC teams have to be aware of the threat from overt malicious activity. We have seen a 633% year-on-year increase in malicious packages uploaded to open source ecosystems in 2022, rising to 742% versus 2019 figures according to industry data.
How regulations are harming secure development
Regulations are often written to describe an ideal world and (consciously or subconsciously) modelled with the predominate industries/personas of the time in mind, which can lead to a tick-box mentality among teams looking to comply. We then codify the idealized, industry-average business personas and ask everyone in the industry to broadly fit into this framework. While a substantial portion of regulation is to create valuable, error-catching friction, it can also codify blind spots or introduce friction. This in turn can mean that the bigger picture is missed, and security suffers. Compliance becomes viewed as a barrier or cost of doing business, rather than an enabler which helps to provide assurance to customers and mitigate legal and financial risk. In some compliance standards like SOC 2, ongoing training isn’t even called out as a requirement, even though it’s critical to improving the security knowledge of SDLC teams.
This kind of myopic focus on personas and individual output also creates a siloed mentality which does not help strategic security outcomes. It can lead to a very rigid process whereby product teams take requirements from the market and get them approved; development builds the product; QA confirms it runs well; operations ship and run it; and security audits it. Each department has their own goals, supporting a small slice of business objectives, and define success as delivering on their subset of outputs.
Where does that leave security? Usually as “someone else’s problem” and something that is considered far too late in the SDLC. This kind of mentality has always been a challenge to overcome, and when regulations are effectively reinforcing this siloed thinking, it becomes even harder.
Everyone should be invested
Instead, we need everyone involved in the SDLC to be thinking along the same lines, with a security-first mindset that prioritizes business outcomes. The bottom line is secure software saves money and builds trust with the brand. Everyone from UX and QA to product management and software development should be buying into this vision. Security is not someone else’s problem; it should be everyone’s mission.
How do we get there? With a more inclusive and continuous approach to security training. Ideally everyone who works across the SDLC should receive some form of education and training to build that security-first mindset. It should be tailored to each role and must be continuous—the threat landscape moves too fast to take an intermittent, piecemeal approach. In this new culture, no one will have all the answers, but security champions may emerge who can “pollinate” best practices across functions.
A security-by-design and innate culture of this sort will require alignment across the business. It will also demand a commitment: to ensure that all projects include non-product feature requirements like security, and that they allot enough time for these requirements. This can all be done while meeting regulatory objectives and requirements around liability. At a time when critical vulnerabilities are coming to light on a weekly basis, a commitment to continuous security training could drive enormous competitive advantage.