267 BROUGHT TO YOU IN PARTNERSHIP WITH

Introduction to CONTENTS

•  What Is DevSecOps?

•  Key DevSecOps Themes

DevSecOps •  Getting Started With DevSecOps

•  DevSecOps Core Practices

•  DevSecOps Additional Practices

•  What’s Next for DevSecOps?

•  References

ALIREZA CHEGINI
SENIOR DEVOPS ENGINEER, AZURE SPECIALIST AT S-RM

Today, most companies have implemented DevOps practices within their “security as code” culture that encourages security to be treated like
organization. DevOps provides a culture where teams can deliver reliable other software components of the SDLC pipeline.
software and updates faster. This approach presents an opportunity
Figure 1
for teams to focus on quality rather than wasting time on operations.
However, as a result, security practices are often left to security specialists
at the end of the delivery pipeline. A specialized security approach then
creates unnecessary overhead within the delivery process as unexpected
issues frequently arise at the end of delivery. Consequently, teams lose
time fixing the code and starting the same process repeatedly, ultimately
making delivery costly and inefficient.

DevSecOps has become increasingly important as most companies

have embarked on digital transformation. With these plans, companies
are moving to the cloud. This results in moving away from on-premises
infrastructures and transitioning to public cloud solutions. Cloud
providers offer cost-effective, scalable, highly available, and reliable
solutions. However, these advantages come with new security
challenges.

Security deserves a higher priority than ever before. With cloud

solutions, there is no room for mistakes. By not following security
requirements, you might open the door of your network to dozens of
security threats. Therefore, security should be considered earlier during
the design phase. Developers are more successful with this approach
because they first create a secure environment before developing their
features. Additionally, developers are more involved and aware of
security requirements since it is now part of development.

DevSecOps integrates security into DevOps as an integral component

of the SDLC instead of observing security as an afterthought. It
also distributes security responsibilities amongst team members.
In collaboration with security specialists, teams can implement a

REFCARD | FEBRUARY 2022 1

A faster, better way to secure
applications and infrastructure
Reduce cost and complexity with
infrastructure as code security
Unify security standards throughout the
development lifecycle with codified protection

Unleash the power of collaboration

Embed security into developer workflows to streamline
remediations and secure cloud infrastructure before deployment.

Shift-left to minimize risk and boost ROI

Improve efficiency and productivity by reducing time spent
addressing issues and configuring policies.

Automate patching and remediation at scale

Mitigate misconfigurations and reduce alerts by leveraging
automation across the entire development lifecycle.

FREE TRIAL

WHAT IS DEVSECOPS?
DevSecOps is the full stack: DevSecOps spans the entire IT stack
and includes network, host, container, server, cloud, mobile, and
application security. All of these layers are increasingly turning
into software, which makes application security a critical focus for
DevSecOps. DevSecOps spans the entire software development
lifecycle, including development and operations. In development,
security focuses on identifying and preventing vulnerabilities, while
in operations, monitoring and defending against attacks are the main
objectives.
Can teams apply DevSecOps practices and tools to non-DevOps
projects? Absolutely. The ideas in this Refcard apply to almost any
software project. If the goal is to produce highly secure software in the
most cost-effective way possible, DevSecOps is the path forward.
Organizations practicing DevSecOps have shown impressive results.
According to Gartner, these early adopters are 2.6x more likely to have
security testing keep up with frequent application updates and show a
2x reduction in time to fix vulnerabilities.
Understanding the different types of security work and their value to the
organization is critical to successful DevSecOps initiatives. Until teams
truly understand the work, it will be difficult to deliver it effectively. To
learn more about this topic and DevOps in general, read books like The
Phoenix Project and The DevOps Handbook.
KEY DEVSECOPS THEMES
Every DevSecOps program is a little bit different. It is best to view
DevSecOps as a journey. As organizations progress, they may find
that different teams are at different points down the path. The themes
below are not specific activities. Instead, they are guideposts to help
make decisions along the journey.
Table 1
DEVSECOPS GUIDEPOSTS
THEME DESCRIPTION
Empowering Development and operations are empowered
engineering to deliver secure applications into production
teams themselves. Security experts provide support as
coaches and tool smiths but do not have primary
responsibility for security. Ensure that tools
and processes are designed for developers and
operations, not security experts. This way, teams
can share expertise amongst all members of a team.
Making security In many organizations, security work is hidden,
visible unknown, and untracked. In the end, the value
of security is often not easy to understand. In
DevSecOps, we make small security tasks that can
be tracked, tasked, and measured like any other
type of work. Additionally, security becomes part of
day-to-day responsibilities, allowing security to be
transparent to everyone.
REFCARD | FEBRUARY 2022
REFCARD | INTRODUCTION TO DEVSECOPS
DEVSECOPS GUIDEPOSTS
THEME DESCRIPTION
Shift left From developers to DevOps engineers, everyone is
involved in security. Shifting security “left” means
that security activities start during development
and extend throughout the SDLC, with continuous
feedback at every stage from development to
production. See “DevSecOps Additional Practices”
below for more examples.
Security as Code Like continuous integration and continuous
deployment, continuous security means that
teams respond to continuous threats with security
activities that are performed continuously, as part
of the development and operations process, and
integrated into the tools team members are already
using. Security as code is the key to automating
security operations, which leads to an end-to-end
process for security practices.
Integrate As a result of the shift-left approach, security is
security into CI/ considered right away from the development stage.
CD workflows CI/CD workflow is not only for building and deploying
the application anymore. Security is the new part of
this workflow in which every line of code is scanned
and verified against vulnerabilities. New tools make
this relatively easy for developers. These tools
identify the security issues and immediately provide
actionable solutions to fix the issues. Besides
security scanning, there are various methods to
conduct security testing. These are discussed later
in the “Creating Your DevSecOps Pipeline” section.
Continuous Security activities are performed continuously as
security part of the development and operations process and
integrated into the tools team members are already
using to address continuous threats.
Continuous When development is complete, monitoring begins;
monitoring we need to constantly track the behavior of our
applications to detect anomalies and possible
attacks. Continuous monitoring shows insight into
the application’s security and provides feedback for
the development team.
Prevent and No team will ever produce perfect code. Nor will
protect they ever detect or stop all attackers. Therefore, the
best security strategies involve balancing secure
coding during development (DevSec) and runtime
protection during operations (SecOps).
Cloud security Despite the numerous benefits introduced by cloud
solutions, there is still a big challenge from a security
standpoint. On the cloud, developers can create
resources in a couple of minutes and connect to the
public cloud. From a DevOps standpoint, this is quite
interesting since most organizations need to protect
customer data and/or avoid a security breach.
At the same time, organizations want to utilize the
benefits of cloud solutions. Here, a DevSecOps
approach becomes mandatory, and most security
decisions should be made during the design phase.
It is also easier to provide isolated environments
for developers on the cloud to try out new features
without compromising any customer data.
3 BROUGHT TO YOU IN PARTNERSHIP WITH

