Migration From DevOps To DevSecOps - A Complete Migration Framework, Challenges and Evaluation-Jul-12-2020-0359

You are on page 1of 19

Title

Migration from DevOps to DevSecOps - A complete migration framework, challenges and


evaluation
Abstract— DevOps development strategy is based on lean and agile principles and developed to
ensure faster delivery. It ensures the collaboration of all stakeholders in the software
development process and incorporates user’s feedback in a faster manner. This strategy is
developed to guarantee customer satisfaction, increased business value, reduced time for bagging
the feedback and adjusting the deliverables. Once the DevOps settled down the practitioners
started talking about the next concern, security. This became so crucial when business needs
started moving from traditional work space to cyber space. They identified a requirement of
prioritizing security in DevOps and started conferring about security to be embedded in DevOps.
This introduced a mission critical issue in many organizations as it requires breaking down of the
barriers of operations and security team and review of many security policies in place. The
challenge is to find the best way in DevOps can still perform Continuous Integration (CI) and
Continuous Delivery (CD) after implanting and automating security in DevOps environment.
This paper introduces a complete migration framework from DevOps to DevSecOps explaining
the strategy, steps, tools and support functions. As DevSecOps is still in the nascent stage of its
growth, the lack of a framework is disturbing the organizations. This paper also identifies the
attributes on which the migration framework can be evaluated considering the challenges in
migration. Organizations who are planning a migration to DevSecOps can use this model to test
their readiness for the phase thereby reducing the unexpected challenges that are prone to come.
Keywords—DevSecOps migration, DevOps framework, Evaluation of framework, Evaluation
attributes, Security in DevOps, Migration levels, Support functions for migration, Migration
strategy, Tools, Challenges.
1. INTRODUCTION
Initially software development process was bound to be the traditional waterfall model
where a series of phases are executed in a cascaded manner, each step delivered a documentation
and is used as a starting point of the next phase in interrelated manner. The completeness of this
process and the implementation styles influenced the quality and speed of software development.
Then emanated the idea of DevOps based on continuous delivery where the where each
individual deliverable are tested and deployed. As the security concerns in software products
increased, developers started identifying the needs of infusing security in to this continuous
development and deployment process and started thinking of Security in DevOps or DevSecOps.
We moved from the concept of software as a product(SaaP) to software as a
service(SaaS) in which the software is centrally hosted mostly on cloud and clients access it
through a browser. This changed the entire software delivery concept as the software provider
will be delivering improved versions after any updates and does not require to go through the
delivery, implementation and maintenance cycle again. The entire exercise is to reduce this cycle
time and incorporate faster feedback by introducing the concept of Continuous Integration (CI)
and Continuous Delivery(CD). This was the evolution point of the concept called DevOps
(Development and Operations). The driving force behind this adaption was the necessity of cloud
adaption and software defined environments and hurried the introduction of DevOps concept.
This change in the software development process necessitated more collaboration and
communication of development and operations team. DevOps came with a lean development
methodology which joined the different processes in the cycle such as development, delivery and
operations. This idea shifted the software development process from a distributed autonomous
groups to cross-functional groups delivering continuous results (Ebert et al, 2016) and combining
software development with other information technology operations. The systems development
life cycle is reduced by delivering desired results and updating frequently in agile manner
aligning closely with business objectives.
That was the time where the DevOps is getting stabilized, then next issue of security
started bubbling up. The reason was the inability of the customary security techniques to
maintain agility and speed to move along with DevOps. DevOps implementation automated the
software development and deployment lifecycle and facilitated rapid software deployment and
service. The predominant bias towards availability on DevOps made the practitioners think about
how to integrate the other two aspects of CIA to the DevOps framework, confidentiality and
integrity. (Myrbakken et al, 2017).
DevOps is based on the concept of fast deployment of software components to the user
and may decline the security intensity in it. This will be worsened if the organizations itself is
considering security as a barrier for fast development and deployment and don’t want the
security testing to slow down the entire development and deployment process. Then they try to
shift security to last phase of software development cycle (Filkins,2016). This demanded the
information security professionals to become an active participant in DevOps and maintaining
the aspects of teamwork, coordination, agility and shared responsibility (MacDonald and Head,
2016). This initiated must require integration of modernized security methods to achieve
optimized software development process. The practitioners realized the fact that DevSecOps is
not just adding security to the CI and CD; but building security to the software to deliver
compliances (Lietz, 2016) especially when the security needs to be aligned with the compliances
of different regulatory standards.
To maintain the agility and speed of DevOps and still include security in it, a
collaboration and harmony is required between developers, information security professionals
and operation team. The Information security tools used by the organization also need to be to be
integrated at multiple points into DevOps lifecycle (Rahman and Williams, 2016). The
incompatible traditional application security testing, low priority for security by DevOps
developers, compliance issues in DevOps culture also created an intense need of adopting
security into the DevOps making DevOps and security a single entity of existence.
In this paper we are addressing DevSecOps as a way of integrating security in DevOps
where the absorption of security is spread across the overall process of software development.
DevSecOps advanced workflow will integrate security practices at every stage of entire lifecycle.
This paper talks about a complete migration framework from DevOps to DevSecOps including
the strategy, procedure, support functions and tools. After the identifying the migration
framework, we also tried to evaluate the framework by identifying the attributes and also listed
out the challenges in a complete migration.
The remainder of this paper is as follows. Section 2 discusses the previous researches
relevant to security in DevOps and its adaptation to software development. Section 3 explains
the migration framework and Section 4 identifies the implementation challenges of the migration
and Section 5 defines an evaluation matrix for the framework. Section 6 talks about the
contributions of the research in the software development community. Finally the paper is
concluded with the indication of future research direction.
2. LITERATURE REVIEW
Earlier software development and delivery process followed a way of promising a
delivery of the entire product in a time line specified by the users. This resulted in false promises
and extended delivery deadlines and business many times compromised the quality, time and
efficiency. Introducing DevOps to this process improved the performance by introducing joined,
agile, lean and transparent process in development and deployment (Storms, 2015). DevOps
ensures continuous delivery of up gradations after incorporating customer feedback (Ebert et al,
2016).
DevOpsSec, SecDevOps and DevSecOps are the three basic approaches followed by
industries to merge security with DevOps environment. (Fig 1)
1. DevOpsSec
This is the adaption strategy where the security is integrated at the end of the DevOps process.
The traditional way of adding security at the last after the software is developed in the
fundamental insecure way (Carter, 2017). The DevOps team will start thinking about security
once the entire cycle is over and security is not embedded into the lifecycle. The process is
development, deployment, operation, and then review security. Still it can be a good
improvement to the process of security assessment if it is completed in small increments and
accomplished rapidly. However, it lacks complete security, optimum speed and may give a way
to vulnerabilities. It requires the security team to be the primary testers of the software and make
sure that this does not slow down the process (Filkins,2016).
2. SecDevOps
The security is integrated before the DevOps starts and integrates security as the starting
point. The development team identifies the security consideration projecting the development
and include the security requirements in planning phase itself. Automated tests are created based
on these requirements specified. Even though ideal for a theoretical consideration but difficult to
adopt practically. The reason is once freeze at the early stages, the security requirements cannot
be changed and lacks the flexibility to incorporate the changes. It also cannot include the updated
security checks and requirements after receiving the user feedback.
3. DevSecOps
DevSecOps, the adaption style where security is fused into the overall process. The idea
of this style of merging is to equip the existing development life cycle with highly automated
tools enabling developers to take small actionable step quickly and enhance security. This
method benefits from the improved collective teamwork of security, development and operation
professionals. This method requires the integration of an actionable feedback mechanism
throughout the life cycle and continuously updates security based on the feedback. Because of
the practicality and implementation suitability, this approach is gaining wide acceptance and
many organizations are shifting from DevOps to DevSecOps. This paper is also revolving around
this idea of migration from DevOps to the secured DevOps.
Figure 1 Approaches for security adoption

