Are we being failed by DevSecOps? [Q&A]
Over the years, security vendors have pushed companies to integrate their tools into the DevOps pipeline with the promise of being able to move faster and be more secure.
However, as businesses have matured their DevSecOps practices the more they have been hit by mountains of reported vulnerabilities and problems that have slowed them down. So, has DevSecOps failed in its promise? We talked to Eitan Worcel, CEO at Mobb, to find out.
BN: DevSecOps was intended to cut friction between business and security, has it failed to do this?
EW: The introduction of DevSecOps definitely improved the situation compared to the days when people only scanned code before it went into production, but it didn't come close to eliminating the friction. In fact, it seems that the more an organization matures in adopting DevSecOps, the more its developers are penalized from the growing number of tools they must use in the development pipeline, resulting in more issues that require fixing and adding more roadblocks in creating new innovations. Some try to blame this dynamic on the idea that developers hate security, but that is not actually true. Developers want to write secure code and produce secure applications, but tend to prioritize productivity when security policies or tools are too clunky or time consuming. This frustrates security teams who are mostly being measured on different KPIs and don't share the same priorities, and as a result struggle to secure it properly.
BN: Is part of the problem simply too much information?
EW: Yes. Too much information without enough context, which leads to too many alerts and a never ending backlog of issues. This is because most organizations don’t have the ability to differentiate between false positives, benign issues or critical security vulnerabilities. One SAST scan, for example, can find thousands or tens of thousands of issues. Security teams end up overwhelmed with alerts and struggle to prioritize the ones that are needed, which led to the introduction of tools such as ASPM and CSPM.
And with the famous security resource shortage developers are expected to sift through findings to prioritize and fix code based on mediocre data. The bigger problem is the fact that developers are expected to do this effectively and efficiently, without ever having been taught to do so as part of their career training. Organizations spend money and resources providing on-the-job training, but it’s hard to change coding habits once they have been formed.
BN: Have security measures failed to keep up with the way that people work?
EW: DevSecOps tools and policies have improved in covering more attack surface and integrate into the DevOps toolset finding more issues earlier in the development lifecycle, but have failed in helping teams productively act on the findings to actually make applications more secure. Finding more bad things earlier doesn't make them easier to fix, it just disrupts progress sooner. Fixing a single reported code vulnerability can take around five hours. Multiply that by hundreds or thousands of issues found in each scan and the problem becomes more clear. Failed security measures also contribute to the friction mentioned earlier. If security is not simple and complementary to how developers work, it won't be adopted as a natural part of the development lifecycle.
BN: What should development teams be doing to make the most of DevSecOps?
EW: Development teams should be part of decision making when adopting policies and technologies. When they have influence in the security process, adoption rates are higher and friction is lower. Effective DevSecOps also relies deeply on automation. With the proliferation of generative AI, organizations should be embracing AI-informed automation that assists in fixing code problems. However, embracing AI does not mean relying on it blindly. I'm not suggesting everyone start asking Chat GPT to 'fix my code' and hope for the best. Generative AI is only as good as the information it is trained on, so implementing the right guardrails when relying on AI is important. This will help eliminate backlogs, relieve the security burden on development teams, make applications more secure and release new innovations faster.
BN: How do you see the future for DevSecOps?
EW: Success will require delivering on the true spirit of the term -- Dev (innovation), Sec (securing applications to protect the organization and its customers) and Ops (driving business forward, efficiently). For DevSecOps to succeed, security and development need to be prioritized equally, and executed cohesively. This requires synergy between the two teams, and compromise to accommodate expectations and workflows on both sides. There will never be enough people or processes to achieve harmony between these three goals, and we'll only find more issues as application scanning capabilities advance. Technology will have to carry the load in this equation and shift from simply finding more problems to providing the fixes for them.
Image credit: jaizanuar/depositphotos.com