• The first Hub for Developers

The first Hub for Developers

DevOps Overview
CI/CD/CD
+
DevSecOps
Regeneration DecSecOps Academy
 DevSecOps Academy
An intensive hands-on training program for both basic and advanced principles in

• DevSecOps Processes & Principles • Security & Encryption

• Infrastructure & Configuration • Networking
Management
• Containers & Orchestration
• Continuous Pipelines
• Monitoring
• Cloud Computing Building Blocks
• Bridging the gap between Development and
• AWS & Azure Basics Operations departments
• Identity & Access Management • Applying the best IT solutions
• High Availability and Scalability aspects • Speeding up software release processes
• Storage Services & Databases • Aiming at continuous improvement

3
 DevSecOps Academy
• Duration: 6 weeks (27/4 to 3/6)
• Contact time: 80 hours
• Team-based project
• Teams and objectives will be announced next
• Primary teaching tools
• Microsoft Teams
• Primary tech tools
• AWS, free account
• Azure, free account

4
 DevSecOps Academy Course Content
• DevSecOps Aspects, Processes and Principles
• Infrastructure & Configuration Management
• Continuous Pipelines
• Cloud Computing Building Blocks
• AWS & Azure Basics
• Identity & Access Management
• High Availability and Scalability aspects
• Storage Services & Databases
• Security & Encryption
• Networking
• Containers & Orchestration
• Monitoring

5
Running Development and Operations
 What is the issue in software systems today?
• The Problem:
• IT needs to deploy new features
• It also needs to keep systems up and running
• This is a core conflict

• The Answer:
• Practices, tools, culture that aim at resolving this
• Enable ops and dev engineers to participate together
• For entire service life cycle, from design to production
• This is called DevOps
7
 Nice-to-have
• Early and continuous delivery of valuable software
• Rapid feedback
• Empirical decision-making
• Satisfied customers
• Business people and technical people working together
• Measurement-based forecasting
• Harnessing change for competitive advantage
• Emergent design
• Technical excellence
• Empowered self-organizing teams
• Personal safety
• Sustainable pace
• High trust environments
• Lean processes
• Continuous improvement

8
 Nice-to-have
• Can we really achieve all of the above?
• This is the claim of DevOps
• Seen it before?
• How close are we to it?

9
 From Development to Production
• Developing a feature on a local machine is the Dev stage
• QA confirmation that the feature works as expected is Test
• Releasing the feature to the customer is Prod

• There may exist intermediate steps (and alternative terminology)

• SIT
• UAT
• Pre-Prod
• Stage
• Live

10
 From Development to Production

11
 A Real Life Story
• Pushes changes to production everyday
• 1 billion+ active users at any point in time
• 13+ Million Lines of Code
• 15.000+ Commits per month
• Most changes have impact across platforms
• Changes from submission to production gets pushed out in less than 60
minutes
• Updates to production made at full live capacity – No down time

12
 A Real Life Story
• 15.000+ developers in 40+ offices
• 4.000+ projects under active development
• 5.500+ submissions per day on average
• Development on one branch – Submissions on Head
• 20+ sustained code changes per minute with 60+ peaks
• 50% of code changes monthly
• 75+ million test cases run per day

13
 Dev and Ops drifting away
As computers became more complex, dev and ops became
necessarily specialized:
• Accelerating pace of technology
• Increased demand for turning around new features
• Huge amounts of data and number of calculations
• More and more specialized tools
• Increasingly abstract architectures and design patterns

12
14
 New ideas show up
• What would happen if we built tools to automate as much of
operations as possible?
• What would happen if we built virtual infrastructures than can
change on-the-spot?
• How can dev help system stability?
• How can ops help accelerate feature delivery?

15
 More radical new ideas show up
• What would happen if we extended agile development to
operations?
• What would happen if we built cross-functional teams around
common ground of operations?
• What would happen if we had teams of people with experience
on both dev and ops?

16
 Make Developers work with Operations
• Ops can anticipate how new functionality will affect production
• Dev can respond to bugs and deployment failures quickly
• Dev and Ops can work together to permanently remove root
causes of bugs and failures
• Ops trusts dev will provide good code
• Dev trusts ops will put code in prod quickly
• Trust but verify!

