Achieving DevSecOps Requires Cutting Through the Jargon

When it comes to developer and security teams, the word of the day is friction. On one hand, developers are focused on creating and moving as fast as possible. On the other, security teams are typically injected into the process at inopportune times to remediate software vulnerabilities.

This incohesive dynamic interrupts the flow and speed developers like to operate, causing developers to see security as a roadblock rather than a group they should be working with hand-in-hand.

Business leaders understand the general importance of establishing a culture of "DevSecOps" within their environment, where developers and security work seamlessly together to accomplish a common goal. But getting them on the same page is a mounting challenge. Both have been traditionally fragmented areas of business and work in deeply technical environments with completely different agendas.

As with any department, developers have jargon they use that is foreign to those not deeply involved in the intricacies of software development. Establishing a culture where security can work easily with developers starts with making sure they can at least speak the same language.

To help bridge the gap, I broke down some of the common initiatives and terms that developers use and security pros should know to help get them on the same page and best integrate security into their processes.

• "Shifting left": This should really be called "expanding left" (but that's a point and argument for another day). Shifting left simply means that software and systems testing should happen early in the life cycle to catch defects and bugs quickly. With developers focused on speed and innovation, finding bugs late in the software development process slows them down too much. Shifting left aims to avoid mistakes from impeding development. 

This matters from a security standpoint for a few reasons. With increasingly fast DevOps cycles, developers inevitably have a greater responsibility to secure code because security demands their attention more frequently. Traditional security gates simply aren't enough to keep up with this fast pace, hindering not just speed but innovation, too. Security pros also have to shift left to help embed security right into development processes. When this happens, an organization goes from a DevOps to a DevSecOps culture, where both teams contribute significant value by working in tandem.  

• "Continuous integration": Continuous integration (CI) means that code changes are automatically integrated from multiple contributors for one piece of software. For developers, this process is incredibly interactive and quick. When you hear developers talk about CI, they mean the changes being made across their teams are being implemented automatically to improve the software in development as a collaborative effort.

For security, this is valuable to know because of the real opportunity to enforce secure coding practices and vulnerability assessments at this stage. For example, static code analysis early in the software development life cycle can help identify bugs that would normally hit production. When vulnerabilities are removed preproduction, it's a win not only for the security folks but the developers as well because they don't have to rewrite the code further down the line (or roll anything back).

• "Regression testing": Regression testing is pretty simple. It's the end-to-end testing of a new or updated application to make sure that updates or modifications don't negatively impact how the application operates for end users. And it's a process where security should definitely be involved.

During regression testing, security should seize the opportunity for collaboration. Just as developers want to test the product for functionality issues, security should examine the app to identify weaknesses that could be exploitable. This way, proper security gates can be put in place to mitigate vulnerabilities before production.

When security is involved in the regression testing process, the engine is tested from both a functionality and vulnerability standpoint before being rolled out — resulting in high-performing and more secure software.

• "Canary rollout" and "failing forward": These two pretty much go hand-in-hand. A canary rollout is when developers roll out a new or updated software version to a small subset of users to assess how well it operates prior to a mass rollout. Failing forward is when developers find an issue during a canary rollout and make adjustments on the fly rather than rolling back to an old version or impeding development.

Just as developers test for performance issues within a smaller environment during a canary rollout, security can be involved in the process as well by monitoring a small subset of users within a lower risk environment. It's almost like a test drive to see how well the final product will fare once unleashed into the wild.

Achieving DevSecOps
It obviously takes more than learning new terms and initiatives to embed security into developer processes, but one of the most pivotal first steps security teams can take is collaborating closely with developers to understand where security should be involved to add real value.

It’s understandable that development teams want to innovate as quickly as possible, and security teams should be empathetic of that. It's also understandable that security teams want developers to help ensure their innovations don't ignore proper security, and development teams should be empathetic of that.

The key and only path forward is a combined approach where both sides collaboratively work together to achieve the common goal of pushing out innovative software quickly that is also as secure as possible. Until that mindset shift happens, however, both parties will continue to point to the other as hindering progress.

Related Content: