Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

10:00 AM
Mario DiNatale
Mario DiNatale
Connect Directly
E-Mail vvv

Achieving DevSecOps Requires Cutting Through the Jargon

Establishing a culture where security can work easily with developers starts with making sure they can at least speak the same language.

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:


Mario DiNatale serves as head of platform security at ZeroNorth. Prior, he was CTO at Kyber Security and CIO of the Town of Hamden. In addition, Mario acts as a mentor and adviser to numerous startups. Even while acting in an executive capacity, he still remains regularly ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
3/20/2020 | 5:20:08 PM
Seems like the correct perspective
Good to see this perspective - security should learn how to integrate into development workflows and tooling, or the engineering teams will just pass them by. Too often, it is positioned as we should teach devs more about security through training. That is not bad per se, but good tooling and shifting security closer to the engineering team will be far more effective.
Ransomware Is Not the Problem
Adam Shostack, Consultant, Entrepreneur, Technologist, Game Designer,  6/9/2021
How Can I Test the Security of My Home-Office Employees' Routers?
John Bock, Senior Research Scientist,  6/7/2021
New Ransomware Group Claiming Connection to REvil Gang Surfaces
Jai Vijayan, Contributing Writer,  6/10/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: Google's new See No Evil policy......
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-06-18
Contiki-NG is an open-source, cross-platform operating system for internet of things devices. The RPL-Classic and RPL-Lite implementations in the Contiki-NG operating system versions prior to 4.6 do not validate the address pointer in the RPL source routing header This makes it possible for an attac...
PUBLISHED: 2021-06-18
Contiki-NG is an open-source, cross-platform operating system for internet of things devices. In verions prior to 4.6, an attacker can perform a denial-of-service attack by triggering an infinite loop in the processing of IPv6 neighbor solicitation (NS) messages. This type of attack can effectively ...
PUBLISHED: 2021-06-18
Contiki-NG is an open-source, cross-platform operating system for internet of things devices. It is possible to cause an out-of-bounds write in versions of Contiki-NG prior to 4.6 when transmitting a 6LoWPAN packet with a chain of extension headers. Unfortunately, the written header is not checked t...
PUBLISHED: 2021-06-18
Contiki-NG is an open-source, cross-platform operating system for internet of things devices. A buffer overflow vulnerability exists in Contiki-NG versions prior to 4.6. After establishing a TCP socket using the tcp-socket library, it is possible for the remote end to send a packet with a data offse...
PUBLISHED: 2021-06-18
Contiki-NG is an open-source, cross-platform operating system for Next-Generation IoT devices. An out-of-bounds read can be triggered by 6LoWPAN packets sent to devices running Contiki-NG 4.6 and prior. The IPv6 header decompression function (<code>uncompress_hdr_iphc</code>) does not pe...