DevSecOps

Trend Report

B RO UG H T TO YOU I N PA R T NER SH I P WI T H
 Table of Contents
3 Highlights & Introduction
B Y PE T E R C O N N E LLY

4 Key Research Findings

B Y T H E E D I TO R IA L T E AM

8 Shifting Everywhere: DevSecOps Gets Real

B Y J E FF WI LLIAMS

11
The Trail DevOps Blazed: Security’s Journey
Ahead
B Y PI E R R E B E TO U I N

13
Open Source Security as a Use Case for
DevSecOps Adoption
B Y M I CHA E L H O LL A N D E R

16
Successful DevSecOps Teams Proactively
Automate Responsibility
B Y CHA SE D O E LLI N G

19 Diving Deeper Into DevSecOps

20
Executive Insights on the State of
DevSecOps
B Y TO M SM I T H

To sponsor a Trend Report:

Call: (919) 678-0300
Email: [email protected]

DZONE TREND REPORT: DEVSECOPS PAGE 2

ORIGINAL RESEARCH

Highlights & Introduction

By Peter Connelly, Content Coordinator at DZone

For years, security has been an afterthought — functionality that developers and product managers often address at the last
minute, right before a build is about to ship. For some individuals and teams, this practice stems from a reactive approach to
security, in which vulnerabilities are expected to be dealt with only once they’re discovered after a release. For others, this stems
from prioritizing additional features and functionality (and immediate ROI) over security (and minimizing risk). For most, however,
the cause of this issue is more systematic in nature.

Businesses today expect speed from development teams. Too often, the questions that leaders and managers ask concern the
time of the next deployment or how soon a bug can be fixed, rather than how well a problem is addressed. This mindset is
innately oppositional to ensuring the security of an application. Security, like any other part of software development, is iterative; it
takes rounds of testing and attention to detail from all stakeholders involved in order to eliminate vulnerabilities.

Increasingly, more organizations are beginning to realize this, and as a result, they have started to incorporate security into their
DevOps pipelines. With this in mind, we sought the opinion of industry professionals and leaders about the state of DevSecOps
adoption and implementation to help readers understand more effective ways to manage security throughout the SDLC.

In “Successful DevSecOps Teams Proactively Automate Responsibility,” Chase Doelling refutes the common misconception that
security and DevOps cannot coexist. The same attention that’s given to software development in DevOps simply needs to be
shown to security as well. Chase states, “continuous delivery means that you need to start secure and stay secure.” Just as unit
and integration testing are expected to be performed throughout the SDLC, so should vulnerability testing.

Chase then attacks the root of this issue, as he brings up ownership as one of the key reasons that security is often not a
priority in development. According to Chase, “lack of ownership is what leads to security being treated separately, and worse,
as an afterthought. The moment you feel like it’s not your responsibility, you don’t own the outcome fully and will defer when
questioned.”

Michael Hollander furthers this discussion in “Open Source Security as a Use Case for DevSecOps Adoption,” pointing out how
well developers test and ensure the security of open source tools they use in their applications. He then uses this model as a road
map to show developers how easily best practices for open source vulnerability testing can be employed in a DevOps pipeline. In
“Shifting Everywhere: DevSecOps Gets Real Fast,” Jeff Williams expands on Hollander’s road map and provides a step-by-step
process that focuses on automation and continuous monitoring to implement DevSecOps within an organization.

In the following section, we bolster these claims with an analysis of a survey of 391 software developers, engineers, and architects
concerning the state of security in their organizations’ DevOps pipelines.

DZONE TREND REPORT: DEVSECOPS PAGE 3

ORIGINAL RESEARCH

Key Research Findings

By the Editorial Team, DZone

Security has never taken on a more prominent role in our industry than it currently does. As more applications and platforms
migrate to the Internet, the risks presented by the cloud environment have refocused attention on the important role of security.
DevSecOps attempts to take on one of the most fundamental issues facing software teams — how to inject security into the
DevOps pipeline without slowing down the process. The balance between speed to market and risk mitigation is tricky to find. We
hope to use our research to help illuminate the challenges and opportunities that the industry faces.

DZone conducted a quantitative survey among its global audience of developers, architects, and software engineers during July
and August of 2019. The report that follows summarizes the findings from the 391 respondents.

Role of the DevOps Team

The DevOps function is a growing focus for companies globally. Currently, half (49%) of the organizations represented have an
officially designated DevOps team. Not surprisingly, DevOps teams are found more often the larger the company size is. Among
the smallest companies, one-third (32%) have an official DevOps function, with the proportion increasing for each company size
until it is nearly two-thirds (64%) for companies with 10,000 employees or more.

All four goals of the DevOps function are embraced

by the organizations represented by the majority
of our developers. “Helping the organization adopt
the best continuous delivery tools” led all four with
69.7% identifying it as one of their DevOps team’s
goals. “Introducing automation across the software
development lifecycle” was second with 68.3%. The
third goal, with 56.4%, was “increasing collaboration
and breaking down the silos between development and
operations.” “Developing and delivering software across
the entire stack” ranked fourth with 54.1%.

Adopting the best CD tools becomes a more wide-

spread goal as the organization size increases.
Two-thirds of the smallest organizations (under 100

DZONE TREND REPORT: DEVSECOPS PAGE 4

employees) identify it as one of their goals. And 81.3% of
the largest companies (over 10,000 employees) cite it as
one of their goals. Adoption of the other three goals did
not correlate to company size.

Security Initiatives Have Plenty of

Room for Improvement

The software delivery process at most companies does

not include security issue detection (30.6% have it) or
compliance checks (28.1% have it). An official DevOps
function at the organization improves the chances that
security issue detection and compliance checks are
included in the software delivery process.

