DevOps & DevSecOps

Overview

DevOps
DevOps is a combination of two words: Development and Operations.
This allows a single team to handle the entire application lifecycle.
DevOps helps you to reduce the disconnection between software developers, QA
engineers and system administrators.
DevOps promotes collaboration between Development and Operations team to
deploy code to production faster in an automated and repeatable way.

DevOps has become one of the most valuable business disciplines for enterprises
or organizations.
With the help of DevOps, quality and speed of the application delivery has
improved.
The Operations consists of the administrative processes, services and support for
the software.
When the Development and Operations are combined, the DevOps architecture is
the solution to fix gap between deployment and operations teams; therefore
delivery can be faster.
The deployment comprises analyzing the requirements, designing, developing and
testing of the components or frameworks.
DevOps architecture:

This architecture is used for the applications hosted on the cloud platform and/or
large distributed applications.
Some key features of DevOps architecture:
• Automation : it can reduce time consumption, especially during the testing
phase;
• Collaboration,
• Integration : this phase is where the existing code is combined with new
functionality and then tested.
Continuous integration and testing enables continuous deployment;
• Configuration management : it ensures the application to interact with only
those resources that are concerned with the environment in which it runs.

DevOps lifecycle includes six phases:

Continuous Development
This phase involves the planning and coding of the software.
The vision of the project is decided during the planning phase, and the developers
begin developing the code for the application.

Continuous Integration (CI)

This phase is the heart of the entire DevOps lifecycle.
It’s a software development practice in which the developers require to commit
changes to the source code more frequently.
The code supporting new functionality is continuously integrated with the existing
code.
Continuous Testing
With the CI, there is also the Continuous Testing, because in this phase the
developed software is continuously testing for bugs.
For constant testing, automation testing tools are used.
Docker Container are also used for simulation the test environment.

Continuous Monitoring
Monitoring is a phase where important information about the use of the software
is recorded and carefully processed to identify problem areas and find out trends.

Continuous Feedback
The application development is consistently improved by analyzing the results
from the operations of the software. This is carried out by placing the critical
phase of constant feedback between the operations and the development of the
next version of the current software application.

Continuous Deployment
In this phase, the code is deployed to the production servers. Also, it is essential
to ensure that the code is correctly used on all the servers.

DevOps pipeline (CI/CD pipeline)

A DevOps pipeline is a set of practices that the Development and Operations
teams implement to build, test and deploy software faster and easier.
The most important components of a DevOps pipeline are Continuous Integration
and Continuous Delivery.
Briefly,
Continuous Integration (CI) ➔ is a method of integrating small chunks of code
from multiple developers into a shared code repository (central source control
system) as often as possible.
Continuous Delivery (CD) ➔ is an extension of CI, because it involves speeding up
the release process by encouraging developers to release code to production in
incremental chunks.
There are no fixed rules as to how you should structure the pipeline.
DevOps teams add and remove certain stages depending on their specific
workflows, but 4 core stages make up almost every pipeline:
Develop, build, test, deploy.
That set-up can be extended by adding two more stages: plan, monitor.
• Plan : the planning stage involves planning out the entire workflow before
developers start coding. In this stage, product managers and project
managers play an essential role, because their job is to create a
development roadmap that will guide the whole team along the process.
• Develop : In this stage, developers start coding.
When developers are ready to submit their code, they make a pull request to
the shared source code repository.
• Build : this phase is crucial because it allows developers to detect errors in
the code before they make their way down the pipeline and cause a major
disaster.
After the newly written code has been merged with the shared repository,
developers run a series of automated tests. In a typical scenario, the pull
request initiates an automated process that compiles the code into a build
— a deployable package or an executable.
If there is a problem with the code, the builds fails and the developer is
notified of the issues. If that happens, the initial pull request also fails.
Developers repeat this process every time they submit to the shared
repository to ensure only error-free code continues down the pipeline.
• Test : if the build is successful, it moves to the testing phase in which
developers run manual and automated tests to valeted the integrity of the
code further.
• Deploy : when the build reaches this stage, the software is ready to be
pushed to production.
An automated deployment method is used if the code only needs minor
changes.
Implementing a blue-green deployment strategy is also common when
releasing significant updates.
It means having two identical production environments where one
environment hosts the current application while the other hosts the update
version.
• Monitor : at this final stage in the DevOps pipeline, Operations teams collect
valuable data from logs, analytics and monitoring systems as well as
feedback from users to uncover any performance issues.
Feedback gathered at the Monitor stage is used to improve the overall
efficiency of the DevOps pipeline.
 DevSecOps
DevSecOps refers to the integration of security practices into a DevOps software
delivery model.
The definition of DevSecOps Model, at a high-functioning level, is to integrate
security objectives as early as possible in the software development lifecycle.
While security is everyone’s responsibility, DevOps teams are uniquely positioned
at the intersection of Development and Operations, empowered to apply security
in both breadth and depth.

Benefits of the DevSecOps Model:

1. Faster delivery : the speed of software delivery is improved when security is

integrated in the pipeline, because bugs are identified and fixed before
deployment;
2. Improved security posture : security is a feature from the design phase
onwards and the shared responsibility model ensures security is tightly
integrated;
3. Reduced costs : by identifying vulnerabilities and bugs before the
deployment;
4. Enhancing the value of DevOps;
5. Improving security integration and pace : cost and time of secure software
delivery is reduced through eliminating the need to retrofit security control
post development;
6. Enabling greater overall business success.
Integrating security into the CI/CD pipeline
The pipeline is an excellent foundation from which a variety of automated security
testing and validation can be performed, without requiring the manual toil of a
human operator.

