Cisco_eBook_ShiftLeftSecurity_2022_06_07a.pdf

Shift Left Security
J U N E 2022
Fundamentals
of Shift Left
Security
Create more secure applications
with best practices for your software
supply chain and CI/CD pipeline

Table of
Contents
Introduction
What Is “Shift Left Security”?
Why Is Shift Left Security Important?
How Does an Organization Make the Shift?
The Security of Your CI/CD Pipeline
The Security of Your Software Supply Chain
Conclusion
Cisco’s Tools
3
4
6
9
13
17
21
22
2
eBook | Shift Left Security

Introduction
Modern development teams have become highly adept at
building software applications.
DevOps culture and practices—the leftward-on-the-timeline
shifting of operational responsibilities—have empowered teams
to move more quickly as they build complex applications.
As CI/CD pipelines automate testing and infrastructure
provisioning, applications are becoming more reliable and are
shipping faster. And monitoring tools are alerting engineers to
potential failures so they can respond more quickly.
Today’s teams build complex systems that scale massively,
comprise countless microservices, and are distributed
across the cloud. But there is a downside to this progress:
The complexity and distributed nature of modern applications
also bring an increased risk of security threats.
But in many organizations, the security team has little
influence on the design or development of an application.
Siloed away from DevOps, the security team is responsible
for dealing with the risks and threats after the application
goes live.
It’s time for security, just like operations, to shift left.
In this guide on shift left security, we’ll look at what it is, why
it’s important, and how organizations can begin to make the
shift. We’ll also focus on security in two key areas: your CI/CD
pipeline and your software supply chain.
Planning
Source Control Management
Coding
Local Testing
Code Review
CI/CD Management
Pre-Deployment Testing
Development
Infrastructure Provisioning
Production Deployment
Smoke Testing
Rollbacks
Day 1 Operations
Shift Left
3

What Is
“Shift Left
Security”?
A DevOps approach divides the steps in the
software development life cycle (SDLC) into
three phases:
1. Development includes all the planning,
implementation, review, and testing that
take place prior to deployment.
2. Day 1 Operations is concerned with the
actual deployment of the application, and
it includes infrastructure provisioning,
installation, configuration, smoke testing,
and deployment rollbacks.
3. Day N Operations covers all the tasks
after an application goes live, including
monitoring, issue detection, and alerts.
4

In this timeline of phases, the further left a bug is discovered,
the lesser the impact of that bug, and the lower the cost of
mitigating issues arising from that bug. That’s why automated
and rigorous testing of individual code units is of such high
value in DevOps culture.
Shift left security says: We should take the same approach
to security vulnerabilities as we do with bugs. If security
risks can be handled further to the left, then fewer
vulnerabilities will sneak through, and the blast radius of a
vulnerability is smaller. As a result, the cost of maintaining
a strong security posture is lower, and the production
application is more secure.
Shift left security is like exercise, rest, and a good diet.
Preventative health is less costly than treating a health condition.
Shift left security is less costly than fixing a breached system.
Planning
Source Control Management
Coding
Local Testing
Code Review
CI/CD Management
Pre-Deployment Testing
Development
Infrastructure Provisioning
Production Deployment
Smoke Testing
Rollbacks
Day 1 Operations
Monitoring
Issue Detection
Incident Management
Alerting
Post-Mortem
Day N Operations
5
eBook | Shift Left Security 5

Why Is Shift
Left Security
Important?
Because
Insecurity Is
Expensive.
Let’s look at the potential costs of not
adopting shift left security.
6

The effect on overall system security
Without proper security mechanisms in place, developers can
get sloppy. They’ll write hasty duct-tape code patches, rely on
a convenient but vulnerable library, or manually apply changes
directly to a production machine. Without security guardrails in
place, the resulting system is at high risk of being exploited.
The effect on productivity
When a vulnerability is exploited, engineering teams are
thrown into disarray. First, responsible teams will need to
devote resources to incident response, damage control, and
the patching of vulnerabilities.
Next, you can expect a heavy-handed reaction from the
security team and business stakeholders. Developer access
to cloud resources will be restricted. Code updates and new
features will be met by a slew of measures for enforcing
manual reviews and approval. Productivity will plummet.
The cost of data breaches
In today’s systems, data flows between and is stored in
various cloud providers and on-premises systems. Without the
right security mechanisms in place, the risk of a data breach
is high, and an organization may be unable even to detect that
a breach has occurred. An IBM/Ponemon report found that
the average time to identify and contain a data breach was
287 days. The report pegged the average cost of a breach, in
hybrid cloud environments, at $3.61 million.
7