Generally, organizations that have a DevOps function

in place are about twice as likely to have security issue
detection and compliance checks included in their software delivery process. However, less than four in ten organizations with
DevOps teams have these important processes in place. That means that we still have a long way to go to ensure that we are
addressing security and compliance issues throughout the software delivery process.

Security policy automation has not taken hold in many organizations yet. Only 17.6% of companies currently automate their
security policy configurations. Not surprisingly, it is more prevalent in companies that have a designated DevOps function (22.8%)
than those without (12.6%). This result suggests, again, that security has not yet been integrated with DevOps.

What Will Impact Security Decisions?

What will have the highest impact on an organization’s application security decisions? What developers see are all external forces.
Regulatory requirements top the list, cited by over a third of respondents (36.5%). Customer requirements (20.4%) trail closely,
and in third place, security awareness organizations such as OWASP and SANS with 16.7%. All other potential influences follow
substantially behind. As far as the outlook for the
future, developers do not foresee any change to these
priorities in the next 6-12 months.

It should not surprise anyone to see that the larger

an organization’s size, the more impactful regulatory
requirements are perceived to be. The perceived
impact of regulatory requirements for the largest
organizations is twice the impact seen by the smallest
organizations (45.3% vs. 23.0%). On the other hand,
organizations with fewer than 100 employees say that
customer requirements will have the greatest impact
on their application security decisions, with 33.6%
identifying it as the most impactful.

An interesting pattern seen throughout the survey

data is that, regarding security concerns and decisions, companies with fewer than 100 employees stand out quite distinctly from
all larger companies. When companies have more than 100 employees, security issues are treated more alike, only varying in
proportion and not taking different directional approaches for the most part.

DZONE TREND REPORT: DEVSECOPS PAGE 5

 How Does Security Fit Into the
Software Development Pipeline?

One concern of developers is the balance between speed

to market and assuring the security of their applications.
Best practices say that time should be spent on security
at every stage of the pipeline, but that in general, more
time spent earlier means fewer problems will emerge
later. We asked our developers to tell us where in the
software development pipeline they spend the most time
on security. We see a spread across all aspects of the
lifecycle, with a general tendency toward the earlier side
but not as early as some might hope. Nearly a quarter
(23.5%) say that the most time is spent on security
during coding, followed by 18.4% on design, 15.9% on
requirements gathering and analysis, 12.6% on testing, 10.3% on deployment, and 9.9% on maintenance.

Four out of ten of our developers (40%) say that their organizations’ release schedules override security concerns at least
sometimes, and another 13.2% say that they have no idea if this happens. It happens rarely for 30.3% of the respondents, while
only 16.5% say it never happens. These proportions remain consistent across all organizational sizes. Companies with a DevOps
team are only slightly more likely to say it never happens (18.2%
vs. 14.8%).

Perhaps the two findings above — one, that teams do not spend
the most time on security in the requirements gathering and
design stages, and two, that most companies have occasions
when release schedules override security concerns — are the
reasons why security analysis and vulnerability fixes have a high
or medium impact (16.3% and 30.5%, respectively) on the team’s
ability to release on time and on budget. We also see that the
larger the organization, the more frequently they say it has a high
or medium impact.

Fully, 60% in the largest companies (10,000 employees or

more) say that security analysis and vulnerabilities fixes have
a high or medium impact on their team’s ability to release
on time and on budget. The majority (53.9%) of companies
between 1,000 and 10,000 employees say it has a high
or medium impact as well. Any impact is of concern, but
even more so when we see it at such high thresholds. That
result certainly reinforces the voice of many in the software
industry who identify security as one of the leading issues to
be addressed.

Conclusion

Although many in the industry espouse the need for

DevSecOps, believing it essential to emphasize the need to
build a foundation of security into DevOps initiatives, our

DZONE TREND REPORT: DEVSECOPS PAGE 6

data suggests that it is still in a quite early stage. Adoption of security initiatives as part of the software development and delivery
process is far from commonplace.

The key now is to uncover why the DevSecOps approach has not been integrated more. Is it just too difficult? Having a designated
DevOps function specified within the organization appears to be the first step, as our evidence clearly suggests that the DevOps
function encourages better integration of security tools and processes into the software development lifecycle. But addressing
security issues within the SDLC still lags the adoption of DevOps. Security concerns continue to mount as movement to the cloud
increases. Security is not a sexy or interesting topic to most, but it is a necessary aspect of the world we live in. We hope that
attention to security increases so that any potential crisis can be averted.

DZONE TREND REPORT: DEVSECOPS PAGE 7

OPINION

Shifting Everywhere:
DevSecOps Gets Real
By Jeff Williams, Co-founder and CTO at Constrast Security

We’re Not Very Good at Writing Secure Code

TREND PREDICTIONS
The application security problem is already very serious. As more and
▶ The risk of attack on virtually every appli-
more businesses are turned into software via digital transformation...
cation is increasing steadily as enterprises
it’s getting worse, fast. Vulnerabilities are widespread across
entrust more data and resources to software.
enterprise web applications and APIs. On average, applications have
over 25 serious custom code vulnerabilities as well as several libraries ▶ DevSecOps spans the entire SDLC, and

with known vulnerabilities. teams are “shifting left” to identify vulnera-

bilities and “extending right” to monitor and
Perhaps even more terrifying, virtually all applications are attacked defend.
every month. This has been the status quo for the past decade. But as
▶ Automation across DevSecOps is trending
enterprises entrust more of their business, and more importantly data,
toward an instrumentation-based, inside-out
to this software, the risk increases steadily. To help you understand approach that prioritizes high-speed, accu-
the current risk level, the chart below shows the likelihood that a rate, and continuous security.
web application or API will have a particular type of vulnerability
and the likelihood that it will be subjected to attacks targeting that
vulnerability type in the next month.