The customary way of adding security at the end of a product life cycle was inherently
slow and became the reason for slaw and faulty delivery. This accelerated the need for
automating the security testing process and a collaborative working style of security team and
DevOps team. This requirement strictly stated that these two should not work in silos and should
be in tune. The concept of DevSecOps is then explained the idea of delivering security as a code.
DevSecOps Centre of Excellence (EGT LAB) defines the best practices of DevSecOps as
establishing a security culture, coaching, security first design, automation, build-deploy-test
often and DevSecOps friendly acquisition (E global tec, 2018).
DevOps was not very much in differing to security. DevOps features such as consistency,
auditability and increased predictability favoured security; but was worried about the security
issues in faster production, more deployments, less test cases and no audit (Storms, 2015).
DevSecOps addressed these issues by embedding security at the very basic level of development
and promoted threat hunting, immutable infrastructure, security auditing and monitoring, cost
reduction by ensuring customer value, culture of openness and transparency and measuring
ability (Raynaud, 2017).
Integration security in DevSecOps adopted the style of shifting security to the left. This
facilitated the development process by reducing the time and cost incurred if a rebuild of
software is dispensed (Ebert et al, 2016). This migration should consider the different layers of
security integration such as infrastructure, platform and application (Myrbakken et al, 2017). It
has been suggested by software practitioners as DevSecOps should focus on software quality and
security, compliance requirement and risk avoidance in the process of software development and
deployment (Synopsis, 2018) .
DevSecOps practitioners cautioned the migration team that they should try adapting
security with operations not vice versa and remember 100% security is not attainable. The rest of
security can be compensated with security applications, identify and remove known
vulnerabilities, train developers on security coding and will definitely ease the migration process
(KnowledgeHubMedia, 2017). Some common security measures that will reduce these
unexpected issues after implementing are sanitizing the input to block common attacks like
buffer overflows, SQL injection and cross site scripting (MacDonald and Head, 2016).
This area of DevSecOps is still in its budding stage and practitioners are fighting to get
good references for their migration. One best practices suggested for the migration include good
documentation, strong collaboration, process automation and enforcement of separation of duties
(Mohan et al, 2018). Stemming NIST framework along with the DevOps delivery pipeline is one
method adopted for DevSecOps implementation in healthcare sector (Colomo-Palacios et al,
2013).
Another challenge this collaboration of security face is the mandatory information
sharing happens between the teams when the integration takes place. Even though it is very
necessary for a smooth integration of functions it will have incalculable security implications. It
is better to have a proper policy defined for this information sharing before the organizations
plan for DevSecOps migration (Mohan et al, 2016). This integration and collaboration may also
result in unauthorized access and the policy should address it very carefully without hammering
the very basic idea of collaborative environment (Rahman and Williams, 2016a.). One major
challenge identified is the slow maturation of the security tools which will enable the integration
of security in DevOps environment (Hulme, 2018).
Another challenge this migration is bringing to the organization are the conflicts in
workgroups and the problems in group dynamics. One research suggests the use of agency
theory to solve this issue by defining the development team as the agent and customer as
principal. The conflicts happen in the goal attainment can be addressed by goal abstraction and
information transparency (Lee , 2018).
Lack of a standardized model is troubling the migration process and organizations are
eager to know their DevSecOps adaptation posture. The only one model available is a
DevSecOps maturity model is defined with the stages Burp, Crawl, Walk, Run and Fly
(Lietz,2016). The different aspects of DevSecOps like the definition, security best practices,
compliances, process automation, tools, software configuration, team collaboration, availability
of auditing data and information security is analyzed to find the momentum of this concept in the
software development methodology (Mohan et al, 2016).
We are at the very nascent stage of DevSecOps migration and organizations are still
having no clue about how to approach the change and how to benchmark their progress.
Researchers and DevSecOps practitioners are working together to find out a comprehensive
model which can be used as a checkpoint when the organizations migrate to DevSecOps
approach. This paper is trying add to the research area by integrating all the different aspects of
security migration in to a single framework and provides a consolidated technique to fix the
problem that organizations undergo when migrating to DevSecOps. This framework is unique in
the aspects that it comprehensively covers all the different components of information system
development and their contributions to the DevSecOps migration.
Migration to a new platform always brings risks to the organization. Companies are still
not a position to talk about the DevSecOps migration risks and challenges as it is just started
experiencing it. They trying to align it with many other migration scenes and finding out the
possible risk factors that the migration should care for. Agile and to DevOps migration and cloud
migration are the recent past in the software development framework and this study does a
literature review on the challenges, risk factor and issues identified in these migration and the
framework evaluation.
Basically the risks associated with any migration can be categorized as business risk,
organizational risk and technical risk. A decision support system to decide the cloud migration
identifies the risks as Business value, organization function, Confidentiality, integrity,
availability and transparency (Islam et al, 2017). A cloud migration framework is evaluated
using different parameters categorized as generic and cloud specific risks (Gholami et al, 2016).
All the migration is talking about the basic business attributes such as cost saving, efficiency,
scalability and maintainability (Rai et al, 2015) (Taibi et al, 2017). This pointed to the fact that
any type of migration should take care of the business and its basic functioning mechanism
keeping in mind the intangible benefits of it.
Based on this basic idea on how a new software development framework should be
evaluated and what are the challenges the migration will face; we are defining the factors on
which our DevSecOps migration model should be evaluated. This study also identifies the key
challenges in the migration process and how the model addresses it with the aid of the
components identified.
3. CONCEPTUAL FRAMEWORK- MIGRATION FROM DEVOPS TO DEVSECOPS
A smooth transition from DevOps to DevSecOps requires complete strategy and should
own a secure culture. Unplanned and unthoughtful migration may not achieve the main purpose
of DevSecOps. Before integration into DevOps, security teams should undergo a series of
homework including risk assessment, threat modelling and defining security baselines. This
helps the security team to flawlessly integrate security in to the automated CI and CD phases.
The migration framework explained bellow talks about the following components.
• Levels of migration
• Migration Strategy
• Migration Procedure
• Support functions
• Tools
Figure 2 shows the complete migration framework including all the above mentioned
components and their interrelationships. It provides an instrument to identify the tools used in
every stage of integration and the support functions at each level that needs to be aligned with
the migration.
Figure 2 Migration Framework
3.1 Levels of Migration
DevSecOps migration strategy is focused on four levels: Governance, People, Process and
Technology (Moore and Bovoso, 2018) (Wootton and Erkunt, 2018).
• Governance
Governance is the base level from which the migration should start from by ensuring the
top management support for the security integration to DevOps. This may necessitate a complete
remodeling of the governance and compliance framework with proper delegation of authority to
the operational support.
• People
People, considered to be the weakest link of security plays an important role in
DevSecOps migration too. They are responsible for removing the silos by communicating
effectively in the entire process of DevSecOps migration (Raynaud, 2017). They need to
innovate and adapt quickly to the new environment (Myrbakken et al, 2017) to make sure that
the inclusion of Security into DevOps does not ruin the speedy delivery concept of DevOps.
Proper communication, feedback mechanism and employee training is effectively included in
this migration framework as migration procedures and support functions.
• Process
Aligning the software development process with security is the important concern in
DevSecOps migration (Myrbakken et al, 2017). There should be a proper integration of security
process to the development and deployment process flow adding incident response, clear
documentation and version control (Ebert et al, 2016) (Wootton and Erkunt, 2018). It should
include a policy to move security to the earliest, for standard enforcement, security testing,
release and deployment (Storms, 2015). Establishing a concrete DevSecOps practice is necessary
to make sure that the new security process does not affect the agile behaviour of DevOps.
• Technology
At this level the focus will be to identify the extent to which technology can enable the
migration process. The migration framework identifies the repetitive tasks for establishing
security and applies automation to the utmost level it can. Host hardening, CI/CD patching etc.
are some of the examples of the technology adaption for DevSecOps migration (Raynaud, 2017)
(Myrbakken et al, 2017). Technology should aid the reduction of manual intervention in security
testing so that the migration to DevSecOps will be smooth without any hurdles and delays.
3.2 Migration Strategy
The strategy for the migration to DevSecOps describes the approach organizations
follows while migrating which ensures all the aspects of migration has been taken care of. We
suggest set of migration strategy which extensively covers all the phases of migration starting
from understanding the requirements to continuously monitoring and vulnerability management.
Strategy 1: Understand DevSecOps and it’s extend with depth.
Strategy 2: Identify requirements of DevSecOps.
Strategy 3: Gather required tool set and infrastructure changes
Strategy 4: Harden the core infrastructure and integrate secure development tools
Strategy 5: Adopt secure development processes with enhanced security automation.
Strategy 6: Integrate security controls and compliance automation tools and practices in
operations
Strategy 7: Continuously monitor and analyse output at each process and integrate feedback
mechanism for entire lifecycle to continuously update security posture.
Strategy 8: Set vulnerability management program, threat intelligence mechanism and red team
for security testing at regular interval as well as in ad-hoc manner.
3.3 Migration Procedure
After identifying the levels and understanding the migration strategy, this framework
defines the migration procedure from DevOps to DevSecOps which involves the following steps.
• Step I : Initial assessment of entire DevOps process
• Step II : Imbibe Threat Modelling to secure network
• Step III : Harden the development environment
• Step IV: Integrate security tools in development environment and then proceed for
coding.
• Step V : Update security definitions and integrate tools to automate code review
• Step VI : Integrate extra layer for compliance and penetration testing by Red Teams
• Step VII: Secure configuration and deployment procedures and automate the process.
• Step VIII: Establish monitoring, intrusion detection mechanism
• Step IX : Setup rollback mechanism in case of incident and app update tools
• Step X : Automate log and incident analysis using tools
• Step XI : Setup repose process, escalation ladder and remediation process using enhanced
tools
• Step XII : Integrate tools to predict upcoming security requirement
• Step XIII : Establish feedback mechanism in the entire lifecycle to speed up changes
• Step XIV : Train employees while establishing new procedures and adopting new tools
• Step XV : Threat Intelligence and Vulnerability management program will update
security tools
• Step XVI: Continuously optimize the process to maintain speed and agility with security.

