DevSecOps has become an increasingly popular topic as enterprises grapple with the continuing challenge of improving their cybersecurity infrastructure. As the first quarter of 2020 has come to a close, are we making significant progress in fully integrating the development, operations and security functions in the enterprise?
The term “DevOps” was first used in 2009 by an IT consultant, Patrick Debois. Little more than a decade later, the IT industry is evolving to DevSecOps in response to the global cybersecurity threat and the realization that a more concerted effort is needed to effectively mitigate risk.
One of the challenges is that DevOps itself is still not fully utilized in many enterprises, making those organizations more reluctant to embrace the idea of adding tighter integration with security teams and frameworks. Anyone who has worked in an organization knows implementing a cultural shift is difficult at best and not an overnight success. Moving from DevOps to DevSecOps does require such a shift.
From Inertia to Integration
The Oracle Java 8 end-of-life story is a great illustration of the need to better integrate security into development and operations. Java applications traditionally were developed and delivered, and the inevitable security updates became the responsibility of the operations team to update the Java Runtime Environment (JRE) on each system that would utilize the application. This inevitably became a struggle of compatibility issues that resulted in exceptions versus resolving the security issues by updating Java.
Java 10 resolves this struggle by creating a more symbiotic experience where the runtime components are baked right into the Java application as it is built. With this change, the dev team needs to take ownership of regular updates to the application to resolve security vulnerabilities, but this shift is slow in coming. Java 8 applications are still a critical part of many operations, even after the end of life of version 8, and companies now turn to OpenJDK and Corretto Java to continue in the legacy model.
This is where inertia comes in. Enterprises stick to legacy systems, such as the Java 8 applications, and continue the cycle of compatibility issues preventing updates required to resolve security vulnerabilities. They have little or no attention from busy security staff, which long ago moved on to critical projects like protecting against the next WannaCry.
Better integration–putting the Sec in DevSecOps more front and center–can be done.
Here are some considerations to move from inertia to integration.
Take Charge
The concepts of ownership and responsibility need to change. A development team that has created a specific product needs to be responsible for taking care of future application needs, such as patching updates. The old-fashioned “We developed it; now we throw it over the wall to operations” doesn’t work in an integrated environment. The team needs to continue responsibility into the operation phase. This ends the volleying back and forth on who “owns” updates, and makes bugs, fixes and patching the DevSecOps team’s responsibility.
Get Your Track Shoes on
Thanks to the plentiful options technology offers, enterprises are using varied development tools, browsers and vulnerability scans. This adds up to challenges since traditional patching is no longer always possible. At the same time, failure to execute updates in real time leaves the enterprise vulnerable to threats. For example, Microsoft introduced the new Edge Chromium edition which utilizes Google’s Chromium open source framework. Google had three Chrome releases between this year’s regular January and February Patch Tuesday events. This meant Microsoft had to integrate Chromium updates in real time or delay resolution to critical vulnerabilities for its customers. As another example, if an enterprise has an internal browser that used Chromium, the same updates have to be pushed out to protect users from threats.
Think Totality of a Fix
The best way to achieve integration is to ensure security is baked in as part of the development and operations process from the beginning. Before a new product/application is launched, a united DevSecOps team will be aware of all the components in that product, all the vendors who will have updates related to those components and the expected cadence of these updates. For enterprises updating a web or SaaS-based application, updates should be doable fairly quickly.
Make Security First
Time-to-market pressures abound but the strategic DevSecOps professionals are placing risk mitigation before operational impact. They are doing this in a landscape in which cyber hygiene continues to be an issue. Legacy systems are not being patched correctly; updates are being done too late, or not at all. To counter this, enterprises need to adopt a security first principle and improve the timeliness and thoroughness of patching and updates.
Know Your Vendors
A must-do is for DevSecOps to fully investigate what patching/updates a particular third-party vendor provides, what their release cadence is and what risk exposure it may present by not covering certain releases/companies. As part of this scrutiny, discern which vendors are responsive to security risks and which are not. With so many companies–Microsoft, Oracle, et al.–executing varied release schedules, adding automation into DevSecOps can further ensure updates are done in real time and cyber hygiene can be improved.
Fulfilling the DevSecOps Promise
DevSecOps can begin to reach its potential by paying attention to the people factor and using technology as a support rather than another headache. Whether an employee is in development, operations or security, they are working for the same organization.
By introducing more automation into the process, gaining a clearer picture of all relevant components and the third-party vendor release cadence, and making security a participant at the beginning of new product development, smoother updates, better security and a productive culture will result.