DevSecOps is Helping Organizations

Improve at AppSec

DevSecOps is an approach to IT security based on the

principles of DevOps. The goal is to achieve security while
building applications and APIs without disrupting high-
speed software pipelines.

DevSecOps applies to securing the entire stack, not just

your custom code. Of course, because all of these layers
are turning into software, all security is starting to look
like application security. Also, DevSecOps spans the full
software lifecycle, including development and operations.

DZONE TREND REPORT: DEVSECOPS PAGE 8

So really, it’s about both “shifting left” to identify and prevent vulnerabilities as well as “extending right” to monitor and defend
applications against attack.

The amount of work dedicated to security increases dramatically as software release velocity goes from yearly to weekly to many
times a day. So the only way forward is to automate the work of application security. Unfortunately, “automation for experts”
doesn’t help. If experts have to be involved, it won’t scale because there simply aren’t enough experts. The only way to get experts
out of the loop is for application security tools to be accurate in terms of both false negatives (missed vulnerabilities) and false
positives (incorrectly reported vulnerabilities).

Gartner has named DevSecOps one of their fastest-growing areas of interest and predicts that DevSecOps will be embedded into
80 percent of rapid development teams by 2021. Organizations practicing DevSecOps have shown impressive results. These early
adopters are 2.6x more likely to have security testing keep up with frequent application deployments.

Beware of “DevSecOps” Buzzword Overload

Be careful of two “buzzword” problems with the term DevSecOps. The first: Good DevOps involves security, so it seems
redundant, and possibly implies that DevOps is deficient in some way. So when I use the term DevSecOps, I try to make it clear
that I’m referring to the security aspects of the broader DevOps approach.

Even more dangerously, the term DevSecOps has started to lose its meaning from overuse. Anything that can hook into a CI/CD
pipeline or be used by developers is all of a sudden labeled DevSecOps, regardless of whether it actually helps to achieve the
three ways of security. This trend almost guarantees the failure of DevSecOps because everything that already doesn’t work is
being rebranded as a DevSecOps solution.

Shifting Security From “Outside in” to “Inside out”

Many organizations have started to make real progress with DevSecOps automation. Ultimately, the goal of these efforts is to
completely automate the security work required for an application to be cleared for production. Note that these four practices
represent a shift from “outside-in” firewalling and scanning to an “inside-out” approach that continuously monitors from within.

1. Continuous Security Monitoring of Application/API Inventory

The first step in any application security program is automating the discovery, profiling, and continuous monitoring of exactly what
code you’re running across your environments. It’s not hyperbolic to say that you can’t secure what you don’t know. Your portfolio,
and therefore your attack surface, spans production code in a variety of data centers, virtual environments, private clouds, public
clouds, containers, serverless, and more. All of which may be running different versions or branches of the code.

The DevSecOps approach to this problem is to use a combination of automated discovery and self-inventory tools. Discovery

DZONE TREND REPORT: DEVSECOPS PAGE 9

tools help you identify what applications and APIs you have. Self-reporting tools enable your applications to inventory themselves
and report their metadata to a central database. You can write your own self-inventory library or use an instrumentation-based
tool. Either way, from that point forward, your inventory will be up to date forever.

2. Continuous Security Monitoring for Custom Code Vulnerabilities

Another key DevSecOps practice is to continuously monitor all your software for vulnerabilities throughout development, test, and
operations. Most vulnerability discovery and remediation should “shift left” to very early in the software development process. Of
course, some applications aren’t in active development yet need vulnerability discovery too.

Companies like Comcast have shifted to using Interactive Application Security Testing (IAST) as their primary way to empower
developers to fix vulnerabilities themselves and check in clean code. Static and dynamic scanners require significant time
and resources to run, generally several hours or even days, which doesn’t work in a modern CI/CD pipeline. They also require
significant triage effort for every scan. Developers can use IAST without expert support. Because IAST directly measures
vulnerabilities from within your applications, it is significantly more accurate than SAST and DAST scanners. Because the results
are instant, they can be leveraged from within all the typical tools in a modern software pipeline.

3. Continuous Security Monitoring for Open Source Vulnerabilities and License Violations

The use of open source software (OSS) is exploding, and DevOps companies are highly leveraging these powerful libraries. Every
time you add a library, you take on the risk that there is a security vulnerability (or multiple vulnerabilities) lurking in that code.
Since the typical modern application has hundreds of these components and dozens of new vulnerabilities are disclosed every
week, the risk and work both add up quickly. Fortunately, there are many solutions available for continuously monitoring your
applications for library problems. The best will not only track your libraries, report vulnerabilities, and report license violations, but
will also tell you exactly why each library is included and whether it is actually invoked at runtime. Without this knowledge, you will
waste a lot of time updating libraries that can’t be exploited.

4. Continuous Attack Monitoring and Runtime Exploit Prevention

Finally, don’t forget about continuously monitoring and protecting your applications in production. Even the best software projects
and security teams miss vulnerabilities. And even if they were perfect, new library vulnerabilities are frequently discovered and
entire new classes of vulnerability are discovered roughly once a year. You should also simply want to know who is attacking you,
what types of attack vectors they are using, and which systems they are targeting. This threat intelligence will inform your threat
modeling and security architecture process and help you make smart decisions.

The legacy web app firewall (WAF) approach can only use HTTP information to differentiate attacks from legitimate transactions.
With modern application protocols and data formats, this approach is extremely noisy and time consuming. The modern approach
is to use Runtime Application Self-Protection (RASP), which instruments applications, directly measures attacks from the inside,
and prevents exploits from within.

