We started off this course by looking at how we could use user secrets to prevent sensitive password information from being saved into the repository with the source code. Then we had a look at the App Configuration Service as a central and secure repository for your application settings. App Configuration has filtering mechanisms such as labels and also uses namespace format to allow you to have settings for multiple applications and multiple sections within an application. App Configuration also supports feature flags, which are very important if you're using a release flow deployment strategy.

It has a mechanism called a Sentinel key which your application can monitor for changes, and when it sees a change in that particular key, which doesn't necessarily have to be called Sentinel, it knows to update all the settings and re-pull them without you having to restart your application. App Configuration also seamlessly integrates with Azure DevOps pipelines so you can pull settings directly into your application from App Configuration Service and you can set up a key within App Configuration that references a secret within your Azure Key Vault by giving your app configuration access to the Azure Key Vault.

You can also replace settings in your DevOps pipeline with secrets from the Azure Key Vault. We had quite a detailed look at how you can use managed identities and access secrets from within your Key Vault to use in container apps that will be running on an Azure Kubernetes cluster. We also saw how a secure development build pipeline might look when you are wanting to deploy code and an image to a Kubernetes cluster using secure keys to enforce security between your pipeline, your container registry, and your production cluster.

Next, we looked at other elements that are needed to make up a compliant pipeline, and the concept of DevSecOps and shifting your security left from the deployment end of the pipeline. We started with the integrated development environment, specifically Visual Studio, and saw how we can download extra code analyzer packages to complement the existing Roslyn code analyzer. We can inspect and customize the rules within the code analyzer, and by making the customized rule sets part of the source code, those rules will remain with the project and be incorporated into the build pipeline.

Third-party code analyzers, such as SonarCloud, support a wide variety of languages. SonarCloud can be integrated into the Azure DevOps pipeline via an extension from the marketplace. We saw how we can implement branch policies to prevent the merging of poor quality code. SonarCloud quality gates integrate with the branch policy and we can specify whether a build is valid or not. Open-source libraries, while useful and great time savers, have their own set of issues. This ranges from accepting any vulnerability within the library into your own project and possible fishhooks with the open source license.

WhiteSource Bolt is an extension from the Azure DevOps marketplace that allows you to integrate open source library scanning into your build pipeline. It reports on known security issues and which type of license pertains to each library. Finally, we saw how to incorporate passive penetration testing into your build pipeline, and how you could schedule active or aggressive penetration testing during down times.