While there is general agreement that more responsibility for application security needs to shift left toward developers there’s not a lot of consensus when it comes to determining how to achieve that goal.
In theory, developers should be given more tools to scan for vulnerabilities in their code before it is added to the build that eventually gets deployed in a production environment. The challenge is most developers have little to no cybersecurity expertise, so they are not well-equipped to identify the severity of a vulnerability. Most applications today include open-source components that have vulnerabilities, so it’s almost impossible to build an application that doesn’t include some.
The second challenge is most applications are built by multiple developers that will have varying degrees of cybersecurity expertise and proficiency. As a result, it’s probably code that may have a serious vulnerability will find its way into the build that is being created. That means the build in addition to the code used to create it needs to be scanned for vulnerabilities as it moves through a software development pipeline.
Finally, the tools and platforms used to create those pipelines are also now under attack. Organizations of all sizes need to make sure that malware has not been embedded into the tools and platforms used to manage their software development pipelines so they can ensure the integrity of the software supply chains.
All these issues are supposed to be addressed via the adoption of a set of best DevSecOps practices. However, the probability that application developers will have all the required expertise to secure every phase of their application development processes is slim to none.
The hope, of course, is that as more cybersecurity guardrails are embedded in the tools and platforms used to build and deploy software, the whole process of ensuring security will become more automated. However, no matter how automated the cybersecurity guardrails embedded in these tools become, there will certainly be a need for someone with cybersecurity expertise to be involved. Organizations are addressing that requirement in one of three ways. They are looking for someone in the developer team that has a real aptitude for cybersecurity to coach everyone else. A second option is to add a dedicated security engineer to the team that manages the DevOps workflow. The third option is to create a cybersecurity center of excellence that includes cybersecurity professionals that work alongside developers as they build applications.
Each organization that builds software will need to decide for itself what approach makes the most sense. Some larger organizations will undoubtedly embrace all three approaches as the consumers of applications continue to require assurances that the software being delivered meets a certain threshold for cybersecurity.
Regardless of approach, it’s clear more organizations will be looking to incorporate cybersecurity professionals within their application development workflows. Less clear is the impact that inclusion will have on the rate applications are developed today. Most development teams prize speed over everything else, with the possible exception of performance. However, the business executives that fund these projects are letting it be known they now have a much greater appreciation for cybersecurity, even if it requires more time to build applications.
Of course, building and deploying applications riddled with vulnerabilities never made much sense to cybersecurity professionals. The good news is that just about everybody else is now finally coming to the same conclusion.
Mike Vizard has covered IT for more than 25 years and has edited or contributed to a number of tech publications including InfoWorld, eWeek, CRN, Baseline, ComputerWorld, TMCNet, and Digital Review. He currently blogs for IT Business Edge and contributes to CIOinsight, The Channel Insider, Programmableweb, and Slashdot. Mike also blogs about emerging cloud technology for SmarterMSP.