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.
User Rank: Apprentice
3/20/2020 | 7:09:02 AM
USually devops everything that includes doing stuff
COVID-19: Latest Security News & Commentary
Dark Reading Staff 5/27/2020
The Problem with Artificial Intelligence in Security
Dr. Leila Powell, Lead Security Data Scientist, Panaseer,  5/26/2020
How an Industry Consortium Can Reinvent Security Solution Testing
Henry Harrison, Co-founder & Chief Technology Officer, Garrison,  5/21/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-05-28
An issue was discovered in the SiteOrigin Page Builder plugin before 2.10.16 for WordPress. The live editor feature did not do any nonce verification, allowing for requests to be forged on behalf of an administrator. The live_editor_panels_data $_POST variable allows for malicious JavaScript to be e...
PUBLISHED: 2020-05-28
An issue was discovered in the Accordion plugin before 2.2.9 for WordPress. The unprotected AJAX wp_ajax_accordions_ajax_import_json action allowed any authenticated user with Subscriber or higher permissions the ability to import a new accordion and inject malicious JavaScript as part of the accord...
PUBLISHED: 2020-05-28
An issue was discovered in the Real-Time Find and Replace plugin before 4.0.2 for WordPress. The far_options_page function did not do any nonce verification, allowing for requests to be forged on behalf of an administrator. The find and replace rules could be updated with malicious JavaScript, allow...
PUBLISHED: 2020-05-28
An issue was discovered in the SiteOrigin Page Builder plugin before 2.10.16 for WordPress. The action_builder_content function did not do any nonce verification, allowing for requests to be forged on behalf of an administrator. The panels_data $_POST variable allows for malicious JavaScript to be e...
PUBLISHED: 2020-05-27
A cross-site scripting vulnerability (XSS) in Trend Micro InterScan Web Security Virtual Appliance 6.5 may allow a remote attacker to tamper with the web interface of affected installations. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or ...