17
 How can we make Dev-Ops collaborate?
• Create feedback loops between creators and operators
• Expose real-time metrics from ops enabling dev to learn from
the system running under real world conditions
• Expose real-time metrics from dev enabling ops to anticipate
production needs and provide early input
• Cross-functional teams collaborate to deliver whole working
systems including all infrastructure, software code, and
configurations

18
 Combining Dev and Ops to DevOps
What is the ultimate goal?
• Create a set up where a single team performs Dev and Ops

What does it require?

• Teams with broad competences
• Automation tools
• Organizational and technical metrics
• New culture

19
 A note on change culture
• When coming across a new working culture, a common comment is
this:

• “We are not like the others”

• “You are saying this but you don’t know how we do things”
• “It will never work here”
• “This does not make sense”

• These may be valid objections, but they refer to how things are now
• But things do change at a continuous pace
20
 DevOps
(On the way to DevSecOps)
 What is DevOps?
DevOps is the philosophy of unifying Development (Dev) and IT Operations
(Ops) at the culture, practice, and tool levels, to achieve accelerated and
more frequent deployment of changes to Production

22
 What is DevOps?
• DevOps breaks down the barriers between Dev and Ops teams to shorten
the time it takes to build, test, and release software of high quality

• Culture: behavior, teamwork, responsibility/accountability, trust...

• Practice: policy, roles, processes/procedures, metrics/reporting...
• Tools: shared skills, toolmaking for each other, common technology
platforms...

23
 What is DevOps?
• A DevOps approach is one of many techniques used to execute
IT projects that meet business needs
• It can coexist with
• Traditional methodologies like Waterfall
• Agile software development
• IT service management frameworks, such as ITIL (Information
Technology Infrastructure Library)
• Project management directives, such as Lean and Six Sigma
• Other strategies

24
 What is not DevOps?
• DevOps is not simply combining Development & Operations teams
• DevOps is not a separate team
• DevOps is not a tool
• DevOps is not a one-size-fits-all strategy
• DevOps is not just automation

25
 DevOps Main Objectives
• Installation of server hardware and OS
• Configuration of servers, networks, storage, etc…
• Monitoring of servers
• Continuous Integration
• Continuous Delivery
• Respond to outages
• IT security
• Change control
• Backup and disaster recovery planning
• Automating and Orchestrating entire process
26
 How does DevOps work?
• DevOps is a methodology
• Used to improve work throughout the software development lifecycle
• A DevOps process is an infinite loop, comprising the following steps:
• Plan
• Code
• Build
• Test
• Release
• Deploy
• Operate
• Monitor
• Plan -- through feedback -- which resets the loop

27
 How does DevOps work?
Ideally in DevOps

• A team writes software that perfectly meets user requirements

• The team deploys without any wasted time
• The software runs optimally on the first try

Organizations use a combination of culture and technology to

pursue this goal

28
 How does DevOps work?
• To align software to expectations, developers and stakeholders
communicate about the project
• Developers work on small updates that go live independently of
each other
• To avoid wait times, teams use CI/CD pipelines to move code
from one step of development and deployment to another
• Teams review changes immediately and can enforce policies to
ensure releases meet standards

29
 DevOps dissected
• From automated code preparation to a CI/CD pipeline, orchestration, monitoring and
feedback -- here's how every piece contributes to successful a DevOps methodology.

DevOps Practice Description Benefits

Build Automation Automated code preparation for • Fast, consistent, repeatable
deployment to live environment. • Portable
The tool used is tied to the • More reliable than a manual build
programming language selected.
Continuous Frequent code merging and unit • Early bug detection
Integration (CI) testing • Maintains code in a state that can be
deployed to production with minimal
effort
• Encourages use of modular code
Continuous Deployment of small code • Faster time to market
Deployment (CD) changes to production in a routine • Dependable deployment process
and frequent process • Reliable rollbacks

30
 DevOps dissected
DevOps Practice Description Benefits

Infrastructure as Manages and provisions IT • Consistent resource creation and