The Future

DevSecOps will continue to revolutionize the practice of security for many years. Achieving a high functioning practice will require
a combination of people, process, technology, and culture. In this article we focused on establishing continuous security telemetry
on your inventory, vulnerabilities, libraries, and attacks. Imagine all of your applications being continuously inventoried, tested,
monitored, and protected in parallel without having a small team of security experts slowing down the process. This approach
to building your DevSecOps platform will help you build a culture of security that is highly scalable, compatible with modern
software, and commensurate with modern threats.

DZONE TREND REPORT: DEVSECOPS PAGE 10

SPONSOR OPINION

The Trail DevOps Blazed:

Security’s Journey Ahead
By Pierre Betouin, CEO and Co-founder at Sqreen

Security today is where operations was 15 years ago. Ops used to be the
TREND PREDICTIONS
bottleneck to software development. However, with the introduction of
▶ Security will follow the trail blazed
DevOps, ops and dev teams are much closer together, and the bottleneck
by operations in DevOps.
has disappeared. Today, every company is increasingly a software company,
▶ The future of security is visibility
but every company — regardless of how big they are or how mature their
and transparency.
DevOps is — struggles to secure their software. The security status quo
▶ Security will not slow down dev
is expensive and complex: secure coding practices, code reviews, securi- ty
cycles in the future.
testing that slows development, periodic vulnerability scans and pentests,
and protections at the network/edge.

Those who have the resources to deploy the status quo still struggle to scale and keep up with engineering — especially as
software teams accelerate their release cycles and deploy apps at internet-scale. In other words, security has not made the leap
forward that operations has, and this is limiting the potential of DevSecOps today.

To achieve real DevSecOps, security needs to follow DevOps’ trail. The silos between security, operations, and developers need
to be broken down, the responsibility for security needs to be infused across the organization, and we need new tools to sup-
port this. That’s why we’re building Sqreen.

Sqreen is the industry’s first provider of Application Security Management (ASM), empowering security, operations, and devel-
opers to succeed in building and running secure applications together, without code changes, reduced engineering velocity,
or added operational burden. Sqreen’s ASM platform provides a central platform for monitoring and protecting applications,
delivering multiple layers of visibility and protection through the use of micro-agents deployed directly inside applications.

Most traditional security tools fail to protect applications from attackers because they rely on easy-to-bypass rules, can’t stop
zero-day attacks, have high false-positive rates, and lack real-time app visibility. By sitting inside the application, Sqreen has
access to the full application context, giving it a deeper understanding of how the application behaves in response to incoming
malicious requests. Multiple protections (RASP, In-App WAF, ATO, and more) can be enabled from a central admin panel.

Sqreen furthers DevSecOps by making it easy for developers to remediate security issues without slowing down the SDLC.
Rather than adding more obstacles to the DevOps process, Sqreen makes it simple to infuse security throughout the SDLC and
bring security, operations, and developer teams closer together.

DZONE TREND REPORT: DEVSECOPS PAGE 11

 2ND EDITION 2ND EDITION 2ND E

The &ub1 The DevOp8 The Earl1

The Node.JS Pentest Best The
Security EngineerM8 SaaS
Practices
Security
Security Handbook Security
Handbook Checklist
checklist Security C
Checklist
First 90 Days
The DevSecOp8
Security Checklist

Getting started
with DevSecOps?
learn how to:
• Develop a security-as-code culture
• °rotect your applicatio¬s ©roª attac¦§
• ¥utoªate security testi¬£
• ¤¸i©t security le©·
• ¥¬d ªore¢

sqreen.com/devsecops
DZONE TREND REPORT: DEVSECOPS PAGE 12
OPINION

Open Source Security

as a Use Case for
DevSecOps Adoption
By Michael Hollander, Product Owner at WhiteSource for Developers

DevSecOps answers the question of how to continuously increase the pace

of deployment without compromising security. TREND PREDICTIONS

DevOps practices and tools helped software development organizations ▶ SCA technologies will split into gov-

shorten development cycles and enabled us to meet the demands of our ernance tools and developer tools,

customers, delivering innovative software products at an increasingly swift integrating into more phases of the

pace. The next piece of the puzzle is integrating security tools throughout the software development lifecycle.

DevOps pipeline to further speed up the process and manage the age-old ▶ These tools will help close the gap
conflict between security and agility. between detection and remediation,
but organizational needs beyond
The DevSecOps approach fuses security into the earliest stages of the SDLC.
those of developers will still exist.
Shifting security testing left helps organizations find and address security is-
sues early when remediation can be relatively quick and easy. However, along
with the many benefits that adopting DevSecOps brings — like allowing teams across the organization to address security issues
without having to delay development — it also presents new challenges. DevSecOps adds security to developers’ already long to-
do lists, often slowing them down or requiring them to work across too many tools and platforms throughout development.

Learning DevSecOps Lessons from Open Source Security

Open source has become the main building block in modern applications. You can no longer develop software at today’s pace
without open source. Since open source usage has become standard practice in software development, I’m going to use the
way companies are adopting Software Composition Analysis (SCA) tools to manage their open source security as a use case for
DevSecOps adoption.

Turning a spotlight on open source security as one specific area of application security and studying how companies are man-
aging their open source security risk can teach us a lot about how developers are handling security throughout the development
lifecycle. To better understand why many organizations are still struggling with open source security even though awareness is
high, we need to look at DevSecOps in open source security with three “WH” questions in mind:

• When are developers implementing DevSecOps in the SDLC?

• How are they doing it?

• Why are they implementing DevSecOps processes and tools, and are they achieving their goal?

