Why can’t developers fully realize the promise of DevSecOps?

…Because we don’t enable them with the right security tools. Let me explain. As a developer, I take pride in the code I write and I also feel a sense of achievement when I release functionality that matters to our customers. However, there were times when the security team members felt like hurdles in my path and that led to some rather interesting (to put it mildly) conversations. Over time as I evolved into an engineering manager, I realized (1) the importance of application security and (2) the fact that the security team is just trying to do their job and ensure we don’t release any exploitable vulnerabilities.

Let’s take a closer look at the traditional relationship between developers and the security team and how the evolution of DevSecOps shifted this relationship from disdain to collaborative. The following are typical scenarios I faced as a developer and a manager. Can you relate to either of these?

1. I look at the Jira board in the morning and think to myself, this seems like a heavy sprint with a ton of Jiras yet to complete. We review status updates for each team member during the standup meeting and then I start trying to knock off as many Jiras as I can today. Then I receive an email from a member of the security team with an attached report from the SCA tool we use. That thing is humungous so I let it sit there. I don’t have time for this now – I have Jiras to close, features to build, and bugs to fix!A couple of days go by and I receive a follow-up email, “Any update?”, from the security team member with my manager and the Director of the Security Team in Cc. Now I begrudgingly open the report again and start looking at the running list of alerts which are in no particular order. I end up spending four (4) hours just trying to make sense of it. I mark more than half of the alerts in the report as “False Positives”. I make a list of the libraries that have vulnerabilities and create Jiras for updating them. Quite obviously we can’t upgrade these libraries mid-way into the sprint since I know for certain that upgrading all of these will either break some functionality or cause some hard-to-debug issues, so I defer it to the next one. If only I could prioritize these issues or my team could have known that these libraries had vulnerabilities while developing the feature, we would have been saved a world of pain!
2. The release branch is ready. My team of developers pulled off a big feature in record time that a high profile customer wanted urgently. QA has also blessed the release. I am thinking of taking the team out to celebrate and then BAM! I get disappointing news:  the security team has flagged the release after running a DAST scan on it. It seems a few URLs we added for the feature are vulnerable and we will need a few days to fix them and get them retested by the security team. I know this is not going to bode well with the Product Manager who has already committed the feature to the customer. I dreadfully enter a meeting with the Product Manager, Program Manager, Director of Security, and Director of Engineering to decide the plan of action. Do we release with these vulnerabilities? The security team will certainly not entertain that possibility. Do we communicate to the customer that we will need another week to release? The customer is not going to be happy to hear that. Finally, the Product Manager rightly loses the battle with the security folks and informs the customer that we will release the critical feature next week. While we didn’t lose the customer over this, it definitely caused some short term strain in our relationship with the customer.

As the organization I previously worked for matured and started pitching to larger enterprises and channel partners, aspects like Security, Compliance, and Accessibility took center stage and hence, the beginning of DevSecOps. Several steps were taken to evangelise these within the organization: mandatory security training, sensitising the team about the importance of security and repercussions of ignoring it, onboarding compliance consultants, and special workshops led by security teams and functional QA teams. And you know what? These steps did help. Developers started to think about security while coding. They started to understand terms previously alien, like SAST, SCA, DAST, CVE, etc. Unfortunately, they didn’t have the tools to help them actually implement any of the training and knowledge they had gained. The saga of large reports filled with false positives remained and alert fatigue was pervasive. Regrettably, issues kept cropping up just before releases. So, the intent and spirit of DevSecOps were instilled but the tools weren’t there for developers to fulfill that intent.

Similar to how a lot of the operator tools “shifted left” to create the now well known DevOps role and market, we need tools to shift-left Security and Compliance. This may sound simple, but most security tools are not designed and built for developers, which means developers are not equipped to fulfill the promise of DevSecOps. Lack of tools designed for the job is a huge gap. The thing is, tools designed specifically for developers will greatly help organizations reduce the risk of finding issues late in the cycle and avoid issues slipping into production. This will also allow security teams and developers to communicate effectively, build a collaborative relationship, and hopefully end the unnecessary and inefficient tussle.

At DeepFactor, we created a continuous observability platform specifically for developers. A platform that will give them the visibility they need to build secure applications during their development cycle. I joined DeepFactor for two main reasons: (1) I identify with the pain point they are trying to solve – I’ve felt that pain myself; (2) to solve the problem and build Continuous AppSec Observability tools designed specifically for DevSecOps to shift-left Security, Privacy, and Compliance. We offer our product for free to small teams and open source projects, so I encourage you to register HERE and begin seeing results today.