3.4 Support Functions


The other functions of organization need to support the migration frame at different
migration points to make sure that a smooth transition takes place in the defined scope. The other
functions that supports migration are identified as follows. We have named the support functions
for the easy referencing in the model.
• Inventory Management (Sup_IM)
• Configuration and Patch Management (Sup_CPM)
• Vulnerability Management Program (Sup_VM)
• Threat Intelligence (Sup_TI)
• Change Management (Sup_CM)
• Employee Training (Sup_ET)
• Event/Incident Management (Sup_EM)
This model expresses that the involvement of these support functions are inevitable and
spreads across the entire life cycle of the product development and deployment. The success
factor of this migration primarily depends on the extent of support these functions can provide to
the required time frame.
3.5 Tools
We also identified a list of tools that can aid the migration process. The list is not an
extensive list of all tools and can include more when new tools are introduced. Table 1 shows a
list of tools with their features and their role in DevSecOps.
4. CHALLENGES OF MIGRATION
Migrating the entire working environment is very sensitive issue to many organizations.
If not executed correctly, this migration may introduce some unseen problems to the
development environment. Organizations need appropriate measures to smoothen the migration
by correctly identifying the issues and addressing it appropriately.
We identified the challenges that this migration will face and are coded for the easy
reference. The eight identified challenges are
a. CH#1#BENCHMARKING
b. CH#2#FRAMEWORKS
c. CH#3#INFO_SHARE
d. CH#4#LACK_POLICY
e. CH#5#UNAUTH_ACCESS
Table 1 Tools 1
Table 2 Tools 2
f. CH#6#SLOW_MAT
g. CH#7#GROP_CONFLICT
h. CH#8#GOAL_CONFLICT
The challenges are addressed by the prescribed model to some degree. Table 2 explains how
the challenges are addressed by the model.
Table 3 Challenges