DZONE TREND REPORT: DEVSECOPS PAGE 13

When

Shifting Open Source Security Left: The Earlier, the Better

DevSecOps sets out to relieve the stressful, expensive delays that were caused when security testing was performed late in the
game by setting up processes and tools for testing security early and often. As organizations continue to embrace the DevSecOps
approach, testing tools and practices are integrated even further left in the development pipeline.

When we asked developers how they choose an open source component, they listed security as their main concern, showing us
that detecting security issues as early as possible is a high priority for them.

Integrating automated security testing into the build stage is already a fairly common practice in DevSecOps-savvy development
outfits. By now, many organizations have taken their open source security even further left and are detecting open source security
vulnerabilities before the build stage by using SCA tools that integrate with their IDE and repositories.

How

Integrating Open Source Security Into Developers’ Native Environment

Once we tackle the question of when to implement DevSecOps practices and tools, it’s time to look at the process. What we
found is that developers are happy to use SCA tools when they are integrated into their native environments — like their repo or
build tools.

A third of developers are already using automated SCA tools that provide real-time alerts on open source components with known
security vulnerabilities. Most of these tools are free, which is one factor that explains the widespread adoption despite the fact that
some offer limited capabilities and support.

Not surprisingly, GitHub, one of the open source community’s most beloved playgrounds, offers the most popular free SCA tool
that developers are using, followed by the well-respected OWASP’s Dependency Check tool and WhiteSource Bolt. All three of
these tools integrate easily into developers’ native environments, proving once again that developers will happily embrace security
when given the right tools.

Why

The Challenges of Implementing DevSecOps Into Open Source Security

While it’s clear that developers have been adopting DevSecOps practices to better manage vulnerable open source components,
there are still some gaps in the road to adopting DevSecOps.

DZONE TREND REPORT: DEVSECOPS PAGE 14

Most SCA tools were originally designed for traditional security teams but lack the capabilities for supporting developers in
remediating detected vulnerabilities. This results in software development teams being constantly bombarded with security alerts
without the resources to properly handle all security issues. Lacking the proper DevSecOps tools and processes that they require
for remediation, developers might find themselves spending up to as many as 12-36 hours a month addressing remediation.

When it comes to “why,” it appears that most organizations are missing the mark. The goal of implementing DevSecOps into open
source vulnerabilities management is remediation, not just detection. While automatic detection provides development teams with
never-ending lists of alerts, they are not provided the tools to achieve their end goal, which is remediation.

Alert, Report, Prioritize, and Remediate: What’s on The Horizon for DevSecOps
in Open Source Security

Software Composition Analysis (SCA) technologies — originally developed for management, security, and compliance teams
— are evolving to support the DevSecOps revolution, integrating into more phases of the development lifecycle. We’ve already
begun to see the next phase of this evolution, in which SCA solutions will split into two kinds of tools: governance tools and devel-
oper tools.

Governance Tools

Governance solutions will be used by Management, Security, DevOps, and Legal teams to provide them with full visibility and
control over open source issues across the organizations’ software portfolio. They will include automated features like automated
reporting, real-time alerts, and continuous security and compliance policy enforcement.

Developer Tools

To provide further support across the DevSecOps pipeline, another category of SCA tools will continue to emerge: SCA develop-
er tools. This new generation of SCA tools will provide developers with the information that they need to help them avoid using
vulnerable open source components or fix the ones detected in their code. Developer tools integrate with native development
environments and DevOps tools and provide alerts during early stages of selection and usage of open source components.

We expect increasing popularity for these tools since they move beyond detection, also providing actionable insights and auto-
mated fix pull requests to help developers easily remediate vulnerabilities. However, these tools are unable to enforce policies
throughout the development lifecycle, generate custom reports, or provide cross-organization visibility like the SCA governance
tools do.

Next Steps for DevSecOps Organizations

Each of these SCA types has its benefits and drawbacks. While the next generation of developer tools for open source vulnerabili-
ties management will finally close the gap that currently exists between detection and remediation, there will still be organizational
needs beyond those of the developers.

This provides the DevSecOps organizations of tomorrow an array of automated solutions to choose from. This also requires them
to closely study the current state of their development lifecycle and assess which processes and teams need a boost.

To formulate a DevSecOps plan, organizations must decide which automated security tools best suit their needs and processes.
Combining these tools will help implement security throughout the SDLC and make the road from detection to prioritization to
remediation of open source vulnerabilities is as quick and easy as possible for all teams involved.

DZONE TREND REPORT: DEVSECOPS PAGE 15

OPINION

Successful DevSecOps
Teams Proactively
Automate Responsibility
By Chase Doelling, Director of Strategic Alliances at JumpCloud

As every company becomes a software company, every development and operations team becomes a security team. This is
especially true for development teams working on SaaS applications whose value, by nature, is to be exposed through someone
else’s servers. Yet, combining security and DevOps seems to slow everything down. Operations begins to feel “more enterprise”
and constricting, especially for organizations that prize agility.

Historically, these were seen as somewhat contradictory goals because time spent securing was time not spent shipping. New
features released was the yardstick for how many customers measured value in an emerging SaaS business. Yet the yardstick
has moved. As cloud services became more commonplace with more infrastructure, personal data, and trust moving with it, the
more valuable a target it has become. The value of your organization or individual application, therefore, is now measured first by
your security, then your core value proposition. So how can you create a security-first mindset that pleases DevOps teams? By
Proactively Automating Your Responsibility, getting your organization up to PAR.

Be Proactive About Security

