As mentioned previously, secrets should not be stored in source control, which is why the capabilities discussed earlier are available. Still, a developer can, by accident or for local testing, write down secrets in the application source code.

To ensure that these secrets do not end up in source control, a local plugin can be used to detect secrets and emit a warning to alert the developer to this risk. One tool that can do this for Visual Studio is the Continuous Delivery Tools for Visual Studio extension. This extension scans any open file for secrets and emits a compiler warning when it detects a possible secret. A link to this extension is added to the references at the end of this chapter. After running the installer, any secret it detects in Visual Studio will result in a compiler warning. Unfortunately, at the time of writing, the extension does not yet support Visual Studio 2019.

In addition to this, it is advised that you run a similar tool as part of the delivery pipelines to identify any secrets that have accidentally been checked in. Even though it will be too late to keep the secret secure, it does provide a clear signal that the secret is compromised and needs to be changed. One tool that can do this is CredScan. CredScan is a build task that is part of the Microsoft Security Code Analysis Extension build task.

A link to the details of this extension is available at the end of this chapter; it also includes all of the installation details. Please note that the extension is only available under certain conditions and is not free.

Once the extension has been installed, CredScan can be added to your pipeline, as shown here:

Perform these steps while referring to the annotations in the screenshot:

1. Add the Run Credential Scanner task to the pipeline.
2. Update the Tool Major Version to V2. For all of the other options, the default settings are good enough for a first scan.
3. If there have been previous scans that result in one or more false positives, they can be removed from the results by pointing to a suppressions file.
4. Add the Create Security Analysis Report task to the pipeline.
5. Add the Publish Security Analysis Logs task to the pipeline.
6. Add the Post Analysis task to the pipeline.
7. Save and queue the build definition.

While some tasks fail and cancel the build when an error is detected, the CredScan task does not. It will always complete successfully, even if passwords are detected. Only the Post Analysis task at the end of the build will act on discovered problems and fail the build if there are any issues found. The advantage of this is that all issues are identified, not only the first one. It also allows any other tasks you want to run to be completed.

The security analysis reporting task (step 4) is used to gather the logs of the different scanning tools that are part of the suite and combine the output into CSV and HTML files. The publishing task (step 5) publishes all of the generated files as a build artifact. If a possible password is detected, the following HTML will be generated and published as a build artifact:

This concludes our discussion of secrets and how to keep them secure in a DevOps pipeline. The next section covers the detection of application vulnerabilities.