Code infrastructure through code and management
automation • Reusable
• Self-documented infrastructure
• Simplified complex infrastructure (e.g., DB,
authentication, application servers)
Configuration Manages and changes state of • Saves time
Management infrastructure in constant and • Provides documentation on infrastructure
maintainable ways • Maintainability with system changes
• Minimizes configuration drift, especially in
large server environments
Orchestration Automation that support • Saves time
processes and workflows (e.g., • Scalability
resource provisioning) • Stability

31
 DevOps dissected
DevOps Practice Description Benefits
Monitoring Collects and presents data about • Consistent resource creation and
the performance and stability of management
services and infrastructure while • Reusable
detecting problems at the same • Self-documented infrastructure
time • Simplified complex infrastructure (e.g., DB,
authentication, application servers)
Microservices Service architecture that breaks • Modularity reduces complexity
an application into a collection of • Flexibility in choice of technology for each
small, loosely collected services service
• Cost-effective when used with
containerization

32
 What problems does DevOps solve?
• Each company faces its own challenges, but common problems include:
• Releases take too long
• Software does not meet expectations
• IT limits business growth
• A DevOps-enabled project has
• No wait times
• No manual processes
• No lengthy reviews
• DevOps moves from requirements to live software faster
• Shorter cycle times can keep requirements from shifting so that the
product delivers what customers want

33
 What problems does DevOps solve?
• DevOps solves communication and priority problems between
IT specializations
• A traditional structure narrows development and operations
teams in silos
• This means developers are satisfied when their code delivers
functionality
• If the release breaks in production, it is up to the operations team to
make the fixes
• DevOps ensures all teams are part of the same delivery team

34
 What problems does DevOps solve?

35
 What problems does DevOps solve?
With a DevOps culture, business has a major competitive advantage

• Developers won't have the "It worked on my machine" response when a

problem arises
• Changes rolled out to production are small and reversible
• The whole team understands the changes, so incident management is
greatly simplified
• From idea to live software the steps are fast and companies can capitalize
on market opportunities

36
DevOps Toolsets
 DevOps Tools – Code Repositories
• Version-controlled source code repositories enable multiple developers to
work on the same project
• Developers save and retrieve shared code
• These tools keep a record of all modifications made to the source code
• We can return to any previous version of code and see what has changed
• In an automated environment, a code change automatically triggers some
next step(s)
• E.g. static code analysis or tests
• Tools for source code management include Git and Git host servers
• E.g. Bitbucket, Gitlab, GitHub

38
 DevOps Tools – Artifact Repositories
• An artifact in software is a tangible output of some process
• Source code is compiled into an artifact for testing
• Artifact repositories enable version-controlled outputs
• Artifact management keeps up with best practices of source
code management
• E.g. JFrog Artifactory, Nexus Repository
• Code and code artifacts are best to be handled independently

39
 DevOps Tools – CI/CD pipeline engines
• CI/CD enables DevOps teams to frequently validate and deliver
applications to the end user through automation during the
development lifecycle
• The continuous integration tool initializes processes so that
developers can create, test and validate code in a shared repository
as often as needed without manual work
• Continuous delivery extends these automatic steps through
production-level tests and configuration setups for release
management
• Continuous deployment goes a step further, invoking tests,
configuration and provisioning, as well as monitoring and potential
rollback capabilities
• Common tools for CI, CD or both include Jenkins, Bamboo,
TeamCity, GitLab, Travis and CircleCI

40
 DevOps Tools – CI/CD pipeline engines

41
 DevOps Tools – Containers
• Containers are isolated runtimes for software on a shared OS
• They provide abstraction that enables code to work the same
on different underlying infrastructure
• from development to testing and staging, and then to production
• Docker is the most well-known containerization software
• Microsoft offers specific Windows container options
• Container orchestrators deploy, scale and maintain containers
automatically
• E.g. Kubernetes, Red Hat OpenShift, Amazon Elastic Kubernetes
Service

42
 DevOps Tools – Containers

43
 DevOps Tools – Configuration management
• Configuration management systems enable IT to provision and
configure software, middleware and infrastructure based on a
script or template
• The DevOps team can set up deployment environments for
software code releases and enforce policies on servers,
containers and VMs through a configuration management tool
• Changes to the deployment environment can be version-
controlled and tested, so DevOps teams can manage
infrastructure as code
• Configuration management tools include Ansible, Puppet, Chef,
Terraform