The cost of regulatory non-compliance
Without a proper security posture toward the open-source
libraries your applications depend on, your organization
might be in violation of licensing terms. If your application
mishandles personally identifiable information (PII) or
protected health information (PHI), the result could be heavy
financial penalties or legal consequences. For example,
GDPR fines resulting from data protection and privacy
violations can be staggering.
The cost of system downtime
Vulnerable applications, when attacked, will result in system
downtime. Whether it’s the direct result of a DDoS attack
or system stoppage for patching, any downtime hurts
your business. When customers can’t use or access your
applications, they will stop paying for your services.
The risk to business reputation and loss of
customer trust
There’s no question that a company’s brand is tarnished
when news gets out about customer data being stolen or an
unbearably long system outage. If your applications are not
secure, it’s only a matter of time before those security threats
are realized. As soon as you lose the trust of your customers,
they’ll walk.
8

How Does an
Organization
Make the Shift?
The traditional approach to application
security involves manual checks, reviews,
and patch updates. Security threats are
handled reactively—after an exploit makes
the news or once poking around in some
logs reveals suspicious activity. However, this
approach is untenable for today’s complex
and distributed applications.
By adopting shift left security, the focus
of security efforts starts well before
Day N Operations.
9

Security at the Development phase
Design, implementation, and testing all take place during the
Development phase of the timeline. Discovering and mitigating
security vulnerabilities at this early stage can reap significant
savings of resources—human and financial—down the road.
Security-aware planning and design
Among the Open Web Application Security Project (OWASP)
list of Top Ten Web Application Security Risks for 2021 is
insecure design. OWASP notes: “If we genuinely want to
‘move left’ as an industry, it calls for more use of threat
modeling, secure design patterns and principles, and
reference architectures.” Taking these steps will ensure
system designs incorporate security practices like access
control, auditing, levels of isolation, and alerting.
10

Secure coding practices
Secure coding practices include techniques like input
validation, parameterized queries, and proper handling
of sensitive data or credentials. However, the list of best
practices continues to grow, and how they’re applied varies
from language to language and framework to framework.
One solution is for developers to use IDEs that have built-in
tools that analyze your code for potential risks as you work.
Many IDEs also incorporate linters which help ensure code is
properly formatted and that it conforms to coding standards.
Access control
Most web applications have a login component and different
levels of access (such as basic user, privileged user, or
administrator). The OWASP list referenced above includes
identification and authentication failures as well as broken
access control. Therefore, when designing an application, it’s
important to give special attention to the components related
to access control. In other words, don’t treat them just like any
other component or microservice. If a malicious user gains
access to your web application with administrator privileges,
the impact could be devastating.
Testing
Unit testing at the early stages of application development
can focus on more than just business logic and preventing
bugs, but also include security-related tests. Testing can verify
proper measures are in place for securing access control,
preventing injection attacks, and validating inputs.
Security at Day 1 Operations
Implementing secure practices for Day 1 Operations is heavily
related to the security of the CI/CD pipeline, which we will
consider in its own section in this eBook.
11

Security at Day N Operations
Although shift left security does emphasize a focus on
security at the Development phase and in Day 1 Operations,
organizations should still adopt security best practices within
the processes of Day N Operations. Adopting these practices
will help teams to respond faster and more effectively in the
event of a security incident.
Observability
With shift left security, an application can be designed from
the outset to include instrumentation for exposing logs,
metrics, and traces, making the components of an application
observable. A DevOps team, by examining this observability
data, can discern the state and the health of an application.
It can also use the data to gain insights into the root cause of
incidents, including security threats.
Monitoring
Monitoring puts a constant watch on specific metrics or
application states so that engineers can know immediately
if something is of concern. Observability data helps teams
understand why an application is in the state that it is.
Monitoring, on the other hand, tracks specific metrics to let
teams know when a noteworthy state is entered. For example,
a team may specifically choose to monitor critical metrics
like bad password attempts, HTTP requests per minute, or
database query latency.
Alerting
Connected to monitoring, of course, is an alerting component
that notifies responsible team members as soon as certain
monitored conditions surpass a critical threshold or reach a
noteworthy state.
12

The Security
of Your CI/CD
Pipeline
Day 1 Operations depend heavily on the CI/
CD pipeline, which is an integral part of the
toolchain for mature DevOps teams. The
CI/CD pipeline deserves special treatment
in our coverage of shift left security.
Engineering teams can use the automated
pipeline to apply security measures when
building and deploying an application.
However, teams also need to ensure that the
pipeline itself is secure. Let’s look at these
concepts in more detail.
13