THREE MISTAKES TO AVOID IN ENTERPRISE
ORGANIZATIONS
Before jumping into core practices, let’s address common problems
seen in most enterprise organizations:
Table 2
MOST COMMON SECURITY CHALLENGES
CHALLENGE DESCRIPTION
Security in a silo Today, most companies have adopted Agile and
DevOps. However, it is still common for many of them
to keep security out of these processes and security
as a separate entity that specialized people can only
manage.
On the one hand, this situation creates a silo around
security and prevents engineers from understanding
the necessity of security or applying security
measures from the beginning. Siloed security results
in an inefficient workflow for software development.
The best practice is to share these responsibilities
across all team members instead of having a
specialized security engineer.
Unbalanced Sometimes security becomes the priority, and
security then the organization loses creativity and quality
performance as a price for security. Financial
institutions are an excellent example of where
security is often unbalanced. Security has the highest
priority over any other software development
project in these scenarios. While this approach
is not wrong, the focus on security can lead to a
detrimental imbalance. As a result, other factors
such as performance and quality are neglected.
The focus and resource capacity are primarily spent
making sure everything is secure. Consider both
security and other essential application components
during the design stage to treat security as a regular
aspect of the application. Then developers can
focus on development while feeling confident about
security instead of security departments delaying
development due to a lack of security considerations.
Lack of Security obsession in some organizations leads to
playground for a strict environment with no room for creativity.
developers With security as the most critical factor, there is no
playground environment; every new experiment or
piece of software must go through a complicated
process and verification against security
compliances before being used by developers.
This prevents developers from having the space to
try out new things. Therefore, DevOps teams cannot
do their job properly, which delays and negatively
impacts the entire SDLC. DevSecOps aims to keep
things secure so that everyone can do their job at
their pace. Developers are the source of creativity
in the software development workflow. This means
that the more freedom they get, the more value they
might deliver. Part of a developer's job is to try new
things out, break things, and learn from failure.
TABLE CONTINUES IN NEXT COLUMN
REFCARD | FEBRUARY 2022
REFCARD | INTRODUCTION TO DEVSECOPS
MOST COMMON SECURITY CHALLENGES
CHALLENGE DESCRIPTION
Lack of Sometimes developers need environments to test
playground for new software without common security limitations.
developers These environments are known as a "SandBox,"
(cont'd) which are temporarily isolated environments.
It is common that these environments have no
connection to any internal network and have no
customer data. This way, engineers can easily
try new futures without being worried about not
following common security compliances.
THE “THREE WAYS” OF SECURITY
For decades, both software and security have struggled with poor
quality results, cost overruns, and processes that require experts.
While DevOps has shown promise on the software side, security is
still practiced in very traditional ways. DevSecOps is not just shoving
traditional security practices and tools into DevOps.
Instead, we must rethink the security work. We will need new practices
and technologies to perform this work. We can give this transformation
structure using the “Three Ways” from The Phoenix Project. By framing
the problem this way, we can see that we need to get security work
flowing, ensure instant security feedback, and create a security culture.
Table 3
THE “THREE WAYS” OF SECURITY
APPROACH DESCRIPTION
Get your Most security work is monolithic and attempts to
security work cover all risks in a single task, like a complete security
flowing architecture or security scan. How do we get security
work flowing?
•  Make the work visible.
•  Work a single security challenge at a time.
•  Limit work in process.
•  Reduce handoffs.
•  Automate everything.
Ensure instant Security is one of the most common causes of
security technical debt, and the cost of this work increases
feedback dramatically the farther it progresses across the
SDLC. Several reasons include lack of knowledge and
limited security specialists.
•  How do we keep security work on track?
•  Increase awareness about the importance of
security.
•  Identify potential problems.
•  Make problems instantly visible.
•  Swarm on the problem.
•  Seek the cause.
•  Ensure security “findings” are designed for
easy consumption.
•  Focus on providing a solution rather than
exaggerating the problem.
TABLE CONTINUES ON NEXT PAGE
4 BROUGHT TO YOU IN PARTNERSHIP WITH
 REFCARD | INTRODUCTION TO DEVSECOPS

THE “THREE WAYS” OF SECURITY augmentations are designed to fit naturally into the process: no extra
steps, no gates, no delays. Instead, teams cycle quickly on small
APPROACH DESCRIPTION
security tasks that are structured to be delivered by the development
Encourage a Many organizations have a security culture of blind and operations teams using the tools they already use. Let’s explore
security culture trust, blame, and hiding that prevents developers
these core practices in detail a bit later.
and operations from working with security. How do
we create a culture of security?
“HELLO, WORLD!” A FIRST STEP TOWARDS
•  Empower everyone to challenge security
DEVSECOPS
design and implementation.
•  Take every opportunity to make security Let’s use a straightforward example to demonstrate. Imagine that we
threats, policies, architecture, and have a web application being built by a DevOps project. All we know is
vulnerabilities visible. that the application didn’t do well on a recent security scan. There is no
•  Allow everyone on the team to participate in threat model or security architecture. How should we get started with
security.
DevSecOps?
•  Trust that engineering teams want to do the
right thing. 1. Analyze: Identify the next most critical security challenge
•  Celebrate the knowledge gleaned from
2. Security: Implement a defense strategy
security issues rather than blaming those
involved. 3. Verify: Automate security testing
•  Spend more effort on upgrading practices
4. Monitor and Defend: Detect attacks and prevent exploits
and preventive measures than vulnerability
remediation and incident response. 5. Documentation
•  Plan trainings and conduct workshops to
maintain continuous security throughout all 1. ANALYZE
teams.
Do not secure everything at once. The most critical scan findings
indicated that this application has obvious SQL injection problems. The
By following these three ways, teams will see security as a concrete
goal is to make tangible progress quickly, so it is best to deal with this
output from the development process. It is a combination of security
first. First, build defenses and assurance over time in small pieces, not
features and assurance, captured in a tangible way. By applying DevOps
all at once. Create a JIRA ticket to address the SQL injection.
concepts, we can produce this concrete security continuously and
effectively as a part of standard software development. 2. SECURE
Next, look at the SQL injections to determine which parts of the
GETTING STARTED WITH DEVSECOPS
application are vulnerable. Once that is complete, we need to build
Traditionally, security has been performed as a series of massive
our defense. The best strategy to prevent a SQL injection is to use
tasks spanning all risks. For example, security consisted of writing
input validation and parameterized queries everywhere across the
comprehensive security requirements, designing a broad security
codebase. It may be beneficial to break this task up into even smaller
architecture, performing a thorough security test, etc. But agility
pieces. So fill out the details of the defense strategy via ticket(s) and
requires a risk-based approach. To accomplish security work in a
start implementing them.
DevOps organization, we can prioritize our security tasks and break
them into small pieces for implementation. 3. VERIFY
Use simple tools to ensure that non-parameterized queries are
Figure 2
eliminated from the codebase. A deployed tool can be used to warn
developers in their IDE if they violate this rule. It is also important to
automatically re-verify during CI/CD as well as perform a final check
prior to deployment.

4. MONITOR AND DEFEND

Finally, be aware of any attackers that target with SQL injection
attacks. For visibility and protection in production, implement runtime
application self-protection (RASP). This application then monitors
requests and detects possible attacks.

This diagram shows how security fits into the normal DevOps
development cycle at a very high level. Notice that these security

REFCARD | FEBRUARY 2022 5 BROUGHT TO YOU IN PARTNERSHIP WITH

 REFCARD | INTRODUCTION TO DEVSECOPS

5. DOCUMENTATION
Now that these critical security steps are complete, it is time to document
everything. Document this process from design to completion to ensure
each task is visible to the rest of the team. Documentation provides
insight into what has worked and what has not worked to come up with
potential improvements.
Once each step is complete, it is time to start in on the next security
breach or challenge. Each time we complete a challenge, we leave
behind infrastructure to make sure it remains secure. Note that we don’t
want to create a fragmented set of individual defenses, so it’s important
to make good decisions over time about security architecture.
In DevSecOps, don’t let perfect be the enemy of good. We’re looking
to improve our security story on every iteration. Your first attempt
might be a partial solution with sampling instead of a rigorous defense
and complete testing. The goal is to get this cycle running and make
measurable progress over time. Again, do not forget to create a
documentation for each implementation to ensure we set a standard
baseline for future applications.
checking the code inside the application. This method is also
known as black-box testing, which can detect vulnerabilities like
SQL injections and cross-site scripting.
•  Static Application Security Testing (SAST): Unlike DAST,
SAST focuses on the code. So the security vulnerabilities can
be found earlier in the development stage without running the
code. Tools like Synk can be integrated into the pipeline to scan
application codes constantly. This approach is quite efficient
and saves time and money for teams.
•  Container Scanning: Containers are great solutions, but they
can become a black box for security. So it is crucial to constantly
scan container images for vulnerabilities, malware, and other
security measures to ensure nothing is left out of the radar.
Figure 3

CREATING YOUR DEVSECOPS PIPELINE

Let’s assume that you have implemented a CI/CD pipeline in your
current DevOps practices. This pipeline includes all required steps to
bring a piece of code from development to production. We need to
integrate security into this pipeline as a part of the application delivery.
Although implementing a separate pipeline for DevSecOps sounds
interesting, this is not an efficient approach and creates overhead for
teams. Additionally, DevSecOps aims to incorporate security earlier in
your current CI/CD pipeline. The main cycle in the DevSecOps pipeline involves security tools, an
analytics hub, and integrations with development and operations tools.
In each phase of the pipeline, there must be some tasks dedicated
The security tools at the bottom of the diagram identify vulnerabilities
to security. Implementing DevSecOps within your pipeline requires
in applications and APIs across development, test, and production
adopting tools and processes that continuously perform security as
environments. In production, other tools monitor and prevent attacks.
code is written, integrated, tested, deployed, and operated. While
The telemetry from these tools feeds into an analytics system for
there’s just one delivery pipeline, having a security “view” of your
historical tracking, analysis, and notifications.
pipeline may help you understand the security value stream separately,
revealing bottlenecks and inspiring confidence in the results. There Common events include:
are a lot of different components you can add to your pipeline. Many
•  Custom code vulnerabilities
security tools can help to implement:
•  Known vulnerabilities in libraries and frameworks
•  Unit Testing: This is the first opportunity to test any piece
of code against its functionality, and therefore, it is the best •  Attacks on custom code vulnerabilities

moment to check if a small part of the software can operate as •  Attacks on libraries and frameworks
expected.
•  Application inventory, including all libraries and frameworks
•  Dependency Scanning: Every project uses various libraries,
•  Software architecture details
and sometimes external libraries are used in the project.
With dependency scanning, those libraries are scanned for In general, DevSecOps favors the use of notifications (real-time integra-
vulnerabilities to ensure the libraries are safe to use. tions into normal development and operations tools) over PDF reports.
However, for some purposes, such as compliance, PDF reports may be
•  Dynamic Application Security Testing (DAST): DAST is how
generated. Notification alert team members need to know about secu-
you can test your applications for vulnerabilities without

REFCARD | FEBRUARY 2022 6 BROUGHT TO YOU IN PARTNERSHIP WITH


rity events immediately through the tools they are already using as part
of their everyday job. While a single analytics system would be ideal,
today, you may need separate systems for vulnerabilities and threat
events.
Table 4
ESSENTIAL DEVSECOPS SYSTEMS
SYSTEM DESCRIPTION
Smart alerting It is vital to design a smart alerting system when it
comes to monitoring — regardless of security or
other goals. The term “smart” here means that our
monitoring platform should raise an alert whenever
an action needs to be performed. This requires
the alerts to be designed and fine-tuned so that
we avoid being spammed with any unimportant
alerts. One example is getting an alert for a service
that is slower than usual but not slow enough to
make a considerable impact on the whole system.
This incident is considered low severity and should
be investigated later, but it should not interrupt
workflows.
Intelligent Use a platform that has implemented intelligent
security analysis security analysis to process the information
constantly and identify anomalies. This makes
security monitoring much easier for security and
DevOps engineers. One of the best examples of
this is the threat protection on Azure, a collection
of security services and functionalities. Azure
threat protection provides an overview of what
is happening at any time within your application.
Therefore, choosing the right platform for your
infrastructure and configuring the right tools can
significantly impact security monitoring operations.
Centralize A critical aspect of security monitoring is centralizing
security all security issues and managing monitoring.
monitoring Especially for enterprise organizations, having a
birds-eye view is necessary. Without these, one
might lose control on what is happening easily,
resulting in huge costs for the organization. On the
cloud, this is called “security posture management.”
As an example, let’s look at the Sentinel product from
Azure. Azure Sentinel connects to each different
solution to collect data. Then, inside Azure Sentinel,
you are notified of previously undetected incidents,
investigating issues using artificial intelligence and
other features. These help to respond to incidents
rapidly and stay compliant.
Another example is the AWS Security Hub, which
provides cloud security posture management.
Therefore, there are still options for security
monitoring on any platform you choose. Having this
knowledge upfront will help to plan your security
roadmap accordingly.
Implementing a notification infrastructure encourages downstream
security stakeholders (developers, testers, operations, audit,
executives, etc.) to work closely with upstream providers (like security
testers) to ensure that the work is optimized for them. Your DevSecOps
pipeline should be designed for very tight feedback loops — think
REFCARD | FEBRUARY 2022
REFCARD | INTRODUCTION TO DEVSECOPS
seconds, not hours, weeks, or months. The faster you can get feedback
from the people that need it, the more secure and cost-effective your
DevSecOps pipeline will be.
In the beginning, a DevSecOps pipeline will only verify a few simple
things about the software. But over time, as challenges are addressed,
you will automate verification of more and more of the security
strategies and defenses. Over time, the goal is to migrate from manual
security testing to a fully automated pipeline capable of deploying
secure code directly into production without gates.
CHOOSING SECURITY TOOLS AND TECHNOLOGIES
Here are a few of the attributes to consider when choosing security tools
and technologies to build your DevSecOps pipeline across the entire
SDLC. Please note that there is no one set of best tools for DevSecOps.
The tools you choose should match how you build software, your goals,
your culture, and the other technologies you use.
Table 5
CONSIDERATIONS FOR DEVSECOPS TOOL SELECTION
CONSIDERATION DESCRIPTION
Policy coverage First and foremost, you must confirm that the tool
actually covers the risks you need it to cover. Many
products have surprising shortcomings in this
area. See the OWASP Benchmark Project for help.
Accuracy Accuracy (eliminating both false positives and
false negatives) is critical. Inaccuracy means
humans have to fix results, which will destroy your
pipeline. You should carefully test your tools to be
sure they accurately verify what you need.
Speed You need to test whether tools are fast enough to
work as a part of your DevSecOps pipeline. That
may be microseconds, seconds, or minutes — but
probably not hours and certainly not days.
Scale Consider the size of your application portfolio
and whether the tools you select can operate
continuously, in parallel, and across the entire
portfolio. Be sure to factor in the number of people
you need to make that work.
Process fit It is best to verify that the tools are useful without
a complex installation process. When well-
meaning security folks buy tools for development
and operations teams, it can cause friction if
they aren’t compatible with their technology
stack or workflow. Engage the actual users in the
evaluation process and conduct pilots to confirm
they will be easy to install and use.
Integrations Verify that the tool integrates with the tools that
people in your DevOps toolchain are already using.
Look for well-documented, supported REST APIs
and SDKs in a variety of languages, IDE plugins,
webhook support, ChatOps integrations like
HipChat and Slack, notifications with PagerDuty
and VictorOps, and SIEM integrations like Splunk.
TABLE CONTINUES ON NEXT PAGE
7 BROUGHT TO YOU IN PARTNERSHIP WITH

CONSIDERATIONS FOR DEVSECOPS TOOL SELECTION
CONSIDERATION DESCRIPTION
Security on the Security becomes a shared responsibility between
cloud cloud providers and companies in cloud solutions.
As the complexities of architecture increase on
the cloud, controlling events is much easier than
on-premise architectures. The interesting thing
about cloud architectures is that you can add
these options to your design before developing
any line of code. So your solution design is already
security-proof before the implementation.
Additionally, every resource is created by code,
and that’s how engineers can think of all security
issues earlier on in the development process.
Cloud providers already give best practices for
various security practices such as using firewalls,
network security groups, DDoS and identity
management, etc. They also provide various tools
and products to implement and monitor security
measures.
DEVSECOPS CORE PRACTICES
DevSecOps takes a very agile approach to security, breaking down
massive security tasks into incremental improvements that are
performed as everyday development tasks. These small batches of
work include continuous verification so that security builds over time
instead of repeatedly starting from scratch.
DevSecOps brings a culture of “security for everyone” to teams.
Everyone has a significant role to play in security at their organization.
Security specialists are critical in this by mentoring, advising, and
leading teams to ensure quality and security.
Once we’ve identified the next security challenge, our normal
engineering process can execute on the improvement. In this section,
we explore four core practices to any DevSecOps initiative. Of course,
your DevSecOps process might be considerably more complex. See
the next section for more ideas, or add your own practices to this basic
cycle.
Figure 4
Fundamentally, it is the constant tension between creating defenses
and attempting to break them that actually makes organizations more
secure. The faster you can repeat this DevSecOps cycle, the faster you
REFCARD | FEBRUARY 2022
REFCARD | INTRODUCTION TO DEVSECOPS
can improve security. Over time, you’ll build a complete security story
that will provide assurance both internally and externally.
1. ANALYZE: IDENTIFY YOUR NEXT MOST CRITICAL
SECURITY CHALLENGE
Why should one always focus on the most critical security challenge?
Generally, working on anything else won’t change your security posture
very much. It doesn’t help to close the attic window when the garage
and front door are wide open. In DevSecOps, we get the work flowing
by creating small batch sizes. So, in most cases, we want to work on our
enterprise's most critical security challenge first. Still, don’t be afraid
to choose a partial measure or a tiny improvement to your most critical
challenge. Working in small increments makes sure we stay on track.
When deciding what to work on next, the team looks at all the potential
security “work” available and makes it visible. The team might add
new features, pay down some technical debt, make an architectural
improvement, fix defects/vulnerabilities, or do something to improve
the team’s tools or practices to improve quality, security, or productivity.
It’s important that the team use its threat model and security
architecture to make an informed decision about the next most critical
security challenge. What is the cost to the company of certain kinds
of attacks? What is the cost of implementing preventive measures for
those attacks? Try to use both internal and external data sources to
figure out the next thing to do that will most effectively reduce risk.
You may find yourself without a threat model or security architecture.
Fortunately, in DevSecOps, these artifacts are created one step at a
time. When you’re starting out, it’s easy to identify your top challenges:
the problems that are the most likely to be found, exploited, and
cause serious damage like injection, authorization problems, known
vulnerabilities, etc.
Consider all the different layers of your application stack:
Table 6
SECURITY CONSIDERATIONS FOR
LAYERS OF THE APPLICATION STACK
LAYER CONSIDERATION(S)
Applications and Do you have proactive controls in place? Are you
APIs susceptible to common vulnerabilities?
Libraries and Are your libraries and frameworks up-to-date and
frameworks properly configured? Do you have a complete, up-to-
date inventory (with exact version numbers) of all the
software you are running across all your servers?
Containers Have you hardened your platform configuration
and kept it up to date? Are your cloud environments
configured correctly? Did you consider scanning
container images against vulnerabilities? Did you
add security scans to your pipeline?
TABLE CONTINUES ON NEXT PAGE
8 BROUGHT TO YOU IN PARTNERSHIP WITH

SECURITY CONSIDERATIONS FOR
LAYERS OF THE APPLICATION STACK
LAYER CONSIDERATION(S)
Cloud resources Are applications and customer data secure? Do
we have an authorization matrix in place to make
sure the right people have the right access? Are
networking configurations configured properly
for each resource? Do we have the penetration test
results on public-facing resources?
Network Do you have strong network security defenses in
place and monitored for attacks?
Use a risk-based approach to decide what to work on next. Be sure to
consider whether there’s a viable connection between a threat agent,
attack vector, weakness, technical impact, and business impact in your
enterprise. OWASP depicts this connection as follows:
Figure 5
Going forward, you should practice a combination of threat intelligence
and security research to continuously zero in on your next most critical
security challenge. Note that this process is significantly different from
assessing all your threats. Many organizations get overwhelmed trying
to protect against everything at once.
Table 7
DEVSECOPS THREAT INTELLIGENCE, SECURITY RESEARCH,
AND SECURITY ARCHITECTURE
Threat External sources: ISACs (STIX/TAXII), OWASP, SANS,
intelligence BlackHat, DefCon, LASCON, DevSecCon, CISO
events, friendly peer companies, etc.
Internal sources: Monitor your systems for attacks
and learn from the data. Understanding actual
attacks is a major factor in prioritizing.
Security Security research should focus on challenging
research security architectures and identifying new strategic
ways to improve security. Where possible, work with
development to enhance the DevSecOps pipeline
with new testing methods.
Security There is a shortage of great threat modeling and
architecture security architecture tools. But some interesting
projects include OWASP Threat Dragon, IriusRisk,
and Chaos Engineering (Chaos Monkey, ChaoSlingr).
REFCARD | FEBRUARY 2022
REFCARD | INTRODUCTION TO DEVSECOPS
You’ll have to work out your own cadence for re-examining your threat
model. So, increasing your cycle speed will directly affect the level of
security you are able to achieve. And because DevSecOps adds to your
security incrementally with continuous security verification (discussed
below), you have protection against backsliding.
2. SECURE: IMPLEMENT A DEFENSE STRATEGY
Once you’ve decided on a security challenge to tackle, you’ll need to
choose a defense strategy. A defense strategy isn’t a single security
mechanism or product. A defense strategy can combine technical
security mechanisms, secure coding practices, procedural controls,
supporting processes, training, background checks, and more. We are
using the term “defense strategy” broadly to include anything that
you rely on to prevent a breach. Your defense strategy for a particular
challenge can (and probably should) comprise one or more primary
defenses and a set of supporting defenses as well.
In an agile way, you have defined stories and tasks for each sprint. The
product owner is the person who defines new feature requests and also
the priority level. This usually applies to application features and not
security. In a DevSecOps approach, security is also considered a high
priority feature added to the backlog. Security specialists give consults
on what needs to be done, and all team members can participate in the
implementation, test, and delivery. This approach prevents teams from
having security silos, and security expertise is shared between all team
members from developers to testers and DevOps engineers.
You can capture each security strategy for implementation in a JIRA
ticket that covers each security enhancement that you want to make,
including:
Table 8
DEVSECOPS DEFENSE STRATEGIES
STRATEGY DESCRIPTION
Challenge The goal is to justify why this is an important security
description challenge concisely. This might take the form of a
security story or misuse case. The description should
cover the elements shown in the OWASP diagram above.
Defense story This story should detail exactly how the defense
should work. For technical defense mechanisms,
the story should clearly detail how the threat is
countered and why this defense is effective. For
other defenses, how they work to provide protection
should be argued.
Documentation As part of the defense strategy, you should also
consider how to configure, operate, and use these
defenses. This guidance should be written as a
tutorial to apply to end-users and operations staff,
and even indicate how developers should use
the defense effectively. It is vital to document all
operations and implementations to prevent any
rework in the future.
TABLE CONTINUES ON NEXT PAGE
9 BROUGHT TO YOU IN PARTNERSHIP WITH

DEVSECOPS DEFENSE STRATEGIES
STRATEGY DESCRIPTION
Security testing It is important to define automated tests, which
approach verify the correctness and effectiveness of the
defense strategy.
Fail and test Do not wait for disaster to strike in order to verify
your system security effectiveness. Instead, try to fail the system
and challenge implementations yourself. This can be
done on environments other than production, where
you may have a clone production environment like an
acceptance environment. Simulate security issues to
see if the defense strategy works as expected.
Security The final part of the defense strategy is to detail
monitoring how to will continuously monitor security and avoid
possible attacks.
Your strategy is right when you can easily answer with confidence when
anyone asks: “How do you protect against X?” Having a clear, concise,
defensible answer to this kind of question can not only provide an easy
path to compliance but can also provide business advantages over
competitors.
Your defense strategy doesn’t have to be perfect from the very start. It’s
far better to start with a basic defense and evolve it over time. After you
implement a basic defense, you may choose to work on another, more
pressing, threat. The key to DevSecOps is to continuously reprioritize
based on the threat and existing defenses. The ability to respond
quickly is critical for a world of continuously changing threats.
The work of implementing the security defense shouldn’t be any
different than any other feature. It should — to the maximum extent
possible — be delivered as code or configuration with everything in
source control. Managing security in this way makes it possible to test
and redeploy at any time, ensuring that defenses are in place, working
correctly, and properly configured.
3. VERIFY: AUTOMATE SECURITY TESTING
A key part of DevSecOps is ensuring that the defense strategies have
been properly implemented, configured, and operated. Security
testing is how to verify that your actual security controls match your
intended defenses. In DevSecOps, we focus on automating those tests
by “turning security into code” so that we can run them frequently
without requiring humans, particularly security experts, in the critical
path.
There are many ways to verify the security of a system automatically.
There is no possible way to list them all, but we provide a few examples
of popular tools that have proven to be DevSecOps compatible.
TABLE BEGINS IN NEXT COLUMN
REFCARD | FEBRUARY 2022
REFCARD | INTRODUCTION TO DEVSECOPS
Table 9
POPULAR DEVSECOPS AUTOMATION TECHNIQUES
TECHNIQUE DESCRIPTION
Automate It's not automated if you need humans in the loop.
everything Don't fall into the trap of thinking that you've
automated security when all you really did was
automate the "scan" button. Think about the entire
process. Does the tool require human expertise
to configure or run? Does it require an expert to
interpret and triage the results? We are looking to
eliminate the involvement of humans in the critical
path so that we can push code to production with
both speed and assurance.
Avoid “tool Every tool that you adopt means additional process
soup” steps, a full set of integrations, and a team of
people to configure, run, and interpret. Choose
powerful platforms that will allow you to address
many different types of security challenges using an
integrated framework. Therefore, you avoid having
overhead when maintaining multiple tools.
Test your testing Security testing tools vary significantly in their
tools ability to test real applications for a broad range of
issues. The only way to know how well a particular
tool will work on your applications and APIs is to try
it. Consider temporarily adding “tool canaries” in
your applications to verify that real vulnerabilities
are being discovered and false alarms are not being
flagged. See the OWASP Benchmark project for
details.
Below is a DevSecOps security testing funnel to help you choose a
security verification technique for a particular security challenge. This
may seem obvious, but don’t blindly rely on the wrong tool. Take a
minute to select the simplest, fastest, most accurate way to check that
your defense implementation is correct, complete, and configured.
For example, testing for proper clickjacking protection is easy if you
simply examine HTTP responses for the proper security headers. But
it would be very difficult to verify this by looking at the source code, as
there are so many ways to accomplish this.
Table 10
DEVSECOPS SECURITY TESTING FUNNEL
QUESTION RECOMMENDATION
What are we Think carefully about exactly what you want to
trying to test? test and the results you want. Direct, complete
verification of application behavior is always best,
but you can use sampling, fuzzing, design analysis,
and other techniques.
Do we need to Probably, yes. But you should clearly prioritize things
test it? that are the most critical to security and the most
likely to be discovered and exploited by an attacker.
TABLE CONTINUES ON NEXT PAGE
10 BROUGHT TO YOU IN PARTNERSHIP WITH

DEVSECOPS SECURITY TESTING FUNNEL
QUESTION RECOMMENDATION
Positive or Are we able to verify that the application always
negative follows a known good pattern of execution (positive
testing? security), or will we have to resort to trying to verify
that the application never follows any of the known
bad patterns of execution (negative security)?
Do we already You may be using a security testing tool that covers
test for it? this risk. It's critical to confirm that your tool does a
good job of accurately and efficiently verifying your
security defense.
Do we already Perhaps you just need to enable a rule in a tool you're
have a platform already using. Or maybe you can use an existing tool
that will allow as a platform for creating a custom rule.
us to test this
easily?
Can we test it by If we can't use a security testing platform, can we
writing custom create a custom test case?
tests?
Is there another •  Network: nmap, sslyze, ssh_scan, Tenable,
tool on the Qualys.
market that can
•  Cloud/container: Aqua, Twistlock, Redlock,
help test this?
ThreatStack.
•  Libraries/frameworks: OWASP Dependency
Check, retire.js, Contrast Assess, Snyk,
Sonatype, BlackDuck.
Application: OWASP ZAP, Arachni, sqlmap, Burp,
Contrast Assess, Micro Focus, CA Veracode,
Synopsys, Checkmarx.
Do we need While the goal of DevSecOps is to minimize the
human experts number of things that you need human experts to
to test it? test, bug bounties, red team exercises, and manual
penetration testing can provide useful insight into
defenses that are difficult to test automatically.
Ensure that these efforts deliver rules, test cases,
and other automation, not PDF reports.
Examples: BugCrowd, HackerOne
Are we also It’s impossible to know everything, so certain kinds
testing for what of testing rely on volume and randomness to try to
we didn’t think force applications to misbehave. Fuzz testing and
of? chaos engineering tools can help here.
Any security issues discovered during testing should feed into the
DevSecOps management infrastructure described above to notify all
the people that need to know through the tools they are already using.
4. DEFEND: DETECT ATTACKS AND PREVENT
EXPLOITS
DevSecOps organizations recognize that you can never test yourself
securely, so they adopt a balanced approach that focuses on minimizing
vulnerabilities during development and identifying and preventing
vulnerabilities from being exploited in production. While these two
activities have traditionally been separated, DevOps has brought them
together by supporting the full software lifecycle.
REFCARD | FEBRUARY 2022
REFCARD | INTRODUCTION TO DEVSECOPS
Table 11
DEVSECOPS ATTACK DETECTION AND PREVENTION TOOLS
TOOL DESCRIPTION
Runtime RASP uses application instrumentation to add attack
Application detection and prevention directly to applications
Self Protection regardless of where or how they are deployed.
(RASP) DevSecOps projects can use RASP to achieve
accurate attack-blocking and the flexibility to deploy
in cloud/container environments easily.
Examples: Contrast Protect, Prevoty, Immunio.
Web Application WAFs have been on the market since the early
Firewall (WAF) 2000s and have a history of complex configuration
and spotty protection. Nevertheless, a DevSecOps
project might be able to use a WAF for basic
protection or as a platform for virtual patches.
Examples: ModSecurity, Imperva, F5, Signal
Sciences.
Network There is a variety of network-, container-, and host-
Intrusion level protections against attacks. Seek out products
Detection and that can be deployed and managed as part of your
Prevention (IDS/ standard technology stack.
IPS)
Examples: Snort, Suricata, Bro, Kismet.
Security SIEM tools provide real-time analysis of security
Information alerts generated by applications and network
and Event hardware and are important to handling attacks in
Management DevSecOps.
(SIEM)
Examples: Splunk, ELK, SumoLogic, LogRhythm,
ArcSight.
The threat and attack data gathered should feed directly into the next
DevSecOps cycle to use security research to help choose the next most
critical security challenge.
DEVSECOPS ADDITIONAL PRACTICES
Additional sets of security challenges emerge when an enterprise has
hundreds or thousands of applications in their portfolio. Doing security
at this scale is far beyond what a small, dedicated security team can
accomplish. DevSecOps is a technique for distributing this work
effectively across development and operations.
It’s worth noting that in most organizations, only a small percentage of
projects are very far along in their DevOps journey. So, managing the
transition to DevSecOps across an entire application portfolio is a key
part of the challenge.
STANDARD DEFENSES AND ENTERPRISE
SECURITY ARCHITECTURE
Generally, DevSecOps organizations — particularly those with large
application portfolios — prefer standard security defenses that are
heavily tested for correctness and effectiveness.
Don’t reinvent authentication, authorization, for encryption for every
application and API you build. This reduces the amount of security
11 BROUGHT TO YOU IN PARTNERSHIP WITH

work that must be done and simplifies the organization’s security
architecture. Achieving effective enterprise security architecture in a
DevSecOps manner is beyond the scope of this document, but these
guidelines are reasonable first steps.
Table 12
GUIDELINES FOR EFFECTIVE
ENTERPRISE SECURITY ARCHITECTURE
STRATEGY DESCRIPTION
Security Generally, it is best to use popular, well-tested
libraries libraries for security features, as it is dangerously
easy to make small but disastrous mistakes writing
your own. Probably the best approach here is to
assemble your own enterprise security API that
implements, extends, wraps, or is based on existing
security libraries like Spring Security, OWASP ESAPI,
BouncyCastle, OWASP Encoder, AntiXSS, AntiSamy,
Jasypt, etc.
Standardize To the greatest extent possible, you want a standard
on a standard approach to security, and you should use the security
software stack features provided by your software stack. This
makes security invisible or automatic and reduces
the likelihood of mistakes. Don't assume they're
working, though; you have to test these defenses
continuously.
Security services Consider the extent to which you can turn security
defenses into high assurance services that your
applications can invoke. This creates the possibility
of upgrading security across many applications
without having to recode, retest, and redeploy. In
the spirit of DevOps, make sure there is a self-service
way for your empowered engineering teams to
consume them without needing central approval or
provisioning.
MANAGE THE SOFTWARE SUPPLY CHAIN
Libraries have serious vulnerabilities, most of which have not yet been
discovered by the good guys. And attacks now start within a day or so of
new vulnerabilities being disclosed. So, every DevSecOps project must
pay attention to the security of its supply chain.
Your software stack is composed of thousands of libraries, frameworks,
modules, and components written by unknown developers worldwide.
This becomes an increasing concern when you have open-source
libraries or tools in your stack. These days, it is very common for
developers to adopt open-source libraries such as Bootstrap, Angular
JS, OpenStack, etc.
Although using these libraries can allow you to create software much
more rapidly, what many may not realize is this convenience comes at
a risk. Not all of these libraries are tested via security best practices,
and some libraries are constantly providing new upgrades that need
to be verified. This means that you must take full responsibility for the
security of all of that software.
REFCARD | FEBRUARY 2022
REFCARD | INTRODUCTION TO DEVSECOPS
In practice, this translates to a few important strategies:
Table 13
STRATEGIES FOR SECURE, EFFECTIVE SOFTWARE MANAGEMENT
STRATEGY DESCRIPTION
Show some Be cautious about the libraries and frameworks that
restraint you adopt. Stick to projects that demonstrate a solid
security program, evidence of security testing, and
effective response to new vulnerabilities.
Self-inventory DevSecOps organizations must know the exact
version of every library, framework, application,
and API that is running on every server in every
environment. The best approach is to enable all your
systems to self-inventory by reporting their “bill of
materials” to a central database. This “always-up-to-
date” inventory will enable you to respond quickly to
novel attacks.
Establish When you decide to take on a new library,
secure coding standardize how you will use it safely (both positive
guardrails and negative rules) and turn them into code so they
can be continuously tested.
Test for latent Before you trust your business to someone else’s
vulnerabilities code, you must verify that the defenses that are
provided by the libraries and frameworks work
as advertised and don't contain undiscovered
vulnerabilities. Very few libraries receive adequate
security testing.
Continuously Modern applications are only fully composed at
monitor for new runtime, as their dynamic dependencies, plugins,
vulnerabilities and injections are fully realized. RASP tools
and respond (discussed above) can proactively prevent both
known and unknown vulnerabilities from being
exploited.
EXPLODE, OFFLOAD, RELOAD
While it’s not strictly necessary, many DevOps projects use the cloud,
containers, and APIs. Many organizations have already discovered
that this is, in fact, the fastest path to securely achieving digital
transformation. DevSecOps projects should strongly consider Ed
Amoroso’s advice to “explode, offload, reload.”
Table 14
DEVSECOPS ADVICE: EXPLODE, OFFLOAD, RELOAD
ADVICE DESCRIPTION
Explode Perimeters are no longer effective at stopping
attacks, so the first step is to break up your
monolithic internal infrastructure into smaller
distributed workloads.
Offload Second, take advantage of security and cost
advantages by moving these new, smaller workloads
to virtual cloud and container infrastructure.
Reload Finally, re-establish continuous security for each of
your newly virtualized workloads by selecting and
deploying modern protection technology at the
application, library, container, and network layers.
12 BROUGHT TO YOU IN PARTNERSHIP WITH

This strategy is very compatible with DevSecOps, as it allows for efficient
centralized security management with distributed enforcement for
speed and accuracy.
CREATE A SECURITY CULTURE
Some companies simply seem to have the ability to take security
seriously, focus, and do a great job. But others — even companies that
seem to be doing all the same practices and using the same tools — are
simply terrible at security. The difference is culture. And while culture
is a difficult thing to change, there are a few key practices that have
worked in organizations and should be part of a DevSecOps program.
DEVSECOPS CULTURE IN TEAMS
When it comes to the DevSecOps culture implementation, teamwork
is key. Communication is the most important part of creating a
collaborative atmosphere within teams. The goal of DevSecOps is to get
everyone involved so that security does not fall under the responsibility
of one person or department, but it is distributed between everyone
across the SDLC.
Now, let’s look at a few strategies to create a DevSecOps culture on your
team.
Table 15
DEVSECOPS CULTURE STRATEGIES FOR SUCCESS
STRATEGY DESCRIPTION
Executive You must have support from the executive level.
sponsorship Executives need to clarify that security is everyone’s
responsibility — and that simply getting past the
compliance audit is not the goal.
Micro-training Everyone needs to understand exactly what their
security responsibilities are. The best way to achieve
this is by providing instant feedback while doing
their job.
Accountability Development and operations team members should
be responsible for the security of what they produce
and operate. Security specialists shouldn't be in
the critical delivery path and should instead act as
coaches and tool smiths.
Security in Make security as visible as possible. Be sure that
sunshine vulnerability and attack data are never used to
shame people. Instead, celebrate security risks as
the fastest path to learning and improving. Only
when security is visible can you achieve a culture of
making informed risk decisions.
REFCARD | FEBRUARY 2022
REFCARD | INTRODUCTION TO DEVSECOPS
WHAT’S NEXT FOR DEVSECOPS?
DevSecOps is still in the formative stages. The best way to get involved
is to implement DevSecOps in your organization and publish your
experiences. Here are some sources of additional information:
•  The Phoenix Project
•  Microsoft Azure DevSecOps
•  AWS DevSecOps Blog
•  GitHub's Architect's Guide to DevOps
•  Integrating Security Into the DNA of Your Software Lifecycle
•  WhiteHat Security's 12th Annual Application Security Statistics
Report
REFERENCES
•  https://www.linkedin.com/pulse/lose-security-wheel-edward-
amoroso/
•  https://docs.microsoft.com/en-us/azure/sentinel/
•  https://docs.microsoft.com/en-us/azure/security/
fundamentals/threat-detection
•  https://aws.amazon.com/security-hub/
WRITTEN BY ALIREZA CHEGINI,
SENIOR DEVOPS ENGINEER, AZURE SPECIALIST AT S-RM
Alireza is a software engineer with more than
20 years of experience in software development.
He started his career as a software developer, and
in recent years he transitioned into DevOps practices.
Currently, he is helping companies and organizations move away
from traditional development workflows and embrace a DevOps
culture. Additionally, Alireza is coaching organizations as Azure
Specialists in their migration journey to the public cloud.
600 Park Offices Drive, Suite 300
Research Triangle Park, NC 27709
888.678.0399 | 919.678.0300
At DZone, we foster a collaborative environment that empowers developers and
tech professionals to share knowledge, build skills, and solve problems through
content, code, and community. We thoughtfully — and with intention — challenge
the status quo and value diverse perspectives so that, as one, we can inspire
positive change through technology.
Copyright © 2022 DZone, Inc. All rights reserved. No part of this publication
may be reproduced, stored in a retrieval system, or transmitted, in any form or
by means of electronic, mechanical, photocopying, or otherwise, without prior
written permission of the publisher.
13 BROUGHT TO YOU IN PARTNERSHIP WITH