44
 DevOps Tools – Cloud environments
• Moving operations to cloud infrastructure can automate its
deployment, scaling and other management tasks
• Amazon AWS and Microsoft Azure are among the most used
cloud providers
• Many cloud vendors also offer DevOps support with CI/CD
services

45
 DevOps Tools – Monitoring
• Monitoring tools enable DevOps professionals to observe the
performance and security of code releases on systems,
networks and infrastructure
• They can combine monitoring with analytics tools that provide
operational intelligence
• DevOps teams use these tools together to analyze how
changes to code affect the overall environment
• Choices are wide-ranging, and include ELK, New Relic One,
Dynatrace, Prometheus, Datadog and Splunk

46
 DevOps Tools – Cloud-based DevOps pipelines
• Cloud providers offer native DevOps tool sets to use with
workloads on their platforms
• An incomplete list includes AWS CodePipeline and
CloudFormation, Azure DevOps and Pipelines, and Google
Cloud Deployment Manager
• Cloud adopters have the option to use these pre-integrated
services or run third-party tools
• For example, an organization can use HashiCorp Terraform or
CloudFormation to make infrastructure-as-code templates for
its AWS workloads

47
 DevOps Tools – As-a-service models
• DevOps as a service is a delivery model for a set of tools that
facilitates collaboration between an organization's software
development team and the IT operations team
• In this delivery model, the provider assembles a suite of tools
and handles the integrations to seamlessly cover the overall
process of code creation, delivery and maintenance

48
 DevOps Skills
• DevOps links to collaborative IT culture, rather than a strictly
defined job description or skill set
• The area is broad and DevOps positions suit IT generalists
better than specialists
• Professionals can enter the position from a variety of
backgrounds
• Many DevOps job listings call for knowledge related to
containers, the cloud, CI/CD, as well as soft skills
• A DevOps engineer aims at constant delivery for business
support, including solving organizational problems

49
 DevOps Skills
• Common titles often found in DevOps organizations include the following:
• Infrastructure Developer
• Site Reliability Engineer
• Build and Release Engineer
• Full-stack Developer
• Automation Specialist
• CI/CD Platform Engineer
• Most entry-level DevOps jobs require a degree in computer science or a
related field that covers coding, QA testing and IT infrastructure
components
• Higher-level positions may require experience/degrees in systems
architecture and software design
• There is no standard industry-wide DevOps certification, but various
companies offer certifications related to their DevOps approaches

50
Building DevOps Processes
 Software releases can take a long time
• Clean code with Uncle Bob
• https://www.youtube.com/watch?v=Qjywrq2gM8o, @27:15
• “I worked for a company once and the minimum estimate for everything, didn’t matter what it was,
was six months”
• “To change the name of one menu item, it was six months, and there was a good reason for this”
• “Changing the name of a menu was liable to break something somewhere, because we had other
systems that read our menus”

52
 Systems to automate software deployment

53
 Systems to automate software deployment
• Version Control: Ensures you’re working on the right version of something
• Requirements System: Houses project requirements in a prioritized list
• Build System: Software tools designed to automate the process of program compilation
to create a deployable package
• Test system: orchestrated set of tests, both manual and automated that ensure the
functionality and accuracy of code
• Code Review System: Ensures that code complies with standards and identifies low
level bugs and coding errors; Identifies design and requirements compliance
• Issue Tracking System: Collects issues throughout the cycle of the project and track
them through completion
• Documentation system: Repository of system information throughout the lifecycle
• Deploy System: Installs and configures the package created by the build system into
appropriate environments
• Monitoring System: Collects current-state data to determine health of all environments
• Communication System: Method for conveying information between systems

54
 The case of Capital One

55
 The case of Capital One

56
 The case of Capital One

57
 The case of Capital One

58
 The case of
Starlink

59
 The case of
Starlink

60
 The case of
Starlink

61
 The DevOps toolchain steps
• Plan - collecting requirements, definition of objectives
• Code - code development, source code management, code merging
• Build - continuous integration, build status
• Test - testing tools, testing suites
• Package - artifact repository, application pre-deployment staging
• Release - change management, release approvals, release
automation
• Configure - infrastructure as code, configuration, management
• Deploy - deployment pipelines, deployment tools
• Monitor - applications performance monitoring, end-user experience
62
 Using pipelines to automate releases