Secret and credential management
As part of Day 1 Operations, the CI/CD pipeline is responsible
for provisioning infrastructure and deploying workloads. Your
CI/CD pipeline will be configured to use your organization’s
credentials for accessing cloud provider accounts, service
accounts, and other resources.
Storage of these credentials must be secure. Managed
pipeline services include secret management tools for
encrypted storage, decrypting secrets only when your pipeline
uses them.
Restrict the task of infrastructure provisioning and workload
deployment to your CI/CD pipeline alone. An automated
pipeline ensures that these tasks are performed the same
way every time. Allowing an engineer to perform these
tasks manually runs the risk of skipping critical security or
configuration steps.
The credentials used by the CI/CD pipeline should be tightly
held. Since engineers shouldn’t be allowed to perform these
tasks manually, they do not need access to these secrets.
CI/CD Pipeline
Tokens Cloud
API Keys
Database user
credentials
Private
certificates SSH Keys
Kubernetes service
account credentials
14

Infrastructure as code
Delegating infrastructure provisioning to your CI/CD pipeline
ensures you get the same infrastructure with the same
configurations and settings on every deployment. By using
infrastructure as code, you create declarative configurations of
your system architecture.
Without a declarative configuration, an engineer might make
on-the-fly changes to infrastructure configurations, and this
introduces drift. These habits introduce security risks and are
difficult to track or audit.
By adopting infrastructure as code, such as AWS
CloudFormation or Terraform, every change to an
infrastructure configuration can be recorded and reviewed as
the configurations are stored in a version control system.
Static code analysis
A CI/CD pipeline can run a suite of automated tests followed
by processes that build, deploy, and configure the production
application. At any point in that series of processes, the
pipeline can be tasked with applying additional security
measures or engaging other tools.
In the section on secure coding practices, we mentioned the
use of IDEs for real-time analysis of code. Further analysis can
be performed across all code for an application by using static
code analysis tools. Tools like SonarQube can be integrated
into the CI/CD pipeline and run before building the application.
This will ensure that all code conforms to security standards
and conventions.
15

Vulnerability scanning
Just as static code analysis examines your application’s code
for security flaws, vulnerability scanning checks container
images or third-party dependencies for security risks. Tools
like Trivy or Grype can be integrated with the CI/CD pipeline to
perform scans.
In the section on software supply chain security, we cover the
threat of third-party dependencies in more detail.
Alerting on broken CI/CD
For the sake of security, all infrastructure configurations
and changes, including updates or rollbacks or restarts, are
handled by your CI/CD pipeline. This has several implications.
First, your CI/CD pipeline must be highly available. You
depend on your CI/CD pipeline to make changes to your
infrastructure—and you may need to do so urgently if a
security breach necessitates shutting down or isolating
parts of your application. Whenever your CI/CD pipeline is
unavailable, your hands are tied, and you’ll be unable to make
infrastructure changes.
Second, your CI/CD pipeline must be deployed securely.
If the CI/CD pipeline itself is vulnerable to attack—making it
unavailable or exposing its sensitive data for exfiltration—then
your entire system will become vulnerable.
Approaching your CI/CD pipeline with a focus on security
means planning in advance for how your team will handle a
broken CI/CD pipeline. Consider what would need to be done
to keep your systems running securely while the pipeline is
being repaired.
16

The Security of
Your Software
Supply Chain
Open-source software has become a staple
in modern software development. While the
application you build may be proprietary, it
likely has a set of third-party dependencies
which include open-source libraries,
packages, container images, or tools.
Those dependencies in turn have their own
sets of dependencies. The entire chain of
dependencies—starting with your first library
dependency and reaching all the way to
the smallest I/O package at the end—is your
software supply chain.
An emphasis on security implies heavy
scrutiny of every package in your software
supply chain. A security vulnerability in
your software supply chain exposes your
application to risk.
17

The far-reaching impact of a software supply
chain attack
By relying heavily on open-source software in their software
supply chain, organizations give an unquestioning level of trust
to the developers and organizations behind these third-party
dependencies. However, even if the maintainers of these
projects are not malicious actors, who can guarantee that their
approach to security will be as conscientious as yours?
Libraries continually undergo version updates, and each
new version brings with it the potential for introducing a
vulnerability. Libraries trusted as secure in the past may
undergo several version updates without any further vetting.
Some open-source projects may be trusted and innocuous
for a long time in order to gain trust and adoption, only to be
updated with intentionally malicious code in a later version.
Imagine the reach that a security vulnerability could have if it
were introduced at the lowest level possible—in a dependency
that is relied upon by several key packages that are widely
used throughout the industry. A shift left security approach to
application development requires taking back that blind trust.
Common attack vectors for the software
supply chain
Of the many different ways that a software supply chain can
come under attack, the following are noteworthy
attack vectors.
Common Supply Chain Attack Vectors
Dependency
Confusion
Container Image
Vulnerabilities
Compromised
Packages
Corrupted
Packages
Sabotaged
Packages
18