We have also identified that component in the migration frame work which will aid the
DevSecOps practitioner in addressing the challenges. We have identified it in two different
dimensions as the level at which the challenge should be addressed and the support function
which will aid the migration framework to overcome the challenge. Table 3 describes this
concept and identifies a matrix for the challenges.
The challenges vary from different aspects of implementation and requires a wholesome
method to identify and rectify it. This model clearly enumerates all the challenges and how it can
be rectified with the help of the migration framework suggested. It highlights the fact that there
should be collaborative environment as suggested by the migration framework in the
organization to make this transition smoother and effective.
5. FRAMEWORK EVALUATION MATRIX
A framework developed need to be evaluated considering the factors that attribute it in
the business space. The challenge was to identify that factors which can be used to evaluate the
migration framework. Since at the organizations are still struggling to find a way to migrate to
DevSecOps, the framework evaluation is a distant dream.
Table 4 Challenges addressed

In this research we are trying to evaluate the conceptual model, even though in the very
preliminary stage by identifying the key factors. Since no model is developed and tested, we are
taking the background study of other major migrations occurred in the software industry as cloud
migration and DevOps migration. These two migrations also created a major breakthrough in the
software development scenario, the factors taken from that background was convincing enough
to evaluate the framework.
The key factors identified are listed below. We have classified these factors on the basis
of the four levels that we have identified in the framework as Governance, People, Process and
Technology. We could also connect it with the eight challenges and how these factors are
addressing it. Later we have analyzed how this model addresses the business, organizational and
technical risk that comes as a byproduct of the migration.
1. ROI
For any business process, ROI is perceived as an important issue. If migration is the only
choice, business need to find a way to accept it. Calculating ROI in terms of financial attributes
in one way to evaluate the model.
2. Business Value Increment
The business value in terms of profit, growth, service enhancement and low maintenance
are the measures of success of a new model. Evaluate it on qualitative terms to judge the model.
3. Transparency to the stake holders
Every business has a commitment to the stakeholders to make the process as transparent
it can. The more transparency it can bring, the better will be the model. Migration framework can
be evaluated on the basis of transparency it adds to the entire scenario change.
4. Business Process Refinement
Any update of an existing model should bring some change in the business process. The
model can be evaluated on the basis of the refinement it brought to the existing model.
5. Business Domain Adaptability
Every business domain will have its own peculiar characteristics. The migration should
be in such a way that the adaption to the business domain is stress-free.
6. Business Environment Friendliness
The external environment pedals the business to a very great extend in a veiled way. The
migration should consider the external factors and should make sure that it addresses all those
concerns.
7. User Training Requirement
Any change requires user training. The migration should be evaluated on the basis of the
new training requirement that arise and how the transition can be smoothened.
8. Organizational Structure Re Architecture
It will be a big pain to the management if the organizational structure need to be revised
as part of the migration. The migration model is evaluated by the top management on the basis of
how much painless will be the re-structuring, still performing the necessary tasks.
9. CIA Confidentiality, Integrity, Availability
As we are embedding security in to the DevOps environment, the extent to which the
three basic attributes of security are handled is another evaluation criterion for the model.
10. Maintenance Reduction
Any new model or a migration should reduce the complexity of the maintenance that will
be required in the next stage. This should make the distribution simplified and contribute to the
understandability.
11. Scalability to Technology
Scalability makes sure that it can be easily adapted to any new technology which may
come in near future. In this frequently changing technology era the migration should foresee the
changes and should prepare the migration to accept the change.
12. Infrastructure Flexibility
Infrastructure of the organization should be prepared enough for the migration. The
flexibility of your organization to adapt to the migration is another area of evaluation to be done.
13. Platform Support
The operating system and the network architecture is another area where the migration
should happen and is where migration evaluation should happen.

