By: Sean Wright, Head of Application Security, Featurespace | Paul Davis, Field CISO, JFrog
DevOps engineers and Security professionals are passionate about their responsibilities, with the first mostly dedicated to ensuring the fast release and the latter responsible for the security of their company's software applications. They have many common goals, but when a secure software supply management program is launched, very quickly, according to many CISOs we’ve spoken to, a misunderstanding of needs and priorities arises.
The disconnect starts when DevOps perceives that precautionary security measures are just slowing down the release cadence. Security, in the meantime, appears to be only focused on the potential consequences of neglecting security posture, such as data breaches, reputational damage and legal implications, and doesn’t understand the needs of the DevOps teams.
Ironically, both teams want the same thing, to create solutions that enable the organization to deliver services and capabilities, in an efficient, safe and secure manner.
Both are essentially correct, but there is a certain conflict of interests.
For any organization, speeding up development and protecting today’s software supply chain is a challenge. It encompasses pretty much everything that has to do with software production from the initial ideation and design phase, to coding, testing, deployment and ongoing maintenance.
In fact, the increasing complexity and interconnectedness of software systems, together with the explosion in the use of open source software, has made securing the software supply chain a critical aspect of ensuring overall cybersecurity. One of the key areas around secure software chain management, is managing the risks associated with vulnerabilities.
To ensure that we’re leveraging the skills and powers of each team, it’s essential to align security at every step of the development process and understand the nature of potential vulnerabilities in terms of prevention, detection and remediation. One of the main issues when discovering a vulnerability is to fully understand where it’s located, the true severity of the threat, and the best way to handle it.
On top of that, and especially following the recent National Vulnerability Database (NVD) saga, it’s becoming increasingly difficult to get appropriate information about the vulnerability itself. Still, there’s certainly no need to get stuck in a Fear, Uncertainty and Doubt (FUD) mindset because of a known vulnerability, and start implementing unrelated security procedures instead of concentrating on mitigating the vulnerability itself.
It’s important to ensure that the vulnerability is applicable to your situation. Don’t fall into panic mode, as described in a previous post regarding how companies overreacted in responding to the Log4j vulnerability. Instead, address the issue at hand as well, leveraging the combined perspectives of the two teams, in a balanced, respected collaborative effort.
What Interests DevOps and Security Teams
While both teams share the overarching goal of maximizing efficiency and minimizing costs, when it comes to specific objectives, that’s where the friction starts.
On the one hand, most DevOps teams are interested in:
- Ensuring a smooth unhindered development process
- Delivering quality software releases according to business requirements
- Speed to get software to production
- Less revisiting the code to fix issues
On the other hand, Security professionals are rightly concerned with:
- Ensuring the security of all software packages
- Minimizing risk by preventing, identifying and mitigating vulnerabilities
- Speed to detect security issues
- Less coding and vulnerability issues
Bringing Your Dev, Sec and Ops Teams Together
While these values aren’t necessarily at odds with one another, you don’t have to be a systems analyst to understand where they can be working at cross purposes. For example, when a release needs to get out the door and Security is holding it back due to an obscure vulnerability in an old version of an open source package, serious conflict can arise as to whether the software is safe for distribution or not.
Likewise, when DevOps prevails and prematurely comes out with a release, without proper scanning of open source packages, it can result in potential security risks falling through the cracks, and possibly leading to financial loss and damage to the brand once the vulnerability is revealed.
These examples show where friction or misunderstanding can hinder the prevention of vulnerabilities and potentially slow down the software release process.
Take Aways
Both DevOps and Security teams should aim to enable developers – DevOps to make it easier on developers to develop new software and release it quickly, and Security to ensure developers have access to appropriate tooling and knowledge, with security measures in place, to help prevent them from making serious mistakes.
Recognizing that DevOps and Security have divergent interests is a good first step, but at the end of the day, DevOps needs to understand the importance of maintaining security posture, while Security must be committed to streamlining its vulnerability prevention, detection and remediation. So the issue really becomes:
Does there have to be friction between DevOps and Security at all?
That is really an excellent question and just happens to be the subject of our next blog. We’ll delve deeper into this issue and provide insights about the benefits of DevOps and Security teams streamlining vulnerability management.
After all, both DevOps and Security work for the same organization and are ultimately part of the same extended team, which shares the joint goal of minimizing risk and increasing operational speed and efficiency.