As team structures changed, with roles blurring and responsibilities merging to create DevOps, security can no longer be left to
last-minute requests like, “Hey, is this good? We’re ready to deploy, so whenever you can check the new library that would be
great...thanks!” Increased collaboration and the shortened development cycle continuous delivery brings means that you need to
start secure to stay secure. Otherwise, the cost of delays caused by re-securing features, fixing bugs, updating library versions,
and so on, slows down the delivery lifecycle in the long run.

These long-term costs are visible to the organization but can be hard to see at the individual level. This is often due to a mismatch
of perceived incentives at a personal level — What’s in it for me, right now, in this sprint?

Continuous testing is a useful forcing function for how proactive teams can be in addressing security upfront as code is being
committed. Organizations are working less with large static code structures that need to be tested. Instead, testing must be part of
the build before you even check it into the repo.

As soon as new employees start, take a proactive approach and hold a day-zero security training. When employees pick up their
laptop and find out which cabinet holds the coffee filters, they should also know to what email alias to forward phishing attempts.
Taking the extra steps to explain why you should hover over a link to read the full URL, why writing the Wi-Fi password on the
whiteboard should be avoided, and what it means to trust but verify, sets expectations early. Each of these conversations creates

DZONE TREND REPORT: DEVSECOPS PAGE 16

a security-first posture that influences future decision making. Proactivity is also guided by what feedback loops the organization
adopts. If teams can see that being proactive makes it robust and auditable, it also becomes repeatable.

Automate to Scale Security and Sanity

The ability to automate security best practices on your DevOps teams is the fastest way to adopt a DevSecOps approach.
Automation projects are commonplace in existing DevOps teams as a key pillar to bringing groups closer together while
accelerating velocity. While this may seem obvious for experienced teams, it bears repeating as inserting security practices at this
level is the most impactful. Over time, teams will be able to create a filter to determine what policies can be automated to reduce
the surface area of attack and what should be controlled amongst individuals to reduce critical events. Put another way, what is
static and what is dynamic? And can you automate the former to free up time to think critically about the latter?

Reducing surface area reinforces a proactive DevSecOps approach and also helps the organization as a whole. If you know
there are vulnerabilities in a recent browser version, encourage upgrades. If people are becoming lazy about password resets,
encourage longer passphrases. This is the heart of grassroots security that creates a better posture amongst teams, so automate
as much as you can.

To help teams develop this ability, try to start small.

Automation has a compounding effect that will begin
The lack of ownership is
to pay interest over the long term. By focusing on the
what leads to security being
frictionless wins first, teams get used to the idea of
implementing continuous, long-term changes alongside treated separately, and
near-term operational work. Small wins also prevent
process fatigue. Motivations to take on the next project worse, as an afterthought.
are based on the outcome before it.

When you have automated these things, you can focus on the hardest part — reducing critical events. A majority of critical events,
which we will classify as company and career-ending, can be avoided by removing the human element, adding a multi-factoring
authorization to as many processes as you can, and encrypting the rest. While some teams won’t embrace your plan to have
biometric scanning to push to production yet, Time-based One-Time Passwords (TOTP) or push access like DUO are small lifts.
To provide coverage for everything else, default to encryption. Leverage tools like Keybase for passing sensitive keys, hashing and
salting anything that shouldn’t be clear text, and getting off of anything below TLS 1.2.

Removing the human element while still keeping the humans (phew!), you can now focus on what humans are good at, creativity
and resourcefulness. Do we need another failover? When was the last time we had that pentest? What processes can we
implement now to allow us to get coverage for multiple compliance certifications? And finally, what do we already have in place
right now that we can show to customers to continue building trust? All of these things and more create a higher level of strategy
and creativity that we tend to be rather good at.

Responsibility-Driven Security

Are you a responsible person? Why yes, of course! You’ve gotten this far in your career, and you’re reading this article. The
type of responsibility I’m talking about, though, looks through the lens of ownership. Security without responsibility is where
ownership fades.

Ownership can take many different forms and vary in levels of intent. As you transition from task to task, you also transition
from different levels of ownership around those tasks. In some meetings, you’ll check your phone when the conversation is
declining, and 15 minutes later, you’re watching like a hawk for agreement in the room to get to some consensus on your project.
The ability to enhance personal ownership around security is crucial in integrating security into DevOps teams, blending those
roles to achieve the DevSecOps state. The lack of ownership is what leads to security being treated separately, and worse, as an

DZONE TREND REPORT: DEVSECOPS PAGE 17

afterthought. The moment you feel like it’s not your responsibility, you don’t own the outcome fully and will defer when questioned.

The ability to hire a security-forward, full-stack team member who is trained in the deadly arts of filleting phishing attacks,
mutilating malware, and bludgeoning brute force attacks on every development team might be out of reach. Your goal should then
be to set up a shared matrix of ownership in and amongst teams. Within each team, anoint a (insert hipster adjective) Deputy who
can take the lead and coordinate with the existing security team. Create a threat model at the team level, with the team owning
it and the security team supporting it. In this way, responsibility becomes a reinforcing teacher for new team members. This
supporting structure still makes sure that product teams are not building security practices and security teams are not building
the product, but that ownership is maintained throughout.

DZONE TREND REPORT: DEVSECOPS PAGE 18

 Diving Deeper