Figure 3Evaluation Factors

6. CONTRIBUTIONS OF THE MODEL


This model enforces the very basic concept of “Security by design” by adapting the best
migration practices and tools. This research brings forth a framework for the successful
migration of DevOps to DevSecOps comprising of all the aspects of migration. This framework
is a naïve idea in DevSecOps migration and is the true contribution of our research.
Organizations who are thinking of migrating to DevSecOps can use it as a tool for benchmarking
their activities with other counterparts.
The challenges defined in Section 4 can help organizations to foresee the problems that
they may face and can be prepared to address it with more effective decisions. The more
prepared the organizations will be for the migration, a better savings in terms of time, money and
effort can be obtained.
The evaluation matrix is an effort to find the attributes or factors on which this type of
migration framework can be evaluate. A score prepared by the migration team using this matrix
can be the best management tool to evaluate and convince the stakeholders about the migration.
7. LIMITATIONS AND FUTURE RESEARCH DIRECTIONS
As it is a theoretical framework, no experiments are conducted to validate the framework.
There is no models in research offering this kind of migration strategy. The research limitation is
this lack of benchmarking model with which this migration framework can be combined. The
evaluation matrix identified should be tested with real project data and can be amended with new
attributes as the organization moves its trajectories. This research can be extended by evaluation
the matrix using case study on the migration scenarios on different organizations. Conclusion
The industry still not reached to that saturation point of DevOps and its adaptation. This
is the time where we can align security with DevOps without much pain. The framework
explained in this model will aid the organizations to smoothly move to a security intense model
of DevOps. The tools identified in the study can assistance the organization to automate the
process of security integration without making a delay which is the inherent part of security.
8. References
1. “Aqua Security.” [Online]. Available: https://www.aquasec.com/. [Accessed: 26-Sep-
2019].
2. “CA Technologies.” [Online]. Available: https://www.ca.com/us.html. [Accessed: 26-
Sep-2019].
3. Carter,K., “Francois Raynaud on DevSecOps,” IEEE Softw., vol. 34, no. 5, pp. 93–96,
2017.
4. “Checkmarx.” [Online]. Available: https://www.checkmarx.com/. [Accessed: 26-Sep-
2019].
5. “Chef Automate.” [Online]. Available: https://www.chef.io/products/automate/.
[Accessed: 26-Sep-2019].
6. “CloudPassage.” [Online]. Available: https://www.cloudpassage.com/. [Accessed: 26-
Sep-2019].
7. “CollabNetVersionOne.” [Online]. Available:
https://www.collab.net/products/versionone. [Accessed: 26-Sep-2019].
8. “Contrast.” [Online]. Available: https://www.contrastsecurity.com/. [Accessed: 26-Sep-
2019].
9. “CodeAI.” [Online]. Available: http://www.mycode.ai/what-can-iceberg-do-1.
[Accessed: 26-Sep-2019].
10. Colomo-Palacios, R., Messnarz, R., and Biró, M., Dealing with security, vol. 36, no. 1.
2013.
11. “Continuum Security.” [Online]. Available: https://iriusrisk.com/. [Accessed: 26-Sep-
2019].
12. “CyberArk.” [Online]. Available: https://www.cyberark.com/. [Accessed: 26-Sep-2019].
13. “Datical.” [Online]. Available: https://www.datical.com/. [Accessed: 26-Sep-2019].
14. “DBmaestro.” [Online]. Available: https://www.dbmaestro.com/. [Accessed: 26-Sep-
2019].
15. “Dome9.” [Online]. Available: https://dome9.com/. [Accessed: 26-Sep-2019].
16. Ebert, C., Gallardo, G., Hernantes, J., & Serrano, N. (2016). DevOps. Ieee
Software, 33(3), 94-100.
17. E global tec, “DevSecOps Drives Reliable and Secure , Software,” 2018.
18. “Evident.io.” [Online]. Available:
https://www.paloaltonetworks.com/cloud-security/prisma-public-cloud. [Accessed: 26-
Sep-2019].
19. Filkins, B. “A devSecops playbook,” no. March, 2016.
20. Gholami, M. F., Daneshgar, F., Low, G., & Beydoun, G. (2016). Cloud migration process
—A survey, evaluation framework, and open challenges. Journal of Systems and
Software, 120, 31-69.
21. Hulme, G. V., “DevSecOps The road to faster, better and stronger software.” ,
Devops.com , 2018.
22. “IBM Appscan.” [Online]. Available: https://www.ibm.com/hk-en/security/application-
security/appscan. [Accessed: 26-Sep-2019].
23. “IBM QRadar.” [Online]. Available: https://www.ibm.com/in-en/marketplace/ibm-
qradar-siem. [Accessed: 26-Sep-2019].
24. “IBM UrbanCode.” [Online]. Available: https://developer.ibm.com/urbancode/.
[Accessed: 26-Sep-2019].
25. “Imperva.” [Online]. Available: https://www.imperva.com/. [Accessed: 26-Sep-2019].
26. “immun.io.” [Online]. Available: https://www.immun.io/. [Accessed: 26-Sep-2019].
27. Islam, S., Fenz, S., Weippl, E., & Mouratidis, H. (2017). A risk management framework
for cloud migration decision support. Journal of Risk and Financial Management, 10(2),
10.
28. “JFrog Xray.” [Online]. Available: https://jfrog.com/xray/. [Accessed: 26-Sep-2019].
29. KnowledgeHubMedia, “10 Things to Get Right for Successful DevSecOps” , 2017,
October.
30. Lee, J. S., “The DevSecOps and Agency Theory,” Proc. - 29th IEEE Int. Symp. Softw.
Reliab. Eng. Work. ISSREW 2018, pp. 243–244, 2018.
31. Lietz, S., “Demystified DevSecOps,” 2016.
32. MacDonald, N. and Head, I. “DevSecOps: How to Seamlessly Integrate Security Into
DevOps,” Gart. Res., no. September, p. 15, 2016.
33. Mohan, V., and Ben Othmane, L., “SecDevOps : Is It a Marketing Buzzword ?,” 2016
11th Int. Conf. Availability, Reliab. Secur., pp. 542–547, 2016.
34. Mohan,V., Ben Othmane, L., and Kres, A., “BP: Security concerns and best practices for
automation of software deployment processes: An industrial case study,” Proc. - 2018
IEEE Cybersecurity Dev. Conf. SecDev 2018, pp. 21–28, 2018.
35. Moore, M. G. and Bovoso A. L. “DevSecOps Embedded Security Within the Hyper
Agile Speed of DevOps What is Dev Sec Ops ? A transformational shift which
incorporates secure culture , practices , and tools to drive visibility ,.” 2018.
36. Myrbakken, H., & Colomo-Palacios, R. (2017, October). DevSecOps: a multivocal
literature review. In International Conference on Software Process Improvement and
Capability Determination (pp. 17-29). Springer, Cham.
37. “Nosprawl.” [Online]. Available: https://www.zoominfo.com/c/nosprawl-inc/368636279.
[Accessed: 26-Sep-2019].
38. “Parasoft.” [Online]. Available: https://www.parasoft.com/. [Accessed: 26-Sep-2019].
39. “Qualys.” [Online]. Available: https://www.qualys.com/. [Accessed: 26-Sep-2019].
40. Rahman, A. A. U. and Williams, L., “Security practices in DevOps,” pp. 109–111, 2016.
41. Rahman, A. A. U. and Williams, L., “Software security in DevOps: Synthesizing
practitioners’ perceptions and practices,” Proc. - Int. Work. Contin. Softw. Evol. Deliv.
CSED 2016, pp. 70–76, 2016.
42. Rai, R., Sahoo, G., & Mehfuz, S. (2015). Exploring the factors influencing the cloud
computing adoption: a systematic study on cloud migration. SpringerPlus, 4(1), 197.
43. Raynaud,F., “DevSecOps Whitepaper,” 2017.
44. “Redgate.” [Online]. Available: https://www.red-gate.com/. [Accessed: 26-Sep-2019].
45. “Rogue Wave.” [Online]. Available: https://www.roguewave.com/. [Accessed: 26-Sep-
2019].
46. “Sonatype’s Nexus.” [Online]. Available: https://www.sonatype.com/product-nexus-
repository. [Accessed: 26-Sep-2019].
47. “Sumo logic.” [Online]. Available: https://www.sumologic.com/. [Accessed: 26-Sep-
2019].
48. Storms, A., “How Security can be the Next Force Multiplier in DevOps,” pp. 1–37,
2015.
49. Synopsis, “DevSecOps Realities and Opportunities,” 2018, April.
50. “Synopsys.” [Online]. Available: https://www.synopsys.com/. [Accessed: 26-Sep-2019].
51. Taibi, D., Lenarduzzi, V., & Pahl, C. (2017). Processes, motivations, and issues for
migrating to microservices architectures: An empirical investigation. IEEE Cloud
Computing, 4(5), 22-32.
52. “ThreatModeler.” [Online]. Available: https://threatmodeler.com/. [Accessed: 26-Sep-
2019].
53. “WhiteHat Security.” [Online]. Available: https://www.whitehatsec.com/. [Accessed: 26-
Sep-2019].
54. “WhiteSource.” [Online]. Available: https://www.whitesourcesoftware.com/. [Accessed:
26-Sep-2019].
55. Wootton.B, and Erkunt. E, “Introduction to DevSecOps Best Practices for Adoption.” ,
Contino, 2018.

You might also like