In this chapter, the authors define the main problems when working on products in DevOps Teams and on CI/CD pipelines with regard to security and risk management. It focusses on the regulatory requirements and cyberthreats that have impact on organisations. Regulator requirements vary from industry and country. Working with multiple teams on products requires proper alignment in frameworks, controls, and architecture principles in order to be end-to-end protected throughout the connected platforms. This chapter examines the multiple compliance frameworks and architectural principles that can be applied to agile way of working and more precise to CICD pipelines. It defines the main problem statement and questions the authors wanted to answer. The authors looked with a lens of regulated industry since this industry suffers the most and therefore has the biggest benefit from this research project.
TopIntroduction
Figure 1. Waterfall vs Agile software development method (Derksen, October 2018).
TopConcepts Of Ci/Cd And (Sec)Devops
The beginning of 2000 is a starting point of the creation of a novel software development methodology, known as Agile. The term officially appears for the first time in 2001 in The Agile Manifesto (Fowler, 2001), a publication by a group of software professionals, which covers the twelve principles of agile software development. These principles were the consequence of frustration that started to appear in industry a decade before, as the result of growing software complexity, increasing speed of technological evolution and the inability of the traditional Waterfall method to cope with the new reality. As stated by Murray (Murray, 2015), the effect of Moore’s Law is all around us. Not only computing power is doubled every 18 months, but chips get smaller, cell phones get more powerful and flat screen TV’s get cheaper. If a software project takes 18 months to deliver, you’ve missed an entire Moore’s Law cycle, because the business specifications were written 18 months ago.
The Waterfall approach is considered as a traditional way of managing software development. It consists of consecutive phases leading to the development of a complete software product. The phases are summarized in Figure 1 (Derksen, October 2018):
- •
Define: collect software requirements
- •
Build: design the solution, code the software, test and debug the software
- •
Release: deliver the finished product and enter maintenance mode
The main disadvantages of this approach are (1) the need for complete detailed requirements to be known upfront, before the start of software development, and (2) the fact that the software product is only seen when the development is completed. It means that the project cannot take off before all the requirements are collected, and often the product is delivered after a long development process to only discover that the requirements were incomplete or misinterpreted.
Figure 2. DevOps toolchain (Gartner)
The Agile approach is the extreme opposite of the original sequential software development. It values early and continuous software delivery; changing requirements; close collaboration between business, customers and developers; and face-to-face communication as an alternative for extensive documentation. Figure 1 shows a graphical representation of a typical Agile software development cycle, where the project is split into short iterations. There is a deliverable and a feedback loop at the end of each iteration.
But also the Agile methodology has its drawbacks. For instance, detailed planning and cost estimation are major pain points. Since the requirements are refined after each iteration, it is very difficult to predict the scope and the outcome in advance and it is almost impossible to indicate how much it is going to cost to achieve a certain output. Therefore, Agile is better suited for projects with the following characteristics (Murray, 2015):
- •
Small and not too complex
- •
Constant availability of stakeholder to refine requirements
- •
Few complex impetrations and dependencies
- •
Leadership accepting planning and cost uncertainties
- •
Need for very fast time-to-market
At the same time, activities such as integrations, software and security architecture are often assumed to require a full overview and rigorous up-front planning to guarantee robustness and fewer security holes. The lack of certainty regarding these aspects can, in my experience, disqualify Agile for many organisations.