• A Pipeline is a chain of tasks that can be automated
• Integration tools use pipelines to perform tasks repetitively and
continuously
• There are no fixed rules as to how a pipeline should be structured
• Four common stages are: Develop, Build, Test, Deploy

63
 Pipeline stages

64
 Testing stage

65
 DevOps Pipeline, How to Create one?
Set Up a Build Server (CI/CD)
• Once the code is tracked, the next step is to
test it
• Running tests against the code helps prevent
errors, bugs, or typos from being deployed to
users
• Two of the most popular solutions for creating
builds are Jenkins and Travis-CI
• Jenkins is completely free and open-source
• Travis-CI is a hosted solution free for open-
source projects

66
 DevOps Pipeline, How to Create one?
Set up a source control environment
• Before start building and deploying code,
decide where to store the source code
• GitHub is probably the most popular code-
hosting website
• BitBucket and GitLab are powerful
alternatives

67
 DevOps tools - Git
• Git: manage and share code among developers and tools

68
 DevOps tools - Maven
• Maven: manage code dependencies and automate software
building

69
 DevOps Pipeline, How to Create one?
Run automated tests
• Most common are
• unit tests
• integration tests
• functional tests
• Typically tests run from shortest first
• If the build passes the testing phase, the
code is ready to be deployed to production
• Or deploy to a production-like environment
for further evaluation

70
 DevOps Pipeline, How to Create one?
Deploy to Production
• First we need to set up the server
infrastructure
• Might deploy to dedicated servers or to bare
metal cloud servers
• Deployment can be manual or automatic
• Automation can speed up the process, but
requires confidence that bad code will not
end up in production

71
 DevOps tools - Jenkins
• Jenkins: automate building, testing, and deploying, continuous
integration/delivery/deployment

72
 DevOps tools - Docker
• Docker: create, deploy, and run applications in a customized
environment hosted in any machine

73
 A plain but effective DevOps toolchain

74
 A more advanced DevOps toolchain

75
 DevOps tools per lifecycle stage

76
 DevOps Tool Example - Ansible
• Ansible is an automation engine that automates
• cloud provisioning
• configuration management
• application deployment
• intra-service orchestration
• It is open-source software
• Runs on many Unix-like systems
• Can configure Unix-like systems and Microsoft Windows
• Imperative, mutable

77
 DevOps Tool Example - Ansible

78
 DevOps Tool Example - Terraform
• Terraform is an open-source tool for building, changing, and
versioning infrastructure
• Configuration files describe to Terraform the components
needed to run from applications to datacenters
• Terraform generates an execution plan describing what it will do
to reach the desired state
• As the configuration changes, Terraform determines what
changed and creates incremental execution plans
• Infrastructure as Code: infrastructure is described using a high-
level configuration syntax
• Declarative, immutable

79
 DevOps Tool Example - Terraform

80
 DevOps Tool Example - Heroku
• Heroku is a cloud platform as a service
• Review, stage and release to production

81
 DevOps Tool Example - Heroku

82
 Tool fatigue
• As working becomes increasingly automated and decentralized,
it is common to find numerous tools with overlapping features
for the same task
• This can quickly spiral and create trouble
• Tool fatigue is when you have:
• Too many tools
• Too much overlap between tools
• Too much jumping between tools

83
 Tools sample in the DevOps pipeline

84
 Tools sample in the DevOps pipeline

85
Variations for DevOps
 DevOps variations
• DevOps focuses on automating the release of software
• People suggest that there are other lifecycle stages not
considered
• Therefore DevOps could incorporate those stages too
• Many DevOps variations now exist

87
 Example: AIOps
• AIOps = DevOps + ML + AI
• AIOps platforms collect data
from various IT operations
tools
• They automatically spot and
react to issues in real-time

88
 More Ops
• NoOps • ITOps
• Automate IT infrastructure with no need for an • Traditional way of delivering and maintaining services,
in-house team for operational purposes applications, and underlying technologies
• After product completion the cloud provider will • A more rigid IT infrastructure as the foundation of a
run further operations, monitoring, and successful pipeline
maintenance.

