DevOps as a culture has helped a lot in bridging gaps between development and operation organizations. Various practices such as Infrastructure as Code, Continuous Integration and Continuous deployment, etc. have helped teams collaborate better and deliver faster. Majorly all these practices have helped developments and operations to transform a lot but security has still been the last manual gate that has to be passed before the latest changes are available to users.
In a typical CI and CD flow, a code change triggers the build. Successful builds result in artifacts that are a deployable package. Ideally these packages should be ready to be deployed. But before they can be deployed, these packages must go through security review processes by a team commonly known as InfoSec. At times InfoSec reviews can be tedious and may delay the package to be deployed due to some potential vulnerabilities in the package, package lacks some of the organization security requirements or packages using unapproved third-party libraries.
Now in such cases many times security teams raise bugs and recommend fixes at the last gate and this delay the release despite following Agile and DevOps.
A newly coined term DevSecOps advocates these security validation processes to shift left in the application life cycle.
Just like DevOps advocates for effective collaboration between development and operations, DevSecOps intends to include the security team too in this collaboration. The security concerns can be put into consideration right from starting of development. This can be done by communicating best security practices to developers, organizational security practices, and enable them with tools to easily recognize areas in code where these practices are being violated.
Here will talk about some of the most common security practices that you can incorporate into development practices and CI CD pipelines.
Code Analysis
Various Code editors such as VS Code can help you by installing static code analyzer extensions such as PsScriptAnalyzer for PowerShell, sonarlint for different programming languages, and Roslyn for C#, etc. These static code analyzers in their favorite code editor or IDE can help developers in getting instant feedback and suggestions right within code editor when rules are being defined in these code analysis tools.
Azure Pipelines also helps with running such analysis tasks within your build pipelines. Putting analysis tasks in pipeline ensures that if developers have followed some non-recommended coding style or ignored the warnings from local code analysis then these will be detected during the build in the continuous integration process and code will not proceed further in the pipeline unless fixed by developers.
Azure Pipeline work with SonarCloud which is one of the most famous static code analyzers for many programming languages. You can install SonarCloud extension from Azure DevOps market place from here https://marketplace.visualstudio.com/items?itemName=SonarSource.sonarcloud
After installing the extension, you can add sonar cloud tasks in your build pipelines. In the following YML pipeline we are using SonarCloud tasks to analyze a .NET Core application.
If you use PowerShell code then PsScriptAnalyzer can help you in scanning your PowerShell code in build pipeline.
PsScriptAnalyzer extension can be installed from https://marketplace.visualstudio.com/items?itemName=sabinio.RunPsScriptAnalyzer
In the following build pipeline we have used PsScriptAnalyzer which is one of the most common code analysis tools for PowerShell.
People managing their Azure Infrastructure as Code with Azure Resource Manager templates can use Secure DevOps Kit (AzSK) CICD Extensions for Azure to scan Azure Resource Manager templates in build pipelines. You can install this extension from here https://marketplace.visualstudio.com/items?itemName=azsdktm.AzSDK-task
After installing the extension you can add it your Infrastruture as Code pipelines to scan ARM templates.
This template checker task scans ARM template in the build pipeline and detects some of the best practices violations in ARM template suggested by Microsoft.
You can download the csv file from the pipeline log to see the rule violation details and suggested fix.
Scanning third party components
Many times developers may use third-party package references in their applications which may have vulnerabilities or in a list of the unapproved packages in the organization. It may happen that the whole feature to be released is dependent on the package reference and if caught late during the final InfoSec review may lead to being dropped from the current release.
Better collaborations with InfoSec during the development stage can avoid such scenarios but this can also be improvised by scanning your code in build pipeline for the packages being used. WhiteSource bolt is one such tool that can help you in such scenarios. You can install WhiteSource bolt extension from Azure DevOps market place from here https://marketplace.visualstudio.com/items?itemName=whitesource.ws-bolt
After installing the extension, you can add the task to the build pipeline to scan the code for packages.
After adding the task to build pipeline, WhiteSource bolt will scan the code on the next run and report the packages being used with various details such as Vulnerabilities, packages license types, outdated packages, etc.
WhiteSource bolt paid version also offers set up policies that can help you in automating whitelisting or blacklisting license types.
Managing Secrets in Pipelines
You may need a few variables during the build in your pipelines. These variables can be simple dynamic values or can be secret information such as connection string, keys, etc. One of the ways is to use variables option in Azure Pipelines to store such values and refer them in pipelines. Azure Pipelines also offers to create variable groups that can be managed on the project level, these variable groups can be linked and can be used in any pipeline in the project.
But you may have few variables that need to be managed outside Azure Pipelines. For example you may have a database connection string that should be managed in an Azure Key vault secret by database team and should not be exposed to people working in Azure Pipelines. Azure Pipelines allows you fetch such values from Azure Key vaults and use it in pipelines task.
The secret fetched from Azure Key vaults can be accessed as variables by referring the secret name.
As we have discussed, Security is a vast domain and mostly every organization may have its own custom security review process and requirements. We have discussed some of the most common things that you may incorporate in these generic use cases. While they may help you get started with what we call DevSecOps, it’s necessary to understand that DevSecOps too is cultural shift about involving security teams much like we have been doing with development and operations in DevOps. Security involvement in early design and development discussions can equip developers and infrastructure teams about Security expectations. Even Security can work together with developments and infrastructure teams to shift those security expectations to development and CI/CD phases.