To integrate security objectives early in the development of an application, start

before the first line of code is ever written.
Security can integrate and begin effective threat modeling during the initial
concept of the system, application, or individual user story.
Static analysis and policy engines can be run any time a developer checks in code,
ensuring that any low-hanging fruit is dealt with before the changes move further
upstream.
Software composition analysis can be applied holistically to confirm that any
open-source dependencies have compatible licenses and are free of
vulnerabilities.
One the code is checked in and builds, you can start to employ security
integration tests. Running the code in an isolated container sandbox allows for
automated testing of things like network calls, input validation and authorization.
These tests generate fast feedback, enabling quick iteration and triage of any
issues that are identified, causing minimal disruption to the overall stream.
If an issue is identified, the tests fail and the pipeline generates actionable
feedback in the form of reporting and notifications to the relevant teams.
One the deployment artifact passes the first battery of integration tests, it moves
on to the next stage of integration testing: now, it will be deployed to a wider
sandbox, a limited copy od the eventual production environment.
At this stage, further security integration testing can be performed, albeit with a
different objective. Things like correct logging and access controls can be tested.
Finally, the application makes its way to production, however, the work of
DevSecOps continues: automated patching and configuration management
ensure that the production environment is always running the latest and most
secure versions of software dependencies.

DevSecOps culture
There are 4 key pillars that must be considered when looking to shift the
DevSecOps culture of an organization:
1. People
2. Processes
3. Technologies
4. Governance
Culture is a result of people, process, technology and governance functioning
together.

The environment of shared responsibility and mutual empathy requires breaking

down barriers between teams. Consequently, people are the starting point and
the foundation of any DevSecOps implementation.
The next step is introduce supporting processes, with the aim to further improve
collaboration between people as well as achieving more secure development
processes as a whole.
These processes changes are designed to span the three functional areas:
Development, Security, Operations, providing cohesion and uniformity between
them.
Additionally, DevSecOps approach requires having the right technologies in place
to enable employees to execute these processes as well as automate them.
This reduces the organization’s attack surface and enables effective management
of technical security debt.
Finally, one of the least thought of elements of a true DevSecOps culture is
governance. While the people, processes and technologies come together to
support each other, governance also plays a key role, because it measures the
performance of the other elements and can point out where more focus is needed
to ensure all parts of the culture form together.
So:
People: empowering the team
Process: supporting the new DevSecOps culture
Technology: paving a path to success
Governance: measuring results

Source: https://snyk.io/devsecops/

Security tools to implement DevSecOps

To implement DevSecOps, organizations should consider a variety of application
security testing (AST) tools to integrate into their CI/CD process.
Types of AST:
• SAST : stands for Static AST
• SCA : stands for Software Composition Analysis
• IAST : stands for Interactive AST
• DAST : stands for Dynamic AST

SAST and DAST

SAST, or static analysis, is a testing methodology that analyzes source code to
find security vulnerabilities that make your organization’s applications
susceptible to attack.
SAST scans an application before the code is compiled.
SAST is also known as white box testing.
It helps developers identify vulnerabilities in the initial stages of development and
quickly resolve issues without breaking builds or passing on vulnerabilities to the
final release of the application.
It’s important to note that SAST tools must be run on the application on a regular
basis, such as during daily/monthly builds, every time code is checked in, or
during a code release.
DAST is a testing methodology that examines an application while it’s running,
without knowledge of the application’s internal interactions or designs at the
system level, and with no access or visibility into the source program.
DAST is also known black box testing.
This methodology looks at an application from the outside in, examines its
running state and observes its responses to simulated attacks made by the tool.
An application’s responses to these simulations help determine whether the
application is vulnerable ad could be susceptible to a real malicious attack.
There are many different types of DAST solutions available.
These range from more traditional DAST tools (that provide dynamic scanning and
analysis of web apps during runtime) to DAST solutions that combine web and API
scanning, penetration and fuzz testing.
There also next-generation technology tools such as IAST.

Differences between SAST and DAST:

SAST DAST

White box testing Black box testing

The application is tested from the inside out
Requires source code
It analyzes the sources code or binary
without executing the application
Finds vulnerabilities earlier in the SDLC
The scan can be executed as soon as code is
deemed feature-complete
Less expensive to fix vulnerabilities
Since vulnerabilities are found earlier in the Since vulnerabilities are found towards the
SDLC, it’s easier and faster to remediate them end of the SDLC, remediation often gets
Can’t discover run-time and environment-
related issues
Tool scans static code
Typically supports all kinds of software
The application is tested from the outside in
Requires a running application
It analyzes by executing the application
Finds vulnerabilities toward the end of the
SDLC
The scan can be executed after the
development cycle is complete
More expensive to fix vulnerabilities
pushed into the next cycle. Critical
vulnerabilities may be fixed as an emergency
release
Can discover run-time and environment-
related issues
Tool is able to find run-time vulnerabilities
Typically scans only web apps and web
services
It’s not useful for other types of software

The best approach is to include both SAST and DAST in your application security
testing program
Examples of SAST:
• Fortify Static Code Analyzer
• SonarQube
• ShiftLeft
• Coverity Scan
• Checkmarx CxSAST
• AppScan
• Reshift Security
• Brakeman
• Findbugs
• CodeWarrior

Examples of DAST:
• Clair
• Aqua
• Anchore
• Netsparker
• Acunetix
• AppScan
• Detectify
• Mister Scanner
• PortSwigger