• CloudOps
• DevSecOps
• Shift to the cloud for infrastructure management
• Integration of security into the pipeline
• Creation of stateless environment and applications
• Shift security to the left

• CIOps
• GitOps
• Configure the IT infrastructure required to support the new
• Use Git to automate the rest of the continuous codes before deployment continues
delivery pipeline
• Deploy at varying levels of sophistication according to the
• Good for auditing, requires containerization complexity of the pipeline

89
 Even more Ops…
• MLOps

• BizDevOps
•…

90
 And more Ops-related concepts…
• Shift-left testing: running testing as early as possible
• Move testing from the right (end) to the left (beginning) of the delivery
process
• Allows to identify errors, risks and exposures early

91
DevOps with Service Reliability Engineering
 Site Reliability Engineering
• Google’s approach to DevOps

93
 Site Reliability Engineering
What is SRE?
• Site reliability engineering (SRE) fuses the software
engineering and operations disciplines
• SRE professionals spend about half their time in development
tasks and half on operations tasks
• The SRE role enables collaboration and information sharing
between Dev and Ops departments
• Similar to the DevOps principles but includes additional
objectives

94
 SRE Definition
• Site reliability engineering (SRE) is a discipline that
incorporates aspects of software engineering and applies them
to infrastructure and operations problems.[1] The main goals are
to create scalable and highly reliable software systems.
According to Ben Treynor, founder of Google's Site Reliability
Team, SRE is "what happens when a software engineer is
tasked with what used to be called operations."[2]

• SRE and DevOps share the same philosophy but are

alternative (competing?) practices…
• … though Google calls them “rather close friends”

95
 SRE Principles
• Embracing Risk
• Assess it, manage it, use of error budgets to provide usefully neutral approaches to service
management.
• Service level objectives
• Disentangle indicators from objectives from agreements and find useful metrics for the application
• Eliminate toil
• Toil is mundane, repetitive operational work providing no enduring value, and scales linearly with
service growth
• Monitoring
• If we cannot monitor a service, we do not know what is happening and we cannot be reliable
• Evolution of Automation
• A major SRE principle is the approach to automation
• Release Engineering
• Critical to overall system stability and consistency, as most outages result from pushing a change of
some kind
• Simplicity
• Must ensure it is not lost because it is extraordinarily difficult to recapture

96
 SRE Concepts
• Reduce organizational silos
• Ops is a software engineering problem
• Engineers are required to spend their efforts in solving issues with Ops
• Accept failure as normal
• Must encourage radical changes (within limits) that potentially lead to failure
• A measured risk budget is allowed for SREs to test these limits and potentially innovate faster
• Assume that 100% availability and performance targets are not viable to facilitate growth
• Implement change
• Must have continuous improvement through change
• An objective measurement of change needs to be defined
• Leverage tooling and automation
• Embrace consistent technologies and information access across the IT teams
• Follow a common Google practice: unify the codebase
• All teams working on the same service must adopt the same technology solutions
• Measure everything
• Measurement of Service-Level Objectives (SLO) is the dominant metric
• Allow budgeting for repetitive activities and risk
• The definition of ‘normal’ will evolve on a continuous basis

97
 DevOps vs Site Reliability Engineering
DevOps SRE

Ensure that different teams are not Share ownership with developers by using the same tools and techniques
isolated from each other across the stack

Accept failure as normal and learn from

Have a formula for balancing accidents and failures against new releases
errors

Implement gradual change to enable

Encourage moving quickly by reducing costs of failure
constant improvement

Encourages "automating this year's job away" and minimizing manual

Leverage tooling & automation to teams
systems work to focus on efforts that bring long-term value to the system

Measure everything through a feedback Believes that operations is a software problem, and defines prescriptive
loop ways for measuring availability, uptime, outages, toil, SLA, SLO, etc.

98
DevSecOps
 DevSecOps
• “Everyone is responsible for security”

100
 Most common DevOps threats by the end of 2021
Check https://www.bunnyshell.com/blog/challenges-of-devops
• Cultural shift - resistance to change
• App security
• Data security
• IP protections
• Responsibility
• Disconnect between security and development
• Stakeholders are not security savvy
• Compliance at risk
• Libraries dependency
• Credential management
• Untimely tool licensing
• Single provider dependency
• Developers are human

