EBOOK
Implementing
DevSecOps for
cloud-native
applications
How to achieve production guardrails and
automate enforcement of security policy
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
1
IMPLEMENTING DEVSECOPS FOR CLOUD-NATIVE APPLICATIONS
Table of contents
Modernization is a business priority today …………………………………..…………..… 3
What is cloud-native? Why does it matter? ……………..……………………..……...….… 4
The cloud-native journey and DevSecOps ……………………………………………….… 5
What is DevSecOps?………..…………………………….…………..…………………..……. 6
Shift—left and DevSecOps …………………..……..……………………..…………….……. 8
Security testing and analysis ……………………………..........……………………...……. 10
Software BOM …………….………………….…………….…….………..…………………. 14
Guardrails ……………………....…………...………..………………………………….….… 15
Where testing and analysis fits in .……...……..……………………………………..….… 18
Key takeaways for DevSecOps ……………………..…………………........………………. 21
Tools for building cloud-native ……….……...………………………........…………...…... 22
Conclusion ………………………….……….………………..……………………………..… 37
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
2
Modernization is a
business priority today
To delight customers and win new business, organizations
need to build reliable, scalable, and secure applications.
That means adopting new technologies, practices, and
consuming services as APIs.
As an application development professional, your
goal is to deliver business value fast. Modern applications
help achieve this goal by separating and decoupling the
monolith into smaller functional services—or microservices
—that focus on one thing and do it well. Each microservice
often has its own data store and can be deployed and
scaled independently. They represent the real world,
where service boundaries equal business boundaries.
This has forced organizations to evolve by giving
engineering teams the autonomy to architect, develop,
deploy, and maintain each microservice. With this approach,
you end up with the ability to make decisions very quickly
because your decisions only impact individual services.
After all, innovation requires change. You can learn faster
by making lots of little changes to drive incremental
innovation, rather than waiting to take one giant leap.
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
3
What is cloud-native? Why does it matter?
Cloud-native is an evolving term. The vast amount of software that’s being
built today needs a place to run and all the components and processes required
to build an application need to fit together and work cohesively as a system.
The Cloud Native Computing Foundation (CNCF) definition states:
Cloud-native technologies empower organizations to
build and run scalable applications in modern, dynamic
environments such as public, private, and hybrid clouds.
This definition has to broadly apply to everyone, but not everyone has the
same capabilities. This is known as the lowest common denominator problem.
It is where you try and appeal to a broader group and their capabilities, but in
doing so you also need to limit the capabilities that can be leveraged.
Amazon Web Services (AWS) goes many steps further
by providing a broad set of capabilities that belong to
a family called serverless. Serverless technologies are
more than just AWS Lambda—these services remove
the heavy lifting associated with running, managing,
and maintaining servers. This lets you focus on core
business logic and quickly adding value.
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
4
The cloud-native journey
and DevSecOps
As we cover the different capabilities your organization needs to acquire
to go fully cloud-native, it’s useful to view each one as a step in a journey.
The map below is a model for how organizations typically evolve their
cloud-native understanding. As your organization or team moves from stage
to stage, you are gaining capabilities that make releasing new features and
functionality faster, better, and cheaper. In the following sections, we’ll be
focusing on the capability of DevSecOps.
6. DevSecOps
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
5
What is DevSecOps?
DevSecOps is the combination of cultural philosophies, practices, and tools
that exploits the advances made in IT automation to achieve a state of
production immutability, frequent delivery of business value, and automated
enforcement of security policy. You’ll notice that this definition is not very
different than the one for DevOps—the only difference being that the
practices and strategies for DevOps have been extended into security.
DevSecOps is achieved by
integrating and automating
the enforcement of preventive,
detective, and responsive security
controls into the pipeline.
Security
Development
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
Operations
6
External drivers of change
There are new security issues on the IT horizon forcing companies to shift to a different
operating paradigm. Unauthorized third parties are consistently finding new ways to exploit
organizations, so companies need to shift their mindset to get in front of these issues.
98%
81%
Software supply
chain events
Open-source software
(OSS) usage
Open-source software
(OSS) issues
Sonatype, 2021 State of the Software
Supply Chain, https://bit.ly/3ooE5UJ
The Linux Foundation, Software Bill of Materials (SBOM)
and Cybersecurity Readiness, 2021, https://bit.ly/3yYeGpP
Synopsys, 2022 Open Source Security and
Risk Analysis Report, https://bit.ly/3ctqHMp
650%
2020
2021
According to a survey conducted by Sonatype, software supply chain incidents increased
650 percent from 2020 to 2021. The Linux Foundation reports that 98 percent of projects
use open-source libraries, and a study by Synopsys reports that 81 percent of open-source
projects contain at least one known vulnerability. Even with some of these alarming statistics,
no one is considering building applications without open-source software as part of the
supply chain, so developers have to solve the problem head-on.
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
7
Shift-left and DevSecOps
From a developer’s perspective, it’s tough
to hear that you may not make your deadline
because you have a critical security issue.
And in most cases this security issue started
out as a single line of code that had a ripple
effect throughout the whole project. The point
of the DevSecOps approach is to catch an issue
while it’s still a single line or a small feature,
before it permeates the entire code base.
Shift-left doesn’t mean shift the responsibility,
what it means is to shift the feedback closer to
an earlier point where problems can be more
easily addressed. A developer, IT engineer,
or even InfoSec staff will have great difficulty
reacting to thousands of security issues. But a
developer can easily address issues where the
feedback includes the exact file and line number,
with exact recommendations for fixing the
problem. In some tools, even the remediation
is an automated Git merge request.
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
But shift-left does not mean you need to
move all the guardrails to the front of the
pipeline. Instead, you need to make sure
you apply the same policies and practices
throughout the pipeline. Shift-right is also
an important aspect of DevSecOps because
not all issues can be addressed prior to a
production launch—there is often a gap
between the identification of an issue
and the time it’s ultimately fixed.
Changing security posture is an
organizational effort and DevSecOps is all
about changing the mindset. Security is a
shared responsibility between developers,
ITOps, and InfoSec teams.
8
Benefits of DevSecOps and cloud-native
Now that you understand the basic concept of DevSecOps and why you need it, let’s talk
a little about some of the benefits of DevSecOps with cloud-native technology on AWS:
Cost
savings
By using cloud-native technology, you don’t have the
overhead of running and using compute when you don’t need it.
When you don’t have servers running all the time—only when
you need them—the cost of compute is significantly reduced.
Built-in
security by
AWS
By using cloud-native services, AWS takes care of the security of
your infrastructure. You define the roles and policies and AWS helps
ensure access doesn’t extend beyond what you have defined.
Optimized
for the cloud
Storage, pipeline, build, and deployment services
leverage technologies that are built to scale.
Stringent
AWS security
processes
Standards such as PCI DSS, HIPAA, and FedRamp are met
or exceeded. You can be assured that your build servers are
secured with industry best practices.
Pay per
value
As you need more build servers, they automatically spin
up for you, build the artifact and automatically terminate.
You pay only for what you use, and the service can scale up
or down to meet your business demands.
Speed
and agility
By not focusing your time and attention on managing pipelines
or ensuring you have backups of the code repository, your teams
can focus on adding business value.
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
9
Security testing and analysis
Now that we’ve covered some of the benefits of DevSecOps and
cloud-native, let’s dive a little deeper into security testing and analysis.
Sensitive information in
source code—Secrets Analysis
Software composition
analysis (SCA)
Secrets Analysis is the process of identifying
sensitive information in your source code such
as AWS access keys, secret access keys, and
database passwords. Ideally, this type of testing
should occur prior to committing code, as it’s
often difficult to remove sensitive information
after it’s been written. There are various plugins
and tools that detect secrets on a developer’s
desktop or integrated development environment
(IDE). You might also consider a pre-commit hook
that runs prior to committing code. Most Git
repositories support pre-commit hooks and can
ensure secrets are never written to the repository.
SCA represents a class of tools that are used
to look at AWS Partner software and open-source
components used to build your application. Most
everyone uses building blocks when it comes to
software. SCAs typically create a bill of material of
the scanned software and—based on a database
—determines if there are any known issues with
the software. The power of SCAs is not simply in
tracking one or two levels deep, it’s in the ability
to go really deep with transitive dependencies.
Secret Analysis examples:
• IDE plugin
• Pre-commit hook
Just to give you an idea of how far and wide
dependencies get, as a developer you might think
you used only five external dependencies/imports,
but as you package your application you end up
with 50 libraries bundled up. These are transitive
dependencies and some of them might have known
vulnerabilities. An SCA tool will report any known
vulnerabilities and suggest possible fixes.
• Repository scanning
SCA examples:
• Snyk
• OWASP dependency tracker
• Anchore
• Contrast Security
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
10
Static application
security testing (SAST)
SAST is a close cousin of linters, which are
analysis tools that will flag issues and style
violations in your code, sort of like a spell checker.
SAST looks through custom code for common
weaknesses such as cross-site scripting, SQL
injection, and buffer overflow. Most of the SAST
tools on the market have plugins for popular
IDEs. Also, being a close cousin of linters means
that popular versions have plugins for security
testing, which turns your linter into a SAST tool.
This implementation of these tools is often
referred to as white box testing.
SAST examples:
• Snyk
• AWS CodeGuru
• SonarQube
• Contrast Security
Dynamic application
security testing (DAST)
DAST is also known as black box testing.
This class of testing is completed on releasable
or running code. The test suite knows nothing of
the internals of the running code nor does it need
to know anything about the language. These tests
look for bugs, defects, and vulnerabilities similar
to the way that a pen tester, hacker, or tool like
Metasploit would.
DAST examples:
• OWASP Zap
• Checkmarx
• Rapid7
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
11
Runtime application
self-protection (RASP)
RASP is not similar to SAST or DAST. RASP is
an approach to application security that detects
behaviors and can take action to prevent certain
kinds of incidents. RASP typically sits as an agent
to your running app and, if it notices that someone
is trying to execute SQL injection instructions on
your database, it will immediately block the attack
in real time. RASP is an important part of any
developer’s security suite because not everything
can be shifted left. Interesting things happen in
production that you just can’t replicate in a nonproduction environment. This is where RASP
comes in to help shift security right and layer
security intelligence onto running applications.
RASP examples:
• Sysdig
PENETRATION
TEST
Penetration testing
The last category of security testing and analysis
is penetration testing, also called pen testing.
Pen testing identifies security issues in your
overall system by leveraging ethical hacking,
which describes an authorized attempt to gain
unauthorized access to a computer system,
application, or data.
• Falco
• Aqua
• Contrast Security
Examples of penetration testing:
• Kali Linux
• Burp Suite
• CrowdStrike
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
12
Key considerations
So far, we’ve covered the importance of DevSecOps, the benefits, and classification of the types
of testing and analysis that is done. Now let’s cover some key considerations to keep in mind for
DevSecOps implementation.
Supply-chain Levels for Software Artifacts (SLSA) framework
We talked earlier about the external factors driving DevSecOps and the risks posed to the software
supply chain. SLSA is a set of standards and technical controls you can adopt to improve artifact
integrity and build toward completely resilient systems. It’s not a single tool, but a step-by-step
outline to prevent artifacts from being tampered with and tampered artifacts from being used
—and, at the higher levels, hardening the platforms that make up a supply chain.
SLSA is for developers, businesses, or enterprises that want a standards-based, recognizable, and
agreed-upon level of protection and compliance. The letters in the triangles on the diagram are risk
points where an unauthorized third party might gain access and compromise the DevSecOps pipeline.
SOURCE INTEGRITY
A
Developer
B
BUILD INTEGRITY
C
Source
D
Build
F
G
Package
H
Consumer
E
The need to build integrity
as well as maintain
source code integrity
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
Dependencies
13
Software bill of materials (SBOM)
You want to have assurances that fetched software artifacts are from the correct sources and haven’t
been modified. To do this, you need to keep track of all the open-source packages that are incorporated
into your software, including their license information, version of the package, and component name.
To do this, you create an SBOM for your application.
You can think of an SBOM as a recipe or a list of the components that make up a software product. SBOMs
need to show—at minimum—all top-level components and their immediate transitive dependencies.
Recommended:
Required:
• License information
• Hash of components
• Lifecycle phase
• Other component
relationships
• Supplier name
• Component name
• Version of the component
• Other unique identifiers
• Dependency relationship
• Author of SBOM data
• Timestamp
Software bill of
materials (SBOM)
Establishing artifact integrity
Establishing artifact provenance
It is important to establish trust between
software producers and consumers regardless
of whether they belong to the same or different
organizations. To do this, the producer signs the
artifact and the consumer verifies the artifact
before consuming it.
For build process integrity, you should produce
provenance documents for the entire build process.
This should include all of the various steps involved
in the build process such as compile, build, and
testing. Producers can sign that document and
consumers can verify both the signature and build
process. Provenance can be used for auditing
purposes or to wrap a policy around an application
to ensure the entire build process is not altered.
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
14
Guardrails
Guardrails are processes or practices used by Amazon developers that reduce both the occurrence
and blast radius of undesirable application behavior. At Amazon, security is “job zero,” but at the
same time we want developers to move as fast as they need and not be encumbered by policies
that can stifle their creativity. By using guardrails, security and speed can coexist.
A few examples of guardrails:
Putting limits on what resources can be provisioned, no public Amazon Simple Storage Service
(Amazon S3) buckets, or ensuring that container images cannot be pulled from repositories.
Guardrails should be defined as code because this allows them to be applied during the
development or CI/CD process.
Security
guardrails
Compliance
guardrails
Resource limit
guardrails
Authorization
guardrails
Guardrail example: Policy as code
A policy is a rule or procedure that guides all users accessing and using an organization’s
IT resources. Policies can be written or implemented using technology. Written policies don’t
scale very well as they rely on humans for implementation. On the other hand, technology-defined
policies are cumbersome to maintain as they are typically implemented in the product or application.
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
15
Open Policy Agent (OPA)
To address this problem, there is an open-source project called Open Policy Agent (OPA).
OPA is an open-source general-purpose policy engine that separates the policy decision making
from your software. What this means practically is that you can define a general policy—for example,
no containers unless they are from your repository named private.example.com—and any application
that is integrated with OPA can ask OPA if a specific action can be allowed.
Code snippet from constraint.yaml
apiVersion:
constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
name: allow-only-privateregistry
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Pod"]
parameters:
repos:
- "private.example.com"
Amazon EKS
private.example.com
Running: myapp
public.example.com
Denied: otherapp
Let’s walk through the example that is illustrated in the above graphic. Let’s say you want to allow
private registries for containers if the repository is private.example.com. To enforce this policy, you
would run OPA Gatekeeper on Kubernetes and, through an operator, Kubernetes would check OPA
each time a container is launched. If that container is not from private.example.com, Kubernetes
would reject the request as a violation of policy.
The implication here is that with OPA, you can define a policy guardrail. You can deploy those
policies through a DevOps pipeline to an OPA API server and have any number of applications
checking against them. If a policy changes, update the repository and deploy the changes,
then all applications leveraging OPA will have the latest policies.
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
16
Infrastructure as Code (IaC)
To quickly level set, IaC is a way to treat infrastructure the same way applications are treated.
Infrastructure is defined in a declarative way and stored in a source code system. There are lots of
different tools on the market to help you manage deployed infrastructure, but the difference for
cloud-native comes down to some underpinning philosophies that help you unlock speed and agility.
For starters, infrastructure should be treated as immutable. Ideally, once deployed, there should be
no attempt to alter the configuration of resources, such as deploying patches. The philosophy of
immutability in relation to resources allows for the detection of security issues. If a resource or
application changes, that could be an indication that something has been compromised.
resource “aws_db_instance” “db” {
allocated_storage = 10
…
}
resource “aws_ecs_service” “ecs”
{
name = “ecsApp”
…
ordered_placement_strategy {
type = “binpack”
…
}
}
AWS Cloud
Web servers
Database
Another best practice is that infrastructure code should be scanned through a CI/CD pipeline. There are
a number of open-source and commercial scanners that are available that can detect changes, drift, and
configuration issues. Tools from AWS Partners will scan against AWS best practices, AWS Well-Architected
Framework, and custom rules to ensure the infrastructure configuration is optimal and secure.
AWS Well-Architected
Learn, measure, and build
using architectural
best practices.
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
AWS Well-Architected helps cloud architects build secure, highperforming, resilient, and efficient infrastructure for a variety of
applications and workloads. Built around six pillars—operational
excellence, security, reliability, performance efficiency, cost
optimization, and sustainability—AWS Well-Architected provides
a consistent approach for customers and partners to evaluate
architectures and implement scalable designs.
17
Where testing and analysis fits in
• Secret detection
• Leak prevention
• Architectural guardrails
• Build compliance
• Vulnerability assessment
• Static code analysis
• Compliance of libraries used
• Software build of materials
• Secrets management
• Enabling security monitoring
• Enabling compliance checks
• Dynamic code analysis
• Vulnerability testing
• Penetration testing
• Infrastructure as Code
• Vulnerability assessment
• Penetration tests
• Compliance checks
• Behaviour anomalies
• Compliance checks
• Configuration settings
• Secrets and keys
• Secure network design
• AWS Well-Architected
Framework
In the above diagram, you’ll find a few examples of where to execute the different tests and analysis
functions that we have talked about so far. This is not meant to be a comprehensive list of every
stage and test that can be run, but depicts the more common tests.
A few examples: Secret detection can be done in the code phase, SBOM validation in the build
phase, and pen testing in the testing and monitoring phase. Another takeaway is that not all tests
and analysis are run in the test phase. Checks, tests, and analysis should be executed all throughout
the DevSecOps lifecycle.
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
18
Security of the pipeline
An often-overlooked area of app development is pipeline security. Development teams tend to focus
a lot of attention on testing applications as they progress through the pipeline but don’t focus on
security of the pipeline itself.
Code
Config
management
Build
Key
management
Encryption
Test
Deploy
Authentication
and authorization
Patching
Monitor
Alerting and
monitoring
Logging
and auditing
• Config management. How is the
configuration of the DevSecOps pipeline
secured and who has access to make changes?
• Patching. Is the application that runs the
pipeline being patched and can I validate
the integrity of that pipeline software?
• Key management. Where are keys stored
and is that location secured from leakage?
• Alerting and monitoring. Is the pipeline
being monitored and are there alerts
for the pipeline itself?
• Encryption. Is data being encrypted in motion
and at rest through the entire pipeline?
• Authentication and authorization. Are there
proper controls applied? Are there policies in
place to limit and authorize access to only
those who need it?
• Logging and auditing. Am I logging not
just for builds going through the pipeline
but also to determine which users have
logged in, who executed builds, and
who updated the configuration?
• Overall. Am I treating the DevSecOps
pipeline as if it were a production
application and service that is
being provided to customers?
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
19
Observability
DevSecOps and zero trust
Zero trust is a security strategy that uses policy
to enforce explicit trust between subjects and
resources. DevSecOps, as we’ve discussed, is
a development strategy that combines tools
and agility to continuously develop and operate
software. Both strategies are interdependent
and require balancing concerns relating to how
services, data, and infrastructure must be shared
to achieve efficiency, cost effectiveness, and risk
mitigation. The takeaway here is that you should
apply DevSecOps with the zero-trust framework to
achieve zero-trust workloads.
From an Observability standpoint, yes, you
need to collect the metrics, events, logs, and
traces (MELT) data not just of the workload,
but also of the pipeline and in the pipeline.
Additionally, you need to consider melding
security and operational tools together to
correlate information. This is because
information related to a security event for
a specific container may not be valuable if
you have no context surrounding that event.
With cloud-native, systems are distributed and
often consist of a collection of microservices, so
context is important in understanding the root
cause of any issue, including security issues.
People are often aware of Amazon
CloudWatch logs and metrics, but often
overlook AWS CloudTrail, AWS Config, and
Amazon EventBridge. Look to these services
to help achieve full Observability of the
pipeline, in the pipeline, and of your workload.
Auto-remediation
DevSecOps is not very valuable if you are simply
detecting issues but have no effective path to
remediation. A key consideration for implementing
a DevSecOps strategy is to leverage automation.
Pushing vulnerabilities to a single pane of glass
with a tool such as AWS Security Hub allows you to
trigger auto-remediation tasks.
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
20
Key takeaways for DevSecOps
Some of the most important points you’ve learned so far include:
The definition of DevSecOps, which is an
Guardrails reduce both the
extension of DevOps that adds the shift-left
and shift-right of automated security.
occurrence and blast radius of
undesirable application behavior.
The benefits of DevSecOps and cloud-native,
Which tests and analysis to use
such as cost savings, speed, agility, and security
compliance with mandates such as PCI DSS
and HIPAA.
at which point in the pipeline.
The different testing and analysis categories,
such as software composition analysis (SCA), static
application security testing (SAST), and runtime
application self-protection (RASP).
Security of the pipeline itself.
Pairing zero trust and DevSecOps
to achieve zero trust workloads.
Observability in the context
How the SLSA framework and SBOM are
both used to help ensure the integrity of the
of DevSecOps.
software supply chain.
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
21
Tools for building cloud-native
In this section, we’ll look at some of the best-fit tools you could use to achieve the tenets discussed in
the previous section. At AWS, we’ve long been believers in enabling builders to use the right tool for the
job—and when you build with AWS, you’re provided with choice. You can build using the native services
AWS provides or use AWS Marketplace to acquire third-party software offered by AWS Partners to take
away the heavy lifting and allow your development teams to focus on delivering value to customers.
Let’s take a deeper look at two key components at this stage of your cloud-native journey: a tool for
implementing shift-left security—scanning in and of the pipeline, a way to set up policies and guardrails,
and an Observability solution.
Adding development capabilities with AWS Marketplace
Find, try, and acquire tools across the DevOps landscape for building cloud-native applications
Plan
Test
Build
Secure
Release
Operate
Amazon
CloudWatch
Amazon
Kinesis
Amazon
EventBridge
Amazon
EKS
Amazon
DynamoDB
AWS CodeCommit
AWS Device
Farm
AWS Cloud9
AWS
CodeDeploy
CodeCatalyst
AWS
Lambd
a
Sample AWS and AWS Marketplace solutions
3,000+ vendors | 13,000+ products
AWS Marketplace is a cloud marketplace that makes it easy to find, try, and acquire the tools you need
to build cloud-native. More than 13,000 products from over 3,000 Independent Software Vendors are
listed in AWS Marketplace—many of which you can try for free and, if you decide to use, will be billed
through your AWS account.
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
22
For our example architecture, we’ll use Snyk for code scanning, Sysdig for runtime analysis, and AWS
for all the other components. The diagram below is an example of a DevSecOps cloud-native architecture.
It includes your CI/CD pipeline, scanning and analysis, observability, compliance, and runtime compute
environment. Besides AWS cloud-native services, you also see Snyk, OWASP, and Sysdig.
AWS Cloud
Observability by
Amazon CloudWatch
CI/CD Pipeline
Commit
Source
repo
Build
Compute
Test
Deploy
Monitor
Feedback
Workload
Amazon EKS
Scanning and analysis
Amazon SNS
Amazon ECS
Amazon Inspector
Amazon CodeGuru
Secrets
AWS Secrets Manager
Parameter store
Git repo
Amazon S3
Observability
Amazon CloudWatch
AWS X-Ray
AWS Lambda
Artifact and code repository
AWS CodeArtifact
Amazon ECR
Compliance
AWS Distro for
OpenTelemetry
AWS IAM
AWS CloudTrail
AWS Config
AWS KMS
AWS Security Hub
Snyk and Sysdig are tools in AWS Marketplace that we will cover in depth a little later. OWASP ZAP is an
open-source tool from OWASP Foundation that helps you run DAST analysis, which we’ve learned is also
called black box testing.
A brief overview of Snyk and Sysdig
Snyk is a developer-friendly
security platform for securing
code, open-source dependencies,
containers, and IaC.
Sysdig provides a security and visibility solution designed for
containers, Kubernetes, and cloud. The company pioneered cloudnative runtime threat detection and response by creating Falco as
an open-source standardized tool. Sysdig’s SaaS platform for cloudnative security presents a unified view of risk—from vulnerabilities
to misconfigurations to runtime threats detection and compliance.
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
23
Now let’s focus on the security scanning and analysis aspect of our
cloud-native DevSecOps example architecture. The below diagram
illustrates that the architecture has pipeline stages, security and
scanning, and, at the bottom, the artifact and code repository.
Shift-Left and Shift-Right
security analysis
AWS Cloud
CI/CD Pipeline
Commit
Source
repo
Build
Test
Deploy
Monitor
Feedback
Scanning and analysis
Amazon SNS
Amazon Inspector
Amazon CodeGuru
Artifact and code repository
Git repo
The CI/CD pipeline above
represents the typical
five stages:
Amazon S3
AWS CodeArtifact
Amazon ECR
1. Source Repository. Where you continuously push your code.
2. Build. Where you compile source code and build artifacts.
3. Test. Where you run various tests such as integration tests,
security tests, and others.
4. Deploy. Where you deploy your artifacts.
5. Monitor. Where you continuously monitor and observe
your workloads.
You can leverage AWS CodeSuite—which includes AWS CodePipeline,
AWS CodeBuild, AWS CodeCommit, and AWS CodeDeploy—to build
these stages, or use other tools in AWS Marketplace such as GitLab,
CloudBees, or CircleCI.
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
24
AWS Cloud
CI/CD Pipeline
Commit
Source
repo
Build
Test
Deploy
Monitor
Feedback
Scanning and analysis
Amazon SNS
Amazon Inspector
Amazon CodeGuru
Artifact and code repository
Git repo
The scanning and analysis
section above shows various
services and AWS and AWS
Partner tools. Let’s start
with AWS services and
how they can help scan
your applications:
Amazon S3
AWS CodeArtifact
Amazon ECR
1. The Git repository can be any Git-based repository,
such as AWS CodeCommit or Git, GitLab, or BitBucket
2. Amazon S3 provides an object store where you can store
any objects, including code artifacts, binaries, and more
3. AWS CodeArtifact is an artifact repository where you can
securely store, publish, and share software packages
4. Amazon Elastic Container Registry (Amazon ECR) is a
container registry where you can store container images
and OCI (Open Container Initiative)-compatible artifacts
Let’s move to talking about how you can leverage Amazon Inspector
and Amazon CodeGuru in your CI/CD pipeline to scan your applications.
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
25
Key features:
Amazon
Inspector
Amazon Inspector is an
automated vulnerability
management service that
continually scans your
Amazon Elastic Compute
Cloud (Amazon EC2) instances
and container workloads for
software vulnerabilities and
unintended network exposure.
Amazon ECR
1. Identifies vulnerabilities in both OS packages and programming
language packages such as Python, Java, Ruby, Golang, and others
2. If you enable enhanced scanning in Amazon ECR, it integrates
with Amazon Inspector to provide automated, nearly continuous
scanning of your repositories
3. Amazon ECR and Amazon Inspector can also share data with other
AWS services like AWS Security Hub and Amazon EventBridge
The takeaway here is that If you are running applications on Amazon
EC2 instances and also running container workloads on AWS, Amazon
Inspector can be used as a single solution to scan both workloads.
A fully-managed container registry offering high-performance hosting
so you can reliably deploy application images and artifacts anywhere.
Key features:
Amazon
CodeGuru
Amazon CodeGuru is
another code-scanning
tool that you can leverage
in your DevSecOps pipeline
to scan Java and Python
applications.
1. Amazon CodeGuru Reviewer uses machine learning (ML) and
automated reasoning to identify critical issues, security vulnerabilities,
and hard-to-find bugs during application development and provides
recommendations to improve code quality
2. It is based on years of Amazon internal code review experience
and helps you reduce noise
3. You can associate your existing code repositories on GitHub,
GitHub Enterprise, Bitbucket, or AWS CodeCommit in the Amazon
CodeGuru console
4. Amazon CodeGuru Profiler helps developers find an application’s
most expensive lines of code by helping them understand the runtime
behavior of their applications. You can instrument your applications and
improve the performance by identifying high-CPU-consuming parts
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
26
Shift-left security analysis and Snyk
Snyk’s approach
As mentioned earlier, Snyk is a developer-friendly
platform that can help you with various—if not all—
aspects of shift-left security, including secrets analysis,
SCA, and SAST. Snyk can be integrated with AWS
services, as well as external Git repositories such as
GitHub and GitLab.
Empowered developers
Snyk helps find and fix issues in your first-party custom
code, third-party open-source code, containers, and IaC.
Algorithm-based fix technology
with automation processes to
implement fix recommendations
as part of development.
Snyk’s remediation capabilities mean that the tool
doesn’t just tell developers what vulnerabilities exist, it
tells them what to fix and where to fix it. This can be
done in the Snyk UI, programmatically via API, or by outof-the-box integrations. As we talked about earlier,
underpinning the platform is the Snyk Intel Vulnerability
database, which provides customers with comprehensive,
accurate, and timely information.
Developer-first tools make
it easy for developers to
implement security.
Automated fixes
Security expertise
Powered by Snyk Security
intelligence, supplemented by
Snyk’s own security research
team, and augmented by the
Snyk Code AI engine.
Try it in AWS Marketplace ›
Start a hands-on lab ›
Snyk and AWS
If you are using AWS CI/CD pipeline, you can natively integrate
Snyk with AWS CodePipeline with only a few clicks or IaC.
AWS CodePipeline is a fully managed continuous delivery
service that helps you automate your release pipelines.
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
27
Snyk vulnerability
assessments
Example output from a Snyk vulnerability assessment
Snyk helps you identify
vulnerabilities and provides
context by detailing every
aspect of the vulnerability—
how mature it is, its score as
pertains to importance, trends,
and more. Snyk also helps you
by offering recommendations
for fixing the vulnerabilities
it identifies.
Snyk dependency
management
Earlier we talked about how critical it is to be
aware of your dependencies and the possible
vulnerabilities of those dependencies. Here is
an example dependency graph of root-level
and transient dependencies and their known
vulnerabilities.
We also talked about producing SBOMs with
these details to consume in your DevSecOps
automation and to provide transparency
between the software producer and consumer.
Snyk provides additional tools to produce
SBOMs from this information in formats such
as Software Package Data Exchange (SPDX).
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
28
Snyk single-click pull request
As illustrated here, Snyk provides an
opportunity to submit a single-click pull
request for some known vulnerabilities. The
Snyk platform shows a “Fix vulnerabilities”
option for these that you can enable to
automatically submit a pull request to your
code repository.
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
29
Runtime analysis
While Snyk can help with aspects of shift-left security such as
container image scanning, for the purpose of our example solution,
we’ll use Sysdig’s runtime analysis capabilities. Sysdig will have an
agent running besides your container image to inspect all the system
calls and Kubernetes activity and to identify any vulnerabilities at runtime.
Try it in AWS Marketplace ›
Container security at runtime based on Falco
As mentioned previously, Sysdig was initially created as an open-source project called Falco and was later
extended as a SaaS platform called Sysdig Secure. Sysdig Secure helps you with additional capabilities:
• Sending different types of security data to third-party security
information and event management (SIEM) platforms and logging
tools, such as Splunk, Elastic Stack, Qradar, Arcsight, LogDNA
Open-source Falco
Sysdig Secure
• Alert on malicious events
• DIY responses
• Sending alert notifications to
services such as Amazon SNS,
Slack, PagerDuty, and others
• Detect events based on policies
• Alert on malicious activity
• Automate remediation
• K8s native prevention
• SIEM forwarding
• Alerting integrations
Secure
K8s audit
logs
Syscall
data
K8s audit
logs
Syscall
data
eBPF Probe
eBPF Probe
Kernel
Kernel
Sysdig Secure
Devops Platform
Insights across cloud layers
With Sysdig, you gain insights across different aspects of your AWS Cloud—Amazon EC2 instances,
containers, orchestration, cloud services, and permissions. The goal here is to help you detect the
“bad things” that might take place in your environment. To ensure you catch all issues, Sysdig Secure
alert criteria and detections are highly customizable. With this scope of insight, you get a consolidated
view of risk across your workloads and infrastructure.
In addition, Sysdig does a really great job of capturing activity details—this is key for things like
compliance, where you want to keep an audit trail of all the things happening within your systems.
Plus, the depth of data captured helps you better respond to incidents.
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
30
Snyk and Sysdig: Complete container security
Together, Snyk and Sysdig help you reduce vulnerability overload, ship Kubernetes apps faster,
and secure production. The below graphic illustrates the capabilities and features that the two
solutions provide to enhance protection of your application development pipeline.
Security
Platform & Cloud Ops
Developers
Code Security
Runtime Security
Image Security
Network Security
Incident Response & Forensics
Security Monitoring
& Analytics
Infra & App
Monitoring
Kubernetes & Cloud Platform Security
AWS Cloud
Snyk and Sysdig combine to add layers of protection to your AWS Cloud workloads
Snyk helps you with shift-left security, where
developers can integrate Snyk into their IDEs and
run scans against their code repositories to identify
security vulnerabilities in first- and third-party code.
Sysdig Secure helps you with shift-right security:
Runtime analysis and monitoring and analytics for
your production workloads. Sysdig also has a direct
integration with Amazon Inspector, which enables you
to report all your findings and manage automation.
Sysdig can also send its events to the Snyk platform.
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
The bottom layer in the graphic is AWS, where
your DevSecOps pipeline is running. This way,
you can use AWS expertise and security best
practices to run your cloud-native DevSecOps
pipeline control plane and deploy to various
workloads. AWS will help you orchestrate and
manage the pipeline, aggregate and remediate
your vulnerability findings, and meet your most
strict security and compliance requirements.
You can build your DevSecOps pipeline on
AWS and integrate security partners Snyk and
Sysdig into the pipeline to build a complete
DevSecOps platform.
31
Prioritizing vulnerabilities with Snyk and Sysdig
When most people talk about container security, they’re primarily considering their production environment
and how they’re going to protect the apps in motion. This makes sense because production is where bad
things usually happen since that’s where the apps are actually running.
But containers are not solely a runtime concern. In fact, containers and Kubernetes are where Dev and Ops
meet, from a technical standpoint. And as any developer would tell you, if you put garbage into the system,
you can only expect to get garbage out.
Faster time
to deliver secure
containers / code
to production
Snyk Container
Build securely from the start
Protect against runtime threats
•
Addresses developer pain
points—too many CVEs!
•
Provides container security
from code-to-cloud.
•
Eliminate the majority of
vulnerability alerts!
Runtime data sent to Snyk
gives devs insight into what
to fix to address real risk.
The joint power of
Snyk and Sysdig on AWS
945
43
3
vulns
vulns
vulns
Initial scan
by Snyk
After base image
recommendation
from Snyk
After filtering by
running packages
seen by Sysdig
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
Up to 95%
reduction!
To illustrate the point from another
perspective, what developers are often
faced with is a haystack of issues. Snyk does
a great job of reporting what those are—
and will recommend base image upgrades
to eliminate a lot of already-fixed issues.
But now, combine the runtime insights from
Sysdig and you’re talking about a significant
reduction in what actually requires a
developer’s attention.
32
AWS Security Hub
AWS Security Hub is a cloud security posture management service that performs security best
practice checks, aggregates alerts, and enables automated remediation. It continuously aggregates
and prioritizes findings from various AWS services including Amazon GuardDuty, Amazon Inspector,
AWS Config, Amazon Macie, as well as AWS Partner tools such as Sysdig.
AWS Cloud
CI/CD Pipeline
Commit
Source
repo
Build
Test
Feedback
Compute
Deploy
Monitor
Workload
Amazon EKS
Scanning and analysis
Amazon SNS
Amazon ECS
Amazon Inspector
Amazon CodeGuru
AWS Lambda
Feedback to development and security teams
AWS Security Hub
AWS Security Hub flow example
AWS Security Hub key features:
• Provides a single-pane-of-glass view to manage issues
and threat detection
• Integrates with many AWS and AWS Partner tools
• Checks for security controls for standards such as CIS
AWS foundations, AWS best practices, and PCI DSS
• Triggers auto remediations using Amazon EventBridge
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
33
The below screen capture illustrates how AWS Security Hub can
aggregate all your security findings from various tools. The example
shows vulnerability findings from various tools for SAST, DAST, and
even from Amazon ECR. You can drill down into each of these for
details about their vulnerabilities.
Secrets
in code
Observability
and DevSecOps
For the Observability
aspect of our cloud-native
DevSecOps architecture,
you can leverage AWS
managed services such as
Amazon CloudWatch, AWS
X-Ray, and AWS Distro for
Open Telemetry (ADOT).
We talked about how you should never hard-code sensitive information into your code.
But where can you store that information and request it securely when you absolutely need it?
On AWS you can use services like AWS Secrets Manager and AWS Systems Manager Parameter
Store to store that information, which you can then retrieve while executing your pipeline.
# Runtime settings
import boto3
number_of_items = 300
…
root_file = index.html
# Parameter Store
db_connection =
db.example.com
Parameter Store
sns_queue =
sns.example.com
ssm.get_parameter(Name=‘/
Prod/db_connection’)
…
# Secrets Manager
get_secret_value(
# Database password
SecretId=db_password)
db_password = supersecret
AWS Secrets Manager
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
34
Recap: Shift-left security architecture
Building DevSecOps in a cloud-native way significantly reduces the overhead for developer, security,
and operations teams. AWS provides a broad spectrum of cloud-native services and partner tools to
help organizations build DevSecOps into their app development practice, as seen in the below diagram.
AWS Cloud
Observability by
Amazon CloudWatch
CI/CD pipeline
Commit
Source
repo
Build
Compute
Test
Deploy
Monitor
Feedback
Workload
Amazon EKS
Scanning and analysis
Amazon SNS
Amazon ECS
Amazon Inspector
Amazon CodeGuru
Secrets
AWS Secrets Manager
Parameter store
Git repo
Amazon S3
Observability
Amazon CloudWatch
AWS X-Ray
AWS Lambda
Artifact and code repository
AWS CodeArtifact
Amazon ECR
Compliance
AWS Distro for
OpenTelemetry
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
AWS IAM
AWS CloudTrail
AWS Config
AWS KMS
AWS Security Hub
35
Continue your journey with AWS Marketplace
Snyk and Sysdig can be used together along with AWS to establish a well-engineered approach to DevSecOps.
Gaining these capabilities can provide a strong foundation for continuing to advance through your cloud-native
journey. You can explore these and other DevOps and DevSecOps-focused tools in AWS Marketplace.
To get started, visit: https://aws.amazon.com/marketplace/solutions/devops
AWS Marketplace
Over 13,000 products from 3,000+ vendors:
Third-party research has found that customers
using AWS Marketplace are experiencing an
average time savings of 49 percent when needing
to find, buy, and deploy a third-party solution.
And some of the highest-rated benefits of using
AWS Marketplace are identified as:
Time to value
Cloud readiness
of the solution
Return on
Investment
Part of the reason for this is that AWS
Marketplace is supported by a team of solution
architects, security experts, product specialists,
and other experts to help you connect with the
software and resources you need to succeed
with your applications running on AWS.
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
Buy through AWS Billing using
flexible purchasing options:
• Free trial
• Pay-as-you-go
• Hourly | Monthly | Annual | Multi-Year
• Bring your own license (BYOL)
• Seller private offers
• Channel Partner private offers
Deploy with multiple deployment options:
• AWS Control Tower
• AWS Service Catalog
• AWS CloudFormation (Infrastructure as Code)
• Software as a Service (SaaS)
• Amazon Machine Image (AMI)
• Amazon Elastic Container Service (ECS)
• Amazon Elastic Kubernetes Service (EKS)
36
Get started today
Visit aws.amazon.com/marketplace to find, try and buy
software with flexible pricing and multiple deployment
options to support your use case.
https://aws.amazon.com/marketplace/solutions/devops
Authors:
James Bland
Global Tech Lead for DevOps, AWS
Aditya Muppavarapu
Global Segment Leader for DevOps, AWS
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
37