For years, DevOps has grown in popularity and is now, inarguably, table stakes for any enterprise looking to make development efforts a competitive advantage. So, for those enterprises who have made their DevOps process an ingrained part of their overall development stance, should they consider DevSecOps? How does that impact their development team, and, of equal importance, the security team and overall cybersecurity stance?
At the highest level, DevSecOps refers to building security into application development from end to end. The common DevSecOps term “shift left” refers to the infusion of security earlier in the development process and is at the core of this new movement.
So why should organizations consider DevSecOps? In a nutshell, it’s because this approach enables enterprises to take advantage of three distinct benefits for both security and development teams.
#1: A “shift left” DevOps approach provides critical, immediate feedback
Development teams are under immense pressure to deliver high-quality applications to market quickly and accurately. Traditionally, the pressure associated with intense deadlines mean security issues or warnings are passed over, with a ‘fix it later’ mentality.
This creates several challenges that are hard to fix. After all, it is far more difficult and costly to address security issues once an application is live and used by a wide number of users. Undoubtedly, these challenges have resulted in the growth of the movement to “shift left,” or infuse security principles earlier into development practices. This approach is becoming more popular because it provides immediate feedback to the development team as security issues arise, enabling these to be resolved before the application goes live.
A DevSecOps team can run point on a “shift left” initiative, acting as advisors who can spot design or implementation issues as they arise in the development process and implement a process to resolve these issues. This can include providing immediate examples of issues with code and enables a focus on immediate remediation as opposed to a “shift right” mentality, where accountability for security issues is passed down the line.
#2: Eliminate traditional silos separating IT security and development teams
Shifting left eliminates silos by creating a culture of security that development more naturally adopts versus an almost “shift right” approach that leans on the security review at the end of the development process. A DevSecOps team does not simply lift security responsibility from development teams, rather, it makes security something both security and development teams must keep top-of-mind. The team should include developers who understand and have an interest in implementing a “shift left” approach and are invested in training their peers in both the value of including security earlier in the development process as well as how this can be done in a way that increases efficiency.
A particular pain point in large enterprises, development teams are focused on their core outcome — delivering high-quality applications — and security teams are focused on their core outcome — ensuring these applications are secure. This siloed approach creates significant issues. Take authorization as an example. For years, developers hard-coded authorization policy directly into each application, creating a myriad of unique policies that could conflict and often didn’t align to broader access control or security policies, which were developed by the security team. This made a central view of the broader enterprise’s authorization policies and adherence to specific compliance initiatives challenging to decipher, to say the least.
#3: DevSecOps ensures security and development teams speak the same language
This may seem obvious, but it bears repeating. When security teams try to force policies on various stakeholders, they’re rarely adopted without frustration. A DevSecOps strategy is only accomplished if both security and development teams collaborate and align on policies together. Security teams are tasked with ensuring an organization adheres to security policies. Specific ways in which security can be applied to development practices falls under this purview, but can fall through the cracks, as security practitioners may not be familiar with development practices, coding languages and DevOps processes. This means that by working directly with developers, security avoids creating broad or high-level guidelines that miss the mark or simply aren’t prescriptive enough to be implemented early in the application development process.
Establishing a DevSecOps team and practice forces collaboration between the security and development teams. A mix of both development and security professionals, this team has the experience and credibility to provide specific guidance around security issues in the development process. They can spot security issues in design, coding or execution, ensure security is designed into the application and add a security point of view to development-specific issues such as bug triage or prioritization.
As more enterprises embrace and mature their DevOps strategy and processes, there’s an increased pressure for developers to deliver more, faster and without issue. While traditionally security has been bolted on at the end of development initiatives and considered as a separate initiative, the reality of development and security challenges for modern enterprises makes this an untenable path forward. Implementing a DevSecOps team consisting of members of both development and security teams will enable enterprises to fully embrace a “shift left” philosophy and enjoy the increased efficiency associated with DevSecOps processes.