101
 DevSecOps
• Is DevOps just about development and operations?
• Releasing without considering security is a major weakness in
the approach
• Where is security to be considered
• Before implementation
• After implementation and before releasing
• After releasing
• In the past, security came after the releasing stage
• When the cycle ran in months, this was reasonable
• Not so today, where the cycle may be daily

102
 Move to DevSecOps
• The purpose of DevOps is to automate and speedup app delivery

• “The purpose and intent of DevSecOps is to build on the mindset

that "everyone is responsible for security" with the goal of safely
distributing security decisions at speed and scale to those who hold the
highest level of context without sacrificing the safety required.”

103
 The Case for DevSecOps

104
 DevSecOps
• Current thinking suggests that security is a shared responsibility
• Must be integrated from start to end
• Therefore: DevSecOps
• Need to build a security foundation into DevOps

105
 DevSecOps
• DevSecOps means thinking about application and infrastructure
security from the start
• Security is built-in, not surrounding apps
• Automating some security gates to keep the DevOps workflow
from slowing down
• Selecting the right tools to continuously integrate security
• Requires cultural changes of DevOps (which is already a
cultural change)

106
 Typical DevSecOps Workflow
1. A developer starts by writing code within a version control system
2. Any required change is committed to the version control system
3. Another developer analyzes the code to identify any security defect that
may weaken code quality
4. An environment is created to deploy and apply security configurations to
the system
5. Next, a test automation suite is executed to evaluate the newly deployed
application for security
6. After it passes the automation test, the application is deployed to a
production environment
7. This new production environment is actively monitored for security
threats

107
 Typical DevSecOps Workflow

108
 DevSecOps considerations
• DevOps focus on speed often leaves security teams flat-footed and reactive
• Cultural resistance to security
• DevOps environment relies on cloud deployments, thereby sharing many
cloud security considerations
• New open-source tools managing hundreds of security groups and thousands
of server instances may not be mature
• Containers carry their own risks
• Poor privileged access controls open dangerous backdoors: account
credentials, SSH Keys, APIs, tokens
• To expedite workflows, DevOps teams may allow almost unrestricted access
to privileged accounts (root, admin, etc.)
• The example of the Uber DevOps incident must be remembered (see next)
109
 DevSecOps and DevOps safety
• Enforce policy & governance Automate your DevOps security
processes and tools
• Perform comprehensive discovery
• Conduct vulnerability management Adopt configuration
management Secure access with DevOps management
• Control, monitor, and audit access with privileged access
management
• Segment networks

110
 DevSecOps Fail

111
 DevSecOps Fail

112
 DevSecOps tools
• Static application security testing (SAST)
• Scan proprietary or custom code for coding errors and design flaws that could lead to exploitable
weaknesses
• Used primarily during the code, build, and development phases of the SDLC
• Software composition analysis (SCA)
• As with SAST for open source and third-party components
• Used in a CI/CD process to continuously detect new open source vulnerabilities
• Interactive application security testing (IAST)
• Test and analyze web application runtime behavior, request/response interactions, dataflow, runtime
vulnerabilities
• They can indicate the line of code where the problem occurs
• Dynamic application security testing (DAST)
• Black box testing technology that mimics how a hacker would interact with a web application or API
• Test over a network connection much like a pen tester would
• Run-time application security protection (RASP)
• Run inside the application as a security tool and control application execution
• Protect after defenses are breached by running continuous security checks on itself and respond to
live attacks by terminating an attacker session

113
 DevSecOps

114
 Current top cloud security threads
• Data breaches
• Misconfiguration and inadequate change control
• Lack of cloud security architecture and strategy
• Insufficient identity, credential, access and key management
• Account hijacking
• Insider threats
• Insecure interfaces and APIs
• Weak control plane
• Metastructure and applistructure failures
• Limited cloud usage visibility
• Abuse and nefarious use of cloud services

From https://www.csoonline.com/article/3043030/top-cloud-security-threats.html

115
Thank you!
 DevOps as the world knows it

117
 The DevOps toolchain concept

118
 DevOps
options

119