The rest of this chapter will introduce a number of security concerns, but it is helpful to realize that some of the previous chapters have also introduced security concerns already. As you already know from software development, security is not just something that you add in one place. Security should be applied everywhere. The following diagram shows different activities surrounding the creation and delivery of software. Next to each activity, the applicable security concerns are shown:

Let's walk through a quick recap of the security concerns at each of these stages:

• Branch-master merge: At this stage, the four-eyes principle is applied using pull requests. Pull requests allow another engineer to review the changes before they are merged into the master branch. Branch policies are used to make the use of pull requests mandatory, to ensure that the code compiles and that the unit tests run. This was discussed in Chapter 2, Everything Starts with Source Control, and Chapter 3, Moving to Continuous Integration.
  
• Build: During this stage, a security scan of all source code and third-party dependencies is executed by adding additional tasks to the build pipeline. This prevents security risks from propagating unchecked. We discuss how to do this in this chapter, in the Working with secrets section.

• Release: During the release, approvers can be configured. An approver is a user who has to give their approval before the deployment to a specific stage can continue. Additionally, automated release gates are used to ensure (and further enforce) that certain criteria are met before a release can continue. We discuss how to do this in Chapter 4, Continuous Deployment.
• Deployment environment (target systems): All applications will run on a target environment. This can be on-premises; however, in this book, the focus is on Azure. For runtime security and compliance concerns, this chapter will introduce Azure Policy and Azure Security Center.
• Cross-cutting: All of the preceding points are only useful if there is sufficient access control within the Azure DevOps environment. While this is not in the scope of this book, it is an important angle to cover. Users should have enough rights to do their work, but they should not be able to make unauthorized changes to policies, builds, and deployment processes. Additionally, proper secret management is needed to keep secrets such as certificates, keys, and passwords secure during all phases of the delivery process. How we can do this is also covered in this chapter.

Now, with an understanding of how software and security engineers can come together to work on an application, it is time to address the different aspects of this work in the following sections. The next section will discuss how to handle secrets.