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.
7 Old IT Things Every New InfoSec Pro Should Know
Joan Goodchild, Staff Editor,  4/20/2021
Cloud-Native Businesses Struggle With Security
Robert Lemos, Contributing Writer,  5/6/2021
Defending Against Web Scraping Attacks
Rob Simon, Principal Security Consultant at TrustedSec,  5/7/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
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-05-13
A Denial of Service due to Improper Input Validation vulnerability in the Management Console component of BlackBerry UEM version(s) 12.13.1 QF2 and earlier and 12.12.1a QF6 and earlier could allow an attacker to potentially to prevent any new user connections.
PUBLISHED: 2021-05-13
A Remote Code Execution vulnerability in the Management Console component of BlackBerry UEM version(s) 12.13.1 QF2 and earlier and 12.12.1a QF6 and earlier could allow an attacker to potentially cause the spreadsheet application to run commands on the victim’s local machine with t...
PUBLISHED: 2021-05-13
An Information Disclosure vulnerability in the Management Console component of BlackBerry UEM version(s) 12.13.1 QF2 and earlier and 12.12.1a QF6 and earlier could allow an attacker to potentially gain access to a victim's web history.
PUBLISHED: 2021-05-13
Specific versions of the MongoDB C# Driver may erroneously publish events containing authentication-related data to a command listener configured by an application. The published events may contain security-sensitive data when commands such as "saslStart", "saslContinue", "i...
PUBLISHED: 2021-05-13
SchedMD Slurm before 20.02.7 and 20.03.x through 20.11.x before 20.11.7 allows remote code execution as SlurmUser because use of a PrologSlurmctld or EpilogSlurmctld script leads to environment mishandling.