As the world increasingly moves to the cloud and digital-everything, organizations’ risk postures have also changed. Embedding security into the business is the new, must-have approach and product security is the most seamless path to make it happen – led by the emergence of the engineering-centric CISO
Many top performers like Netflix, Github, Square have proven that integrating security into writing, building, and shipping code is one of the single most effective ways to improve overall security posture. That’s why mass adoption of DevSecOps is one of the biggest post-pandemic security trends.
Frankly, DevSecOps was already a hot topic pre-pandemic. As the quality and productivity benefits of DevOps have become well-established, layering in security and “shifting left” with DevSecOps followed as the next logical step.
However, even in 2022, many organizations are still in the early stages of their DevSecOps journey. Security is still often “the team of no”. Instead of being integrated into the SDLC from the start, security is tacked on post-deployment with vulnerability scanners and penetration tests.
The good news is that businesses recognize the gap and are trying to implement DevSecOps practices. A Cloud Security Alliance (CSA) report (PDF) found that 89% of organizations are actively adopting DevSecOps. Most of those organizations are still in the planning, designing, or implementing phases of their DevSecOps journey, which is indicative of where the market is headed.
In these early stages, organizations need to navigate the cultural and human side of DevSecOps adoption. Security has to stop being “the team of no” and become ingrained with the development lifecycle. Getting “Shift Left” right means leaning into the idea that “security is everyone’s responsibility” and making security a seamless part of the pipeline instead of something that happens post-deployment.
Getting “Shift Left” Right: A DevSec Ops Manifesto
What does that mean for the future of the DevSecOps? Here’s a short manifesto with implications for the market:
● Culture and mindset are more important than tools. I can’t overstate this point. Automation and tools are important, but adopting DevSecOps starts with a culture shift. Making the shift from security as a single team’s job –which often creates an almost combative relationship between security and development – to security as a shared responsibility takes time, effort, and dedication. This creates significant demand for consultancies that can help businesses successfully achieve a smooth transition.
● Software provenance and software composition analysis (SCA) must become a priority. Supply chain attacks, protestware, and opensource vulnerabilities like Log4Shell have made the importance of securing libraries and dependencies clear. Applications today depend on a wide range of software from third parties, and a security flaw in just one package can have a huge ripple effect. DevSecOps platforms like JFrog and GitLab make it easy for teams to secure their dependencies and trace software provenance can address this problem while easing the adoption of DevSecOps.
● Tooling needs to remove friction from security. For DevSecOps to be effective, security needs to be integrated directly into software delivery pipelines. If security integrations create bottlenecks and impede productivity, teams will begin to bypass them. Security must become part of how developers write, build, and deploy, not a separate process. That’s why it’s imperative for DevSecOps tools to tightly integrate with DevOps workflows. Examples of tooling getting this right include Synk and Veracode.
● DevSecOps tooling needs to handle compliance challenges. Compliance with standards like HIPAA, PCI-DSS, and SOX is a must for many businesses. Keeping up with all the audits, scans, and requirements often involves significant manual effort. “Compliance as code” solutions like Concourse Labs and IBM’s opensource Trestle (based on NIST’s OSCAL models) can add a lot of value here. By streamlining the compliance process with DevSecOps tooling and practices, teams can demonstrate business value and help create a positive feedback loop for broader DevSecOps adoption.
(You’ll notice I’ve left AppSec tooling out of the mix here. While important, and likely more primed for growth, AppSec is a distinct category that we should view as complementary to DevSecOps. The difference is simple: DevSecOps is everything from code to deploy, AppSec is post-deploy.)
To summarize, most organizations want to adopt DevSecOps practices, but their current practices are closer to traditional waterfall methodologies than the agile practices described in the DevSecOps manifesto above.
Therefore, the immediate hurdle facing most businesses is overcoming the challenges related to people and processes. For providers of DevSecOps services and solutions, the focus should be on removing friction from integrating security and helping teams come together to make security everyone’s responsibility.
Will is a Managing Director and a founding team member at ForgePoint Capital. He has been an avid technology enthusiast for decades: building his first computer in elementary school and starting online businesses while completing his bachelor’s degree from the University of California, Berkeley. Focusing on security startups for a decade, he has worked with more than 20 cybersecurity companies to date. In his spare time he’s a foodie with friends, enabling serendipity and building communities.Previous Columns by William Lin:Tags: