Security and Compliance

As important as it is to ensure that your application performs the functions it needs to, you also need to ensure it doesn't do things that it shouldn't. In the previous chapter, you learned about quality and testing in order to continuously measure whether your application is doing what it is supposed to do. In this chapter, you will learn how to prevent any unwanted behavior. This is the subject of security and compliance. While increasing the flow of value to your end users—by deploying faster and shortening delivery cycles—you will still want to make sure that you are delivering secure and compliant software. In this chapter, you will learn how to address these concerns in your DevOps processes.

To do this, this chapter will start by discussing the perceived trade-off between speed and security, and it will explain how security...

Technical requirements

To experiment with the techniques described in this chapter, you will need one or more of the following:

• An Azure DevOps project with access to build and release pipelines and the right to install extensions
• An Azure subscription. (To sign up for Azure, you can go to https://portal.azure.com and follow the guide there if you do not have an account yet)
• PowerShell with the PowerShell Azure module installed. (Instructions on how to install the PowerShell Azure module can be found at https://docs.microsoft.com/en-us/powershell/azure/install-az-ps?view=azps-4.1.0)
• Optionally, subscriptions for WhiteSource Bolt, SonarCloud, or similar products

The preceding are all available, for free or as a trial, for learning or evaluation purposes.

Applying DevOps principles to security and compliance

Concerns about security and compliance can be a reason for companies to be reluctant to accept a full DevOps mindset, in order to ship software often and quickly. In the past, they used to have fewer releases that were all handed off for a security or pen test before being deployed to production. This gave them the confidence that they were not shipping software that contained security vulnerabilities.

This practice of fewer releases and having a big final security test before the final release conflicts with a DevOps mindset, and this is where some companies struggle. They are looking for ways to ensure that they are shipping business value to their users but are not willing to compromise on security to do so. The question is whether this is a fair trade-off. Wouldn't it be possible to have both speed and security? Might...

Working with secrets

An important security element is the handling of secrets. When deploying an application, there are always secrets involved. Especially when deploying to the cloud, that is, over the internet, handling these access keys in a secure way is very important. Besides the secrets that are necessary for deployment, there are also secrets that need to be inserted into the runtime configuration of an application. A common example is for accessing the database.

In Chapter 6, Infrastructure and Configuration as Code, multiple mechanisms for delivering application configurations were discussed, including Azure Resource Manager (ARM) templates. However, templates require the input of external secrets, since they cannot be stored in parameter files in source control.

Secrets should not be stored in source control.

If secrets cannot be stored in source control, then where...

Detecting application code vulnerabilities

The security assessments that are often conducted at regular intervals in the pre-DevOps era cannot be just left out when moving to a DevOps culture. This means that, instead of leaving them out, they must be conducted in some other way. There are two approaches for doing this.

The first approach is to keep doing pen tests, security reviews, and other security inspections at regular intervals just as before. However, instead of waiting for an OK from the tests before moving to production, the code is deployed to production separate from the security assessment(s). This implies that there is an accepted risk that there might be vulnerabilities shipped to production that are found only during the next security scan and will be addressed in the next release. Using this approach, it is possible to achieve speed, but then it also needs to...

Working with dependencies

Next to the security risks that the application code developed in-house pose, there is also a risk associated with components that are reused. Between 50% and 80% of modern application code is not developed in-house, but is taken from other parties in the form of packages or dependencies. Some of these might be open source, but this is not necessarily the case. There can also be components that are bought from other development companies or binaries taken from galleries such as NuGet.

Dependencies not only pose security risks, but also licensing risks. What happens if a team starts using a component that is published under the GPL license for a closed source component? If anyone ever finds out, they can be forced to open source their product, or at least suffer public shame for not using the work of others according to the license.

To mitigate these risks...

Ensuring infrastructure compliance

Another important topic is that of compliance. In many countries or markets, there are sets of rules and policies that must be implemented or adhered to when creating software. A fair share of these policies relates to the infrastructure that the applications are running on. If this infrastructure is deployed and managed on the Azure platform, Azure Policy can be a powerful tool for ensuring that the infrastructure complies with regulations.

In Chapter 6, Infrastructure and Configuration as Code, the topic of ARM templates was discussed. ARM templates can be viewed as a technique for describing a complete Azure environment as a JSON array with many objects, each describing one resource in an application's infrastructure.

Azure Policy allows you to write policies that query this document and the changes that are being made through any of...

Monitoring and detecting runtime security risks and threats

All of the security tools that have been discussed up to this point have focused on preventing shipping vulnerable code to production environments. However, the complete, deployed software solution, including all its support infrastructure is made out of so much more than just the code. On top of that, there are many interactions with a solution that may be unexpected or unplanned. Monitoring all of this continuously in production is necessary, not just to prevent security concerns but to also detect any security concerns coming up. In Azure, one of the tools available for doing just that is Azure Security Center. Azure Security Center is offered via the Azure portal and can be selected as any other service using the menu on the left or by searching for it in the top bar.

After opening Security Center, something similar...

Other tools you can use

There are many tools available on the market for performing security scans of application code and dependencies. Some examples include WhiteSource, Black Duck, Veracode, and Checkmarx.

WhiteSource is the paid version of WhiteSource Bolt. It offers the same services and more. For example, it doesn't only report risks at the time of the dependency scan; it also gives you alerts when new risks become available for dependencies that were present in the last scan of an application.

Black Duck is a product that helps teams to manage the risks associated with using open source software. The services it offers are comparable to WhiteSource.

Veracode and Checkmarx are code scanning tools that are used to identify vulnerable code. Whereas SonarQube checks both the code quality and security risks, these two products focus solely on security risks. In general...

Summary

In this chapter, you have learned that DevOps and security are not two conflicting goals, but that DevOps practices can help you to reinforce security. First, you learned how to handle passwords and other secrets when working with continuous deployment pipelines. Next, you learned how to enhance your pipelines with code and dependency scanning tools, applying the shift-left principle to security as well. Finally, you learned how to use Azure Policy to define constraints and rules for your infrastructure and how you can have these automatically applied or have non-compliant deployments audited or automatically denied.

With the knowledge you have gained, you are now able to have a conversation within your company about how to address security concerns within your DevOps teams. You can cooperate with security engineers to configure the tools you work with and receive automated...

Questions

Here is a list of questions for you to test your knowledge regarding this chapter's material. You will find the answers in the Assessments section of the Appendix:

1. True or False: Securing the delivery of software is just a single step in a deployment pipeline.
2. Which tool can be used for security testing, where a proxy is used to identify valid application URLs and then perform different attacks, such as injections on an application?
3. True or False: In most modern applications, over 50% of the code base comes from open source libraries.
4. What are the secure locations for storing the secrets needed during deployment or for running an application? (You can choose more than one answer.)
   1. Azure Pipelines variables that are marked as secret
   2. Azure Key Vault
   3. Azure DevOps Key Vault
   4. Azure Variable Groups
   5. Azure DevOps Secure Variables
   6. Azure DevOps Service Connection
5. Which...

Further reading

• The OWASP Top 10 and the details of every type of risk can be found at https://www.owasp.org/index.php/Top_10-2017_Top_10.
• WhiteSource Bolt can be found on the Azure DevOps marketplace at https://marketplace.visualstudio.com/items?itemName=whitesource.ws-bolt.
• A detailed walk-through on using the OWASP ZAP can be found at https://devblogs.microsoft.com/premier-developer/azure-devops-pipelines-leveraging-owasp-zap-in-the-release-pipeline/.

• More information about the Azure Policy resource types and JSON specifications can be found as part of the ARM reference at https://docs.microsoft.com/en-us/azure/templates/microsoft.authorization/allversions.
• More information about the continuous delivery tools for Visual Studio can be found at https://marketplace.visualstudio.com/items?itemName=VSIDEDevOpsMSFT.ContinuousDeliveryToolsforVisualStudio.
• More information about...