Into DevSecOps
Books Zones
Hands-On Security in DevOps by Tony DevOps DevOps is a cultural movement, supported
Hsu — Learn more about integrating security throughout by exciting new tools, that is aimed at encouraging close
the entire development lifecycle, protecting cloud cooperation within cross-disciplinary teams of devel-
services, and adopting infrastructure solutions. opers and IT operations. The DevOps Zone is your hot
spot for news and resources about continuous delivery,
Puppet, Chef, Jenkins, and much more.
TheDevOps Handbook: How
to Create World-Class Agility, Security The goal of the Zone is to help prepare
Reliability, and Security in the people who make and support those applications
Technology Organizations by Gene Kim, stay up to date on industry best practices, remain aware
et al. — Learn how to integrate Agile and continuous of new and omnipresent threats, and help them to think
delivery three different ways to ensure security across “security-first.”
development and success in the marketplace.
Cloud The Cloud Zone covers the host of providers and
utilities that make cloud computing possible and push the
Securing DevOps: Security in the limits (and savings) with which we can deploy, store, and
Cloud by Julien Vehent — Implement DevOps host applications in a flexible, elastic manner. The Cloud
and security best practices in this hands-on guide to Zone focuses on PaaS, infrastructures, security, scalability,
securing cloud services. and hosting servers.

Refcards Podcasts
Compliant DevOps With new data protection laws and consumers The DevSecOps Podcast Series
more aware than ever before of how their privacy is being compromised, Listen to discussions with thought leaders and industry
companies are now required to adopt a compliant DevOps approach. Download experts on automating security throughout each phase
this Refcard to discover best practices for adopting compliant DevOps. of the SDLC.