Dependency confusion
A dependency confusion attack occurs when your package
manager updates your application with code from an unsafe,
public package rather than your vetted, private package.
For example, your application might depend on a trusted,
internal package called auth-lib. Internally, your package is
at version 2.9.3. A malicious actor might publish a package
under the same name, auth-lib, and release malicious code as
version 2.9.4.
The intent of the attack is to confuse package managers that
are not properly configured to prioritize private packages
over public packages. The susceptible package manager
will discover that a new version of the (public) package is
available, and then it will download and install it, overwriting
the trusted package.
Vulnerabilities in container images
When an application directly uses or depends on tools or
libraries that use containerization, then that application is
open to security risks through container image vulnerabilities.
Container images can often be more opaque than open-
source libraries where the source code is freely available for
examination. Because of this, the risk of security vulnerabilities
in container images is real and reasonable.
Compromised libraries/packages
Dependency libraries undergo frequent updates. Security
patches, feature additions, and performance enhancements
can all result in a version update, which comes from the
authoritative maintainer of that software. If, however, a
malicious actor can gain control of the release process to
manipulate the update, the result would be the dissemination
of malicious code under the guise of a trusted update.
Package corruption or sabotage
Recent events (for example, an incident involving faker.js and
color.js) have also shown that package maintainers themselves
may intentionally sabotage their own packages or introduce
malicious code. If an open-source library is present at a deep
enough level in the software supply chain to be used widely,
the result of such sabotage can be crippling.
19

How to protect your software supply chain
Adopting shift left security will mean implementing certain
security measures—especially in the earlier stages of
application development—to protect your software supply
chain. These measures include the following:
• Take a complete inventory of your software supply
chain. By starting with a software bill of materials (SBOM),
you have a baseline from which to begin checking your
dependencies. OWASP CycloneDX is a lightweight SBOM
standard that can help.
• Assess your dependencies for security risks. For
example, Security Scorecards is a tool from the Open
Source Security Foundation that assigns scores to each
open-source dependency to give you an understanding of
your risk.
• Secure your package manager against dependency
confusion attacks by prioritizing internal packages over
public packages, even those with a higher version number.
• Use lockfiles to lock the dependencies you use to specific
versions which you have already vetted as trusted.
Dependency versions will require approval rather than
being automatically updated.
• Integrate vulnerability scanning tools in your CI/CD
pipeline. With the depth and complexity of today’s
software supply chains, it’s impossible to manually check
all of your dependencies for security threats. Vulnerability
scanning tools can examine container images and third-
party libraries for security threats.
• Use signed images to ensure that the images you
incorporate are created by verified parties.
• Use trusted registries for your container images.
20

Conclusion
Shift left security is trending, but it can’t be treated as just
another tech-speak catchphrase. Today’s applications,
complex and distributed, expose a large surface area that is
vulnerable to attack.
Security can’t be an afterthought, with measures taken
reactively on day two. The negative effects and financial cost
of an exploited vulnerability would be too great.
Instead, security needs to be in focus at the outset of
application design and carried out through protocols and the
integration of tools during development, testing, deployment,
and beyond.
In particular, adopting shift left security means taking special
precautions to leverage and secure your CI/CD pipeline.
Also, it means paying special attention to the security of your
software supply chain.
21

Cisco’s Tools
As your organization adopts a shift left security approach to its
applications, Cisco is ready to journey alongside you. Check
out these tools and resources:
APIClarity, for API traffic visibility in Kubernetes clusters.
This open source, cloud-native tool uses a service mesh
framework to capture and analyze API traffic, and identify
potential risks. Check out the GitHub repo.
Cisco AppDynamics with Secure Application. Protect your
organization and your users from attacks and vulnerabilities
with unified business performance and security observability.
Learn more.
KubeClarity, a tool for detection and management of Software
Bill Of Materials (SBOM) and vulnerabilities, in container
images and filesystems. Go to the GitHub repo.
Panoptica, the Cisco Secure Application Cloud, provides
robust security from CD/CD to runtime – for containers,
Kubernetes, and service mesh, and APIs. All in a single pane
of glass interface. Sign up for free.
For more perspective, read the story from Cisco’s Michael
Chenetz in Stack Overflow: Security needs to shift left into the
software development lifecycle.
22

Cisco_eBook_ShiftLeftSecurity_2022_06_07a.pdf

More Related Content

Similar to Cisco_eBook_ShiftLeftSecurity_2022_06_07a.pdf(20)

Recently uploaded(20)

Cisco_eBook_ShiftLeftSecurity_2022_06_07a.pdf