DevSecOps DevSecOps helps you reach higher security standards while Absolute AppSec Learn more about
following DevOps principles. This Refcard shows you how to get started with implementing security and industry best practices in
DevSecOps with key themes, crucial steps to begin your journey, and a guide to these informal, open conversations about AppSec.
choosing security tools and technologies to build your DevSecOps pipeline.
Continuous Discussions (#c9d9)
Shifting Left With Continuous Delivery Shifting left Explore all things DevOps. Each episode features a
will help you raise the quality of your software projects and improve time to different component of DevOps, covering topics relating
market drastically. This Refcard explains how shifting left with CD makes software to security, automation, continuous delivery, and more.
development faster and more reliable, why whole teams must cooperate in effective
left shifts, and how containers are important in shifting left with continuous delivery.

DZONE TREND REPORT: DEVSECOPS PAGE 19

ORIGINAL RESEARCH

Executive Insights
on DevSecOps
By the Editorial Team, DZone

To understand the current and future state of DevSecOps, we

gathered insights from 29 IT professionals in 27 companies. TAKEAWAYS

Respondents ▶ The most important elements of a successful

DevSecOps implementation are automation,
• Anne Baker, V.P. of Product Management and Marketing, Adaptiva shifting left, and collaboration.
• Steven Aiello, Solutions Principal, AHEAD ▶ A successful DevSecOps culture has security
• Gadi Naor, Co-founder and CTO, Alcide ingrained throughout the organization,
greater collaboration, and metrics used to
• Mike Stahnke, VP of Platform, CircleCI
determine progress.
• Brian Nash, Director of Product Marketing, and Brian Dawson,
▶ Embracing DevSecOps maintains innovation
DevOps Evangelist, CloudBees
velocity that translates to business goals
• Michael Rose, Vice President of Engineering, Cybera
without skimping on security.
• Doug Dooley, COO, Data Theorem

• OJ Ngo, CTO and Co-Founder, DH2i

• Kris Lahiri, Co-founder, Egnyte

• Brian Platz, Co-founder and Co-chairman, Fluree

• Javed Shah, Director of Product Management for Cloud and DevOps, ForgeRock

• Malcolm Isaacs, Senior Solutions Manager, Application Delivery Management, Micro Focus

• Gary Duan, CTO, NeuVector

• Yogesh Badwe, Director of Information Security, Okta

• Franklin Mosley, Senior Application Security Engineer/Evangelist, PagerDuty

• David Strauss, CTO and Co-founder, Pantheon

• Jeff Keyes, CMO, Plutora

• Vishnu Nallani, VP & Head of Innovation, Qentelli

• Sheng Liang, Co-founder and CEO, and Shannon Williams, Co-founder and VP Sales & Marketing, Rancher Labs

DZONE TREND REPORT: DEVSECOPS PAGE 20

• Gene Yoo, CEO, Resecurity

• Altaz Valani, Research Director, SecurityCompass

• Jim Hansen, V.P. Products, SolarWinds

• Colby Dyess, Director of Cloud Marketing, Tufin

• Tim Hinrichs, CTO and co-founder, Styra

• Joseph Feiman, CSO, WhiteHat Security

• Andrei Bezdedeanu, VP of Engineering, ZeroNorth

• Tim Reilly, COO and CFO, Zettaset

What Respondents Told Us

The most important elements of a successful DevSecOps implementation are automation, shifting left, and collaboration.
Eliminate as many manual steps as possible so security becomes a first-class citizen of DevOps workflows. The goal is to embed
security early on into every phase of the of the development and deployment lifecycle. By designing a strategy with automation in
mind, security is no longer an afterthought. This ensures security is ingrained at the speed and agility of DevOps without closing
business outcomes.

Shift security left in the engineering lifecycle. Security should be imbibed as a design mentality instead of being an afterthought.
If you don’t make DevSecOps part of the lifecycle from the planning, design, code, and rollout perspective, you will miss
opportunities to expose vulnerabilities that could expose business to risk.

A successful DevSecOps implementation starts with

strong alignment between development and security
teams. Engage the security side throughout the value
Security should be imbibed as
stream. Have more collaboration with shared goals
around security. While each team has their own unique
a design mentality instead of
needs and constraints, collaborating enables the
groups to leverage their respective strengths to achieve
being an afterthought.
business goals.

The attributes of a successful DevSecOps culture are how security becomes ingrained throughout the organization, greater
collaboration, and the use of metrics to determine progress. Everyone becomes concerned about security and sees security as
their own responsibility, not someone else’s problem. There is proactive security across every team. InfoSec is embedded with
data security and good processes for the architect and development team to develop good code.

There is a focus on partnership rather than blame. Everyone from executives to project teams is on the same page regarding the
importance of security. There is a trust and shared responsibility of security outcomes with a culture of visibility and transparency
so everyone involved can learn what works and what doesn’t.

There are clear security-driven metrics. Security is measured at each stage of the engineering lifecycle. The culture is governed by
shared security KPIs and by bringing in the right people.

DevSecOps solves problems around velocity, risk, security consciousness, and software quality. Embracing DevSecOps maintains
innovation velocity that translates to business goals without skimping on security. It helps ensure that security is integrated into
the fast-moving environment. With security integrated into developer workflows, there are faster, more secure releases without
stifling developer innovation. It accelerates bringing secure applications to market, while significantly reducing response time to
increasing threats.

DZONE TREND REPORT: DEVSECOPS PAGE 21

Risk is reduced by designing with security baked in from the beginning. Databases with a foundation of security are inherently
less risky. Vulnerabilities will be detected earlier, making them easier to fix and reducing the chance of vulnerabilities escaping into
production, exposing the organization and its clients to risk.

DevSecOps ensures security is a norm and not an afterthought. Security becomes part of the ongoing engineering process,
resulting in better software that’s easy to operate and provides a better user and customer experience (CX).

Compliance is one of the more frequent use cases for DevSecOps. DevSecOps helps teams comply with security standards
and auditing systems — anywhere an audit trail is needed for information. It makes it easier to meet the standards for security
assessments, system authorization, and implementation of cloud services for departments across the federal government.
Customers are applying security/operational/compliance policies to the Kubernetes desired-state model.

The most common DevSecOps fails are related to culture, collaboration, and adoption/change. Changing the culture and
mindset is not easy. The executive team needs to create a built-in security culture, realizing that lack of security is a predictor of
business failure. The security team must move past being the department of “no” by embracing DevOps, adding value without
adding friction.

Lack of collaboration is one of the biggest impediments to DevSecOps. There are cultural and organizational barriers to
collaboration between security, development, and operations that must be overcome to build a continuous security mindset.
Finger pointing and a lack of enthusiasm for common goals of the team are generally early warning signs that the DevSecOps
initiative is not going well.

There needs to be a mindset change throughout the

organization. If not, policies around security are instituted Lack of collaboration is one
of the biggest impediments
but viewed as a burden. If the policies are not part of the
core way the operation runs, people will take shortcuts. Be
open to new ways of doing things. Institutionalize security
as part of the process.
to DevSecOps.
Concerns around the current state of DevSecOps are the
culture and the term itself. There is little discussion about collaboration, shared ownership, KPIs for governance, and the cultural
change necessary for successful DevSecOps. More discussion will lead to more mutual understanding, collaboration, and change.

The fact that there’s a name for DevOps plus security shows that security is still an outsider to DevOps. We need to reach a point
where developers truly accept that security can’t be separated from their work and where security professionals accept that they
must be part of the solution.

A failure of leadership is often the root cause of the issue. Many organizations still have not embedded security throughout
their deployment pipelines. The space is still very immature with a small percentage of teams having implemented DevSecOps.
Automated security is only being performed by a select group (5%) of advanced companies.

The future of DevSecOps is having greater adoption, security integrated into the enterprise and the culture, and AI/ML used to
automate and improve the security posture of the enterprise. We’ll see DevOps shift to become DevSecOps. Business leaders will
come to view DevSecOps as a fundamental requirement to operate in the digital world. Successful implementations will detect
and address security threats at greater speed and with less human intervention. Security will become an implicit element
in DevOps.

Security will gain more influence as it is integrated with product teams. Metrics will drive effectiveness and efficiency. Security and
compliance controls will be embedded earlier in the DevOps lifecycle. Security will create less friction and serve as a catalyst for
innovation in existing security tools.

DZONE TREND REPORT: DEVSECOPS PAGE 2 2

Automation will be key to success. AI-driven applications with machine learning will improve DevOps. AI/ML will indicate where
to focus time for vulnerability management. AI-based solutions will predict and identify patterns to unearth security vulnerabilities
before hackers find them.

With regards to DevSecOps, developers need to consider their productivity, the OWASP Top 10, education, processes, and best
practices. An established DevSecOps methodology and culture means less work for developers. A DevOps team working with
security spends 50% less time going back to remediate security issues. Developers trained in cybersecurity are rare, therefore
more valuable. Incorporating security throughout development and deployment is less disruptive and yields better results than
ignoring security until the end.

Start with OWASP to learn security best practices. Understand how your code can be vulnerable. Learn how to defend against
attackers. Check out e-learning resources and read. Secure coding is not taught in any university. Developers should be proactive
in learning how to code securely. It may be uncompensated time to understand SQL injection, code injection, and the OWASP Top
10, but it will save a lot of time and make you more money over the course of your career.

Follow a process and embrace it. Take security seriously for your own development as a professional. Keeping a good mind about
security goes hand in hand with other development best practices. Developers should play a role in ensuring their enterprise’s
security solution adapts to changes in the application it protects.

DZONE TREND REPORT: DEVSECOPS PAGE 23

 INTRODUCING THE

DevOps Zone
DevOps encourages close collaboration within cross-functional teams of developers,
IT operations, and system admins. Dive into the latest DevOps news and resources to
learn how this movement is changing the way modern software is made.

Keep a pulse on the industry with topics such as:

• Continuous integration & continuous delivery • Software testing

• Best practices for implementing culture shifts • Automation across the SDLC

Visit the Zone

TUTORIALS CASE STUDIES BEST PRACTICES CODE SNIPPETS

DZONE TREND REPORT: SCALING DEVOPS PAGE 29