Secret scanning doesn't detect any issues

[mykolaichuk]

Hi,

Secret scanning doesn't detect any issues and doesn't see any secrets (even Azure-specific, like storage account connection string).

Does trivy task use build-in rules only?

Please, let me know if extra details are needed.

[JiandongJiang]

Can you describe how you made the configurations? A link to your build would help. Otherwise, the build logs and artifacts could also be helpful (so that we will have more context). Thanks.

[mykolaichuk]

Hi @JiandongJiang

Sorry, I can't provide all the details. I'm attaching the Microsoft Security DevOps task log and pipeline config.

pipeline.txt Microsoft Security DevOps.txt

[mykolaichuk]

@JiandongJiang seems like trivy is used for secrets scanning as far as I can see its default rules set doesn't contain Azure-specific secrets.

[JiandongJiang]

Trivy is a vulnerability/misconfiguration scanner for containers and other artifacts. It can detect vulnerabilities of OS packages and language-specific packages. In addition, it scans IaC files such as Terraform and Kubernetes, to detect potential configuration issues that expose your deployments to the risk of attack. When MSDO runs this tool, it scans a filesystem by default and the default applicable files are dockerfile, Gemfile.lock, Pipfile.lock, poetry.lock, composer.lock, package-lock.json, yarn.lock, Cargo.lock, packages.lock.json, .jar, .war, and *.ear under the running working dir in your repo. If you need secrets scanning, you may want to try the GHAS (GitHub Advanced Security) that might have better support for it.

I took a look at your configs and the build logs. In the build logs, it shows "INFO Number of language-specific files: 0" which seems to indicate that the Trivy tool did not find applicable files to scan (and hence no detection reported if you expect there should be some vulnerabilities detected in your repo by this tool). So, here are some suggestions you may want to try:

1. Make sure there are some applicable files in your repo for Trivy to scan on.
2. Remove the "categories: 'secrets,code'" and "languages: 'dotnet'" from your configs since they are just used to help filter which tools in MSDO are applicable to run in a build (but since you have already specified the Trivy tool in the configs to run in your build, they are not needed).
3. Add an env var GDN_TRIVY_TARGET in your YAML and provide a full directory path as target for the Trivy tool to scan (on a filesystem by default).

Hope it helps.

[mykolaichuk]

Trivy can also scan repository/project for secrets (please, refer to the official documentation). It scans any plain text files, including dotnet appsettings.json. I have added a modified Sendgrid API key to the appsettings.json file and trivy (as a standalone CLI tool) and as a tool within Microsoft Security DevOps task was able to identify it (please, have a look at an attached pipeline log file).

Is there any table for Microsoft Security DevOps task of what type of secrets it can identify like GHAS for Azure DevOps has?

Microsoft Security DevOps.txt

[JiandongJiang]

Thanks @mykolaichuk for the link to a more recent documentation which contains contents with more scan coverage supported by Trivy (the page I referenced seems with kind of obsolete contents). To your question, AFAIK there is not such a table for the Microsoft Security DevOps task that is similar to that listed on GHAS for Azure DevOps.

I took a look at the second build log and compared it with the first build log. It appears that both builds ran Trivy with the same version (0.45.0) and using the same command line (D:\a_msdo\packages\nuget\Microsoft.Guardian.TrivyRedist_windows_amd64.0.45.0\tools\trivy.exe filesystem --exit-code 100 --format sarif --output D:\a\1\s.gdn.r\trivy\001\trivy.sarif), but the first build didn't detect any secrets while the second build did detect one secret. From your previous message, I am not 100% sure about the context you described so would like to check with you about the following to make sure I understand the context correctly:

1. Was the first build scanning your repo with or without Sendgrid API key in the appsettings.json file?
2. For the second build, you mentioned that you added a modified Sendgrid API key to the appsettings.json file and then Trivy could detect that secret as expected. So, it seems to be working now. Is that correct?

If the first question above is the case where a Sendgrid API key (but not modified) was already in the appsettings.json file, then I would be really confused by the Trivy tool behavior (FYI, the MSDO task runs the Trivy tool but doesn't own it). In this case, you can try configuring the env var GDN_TRIVY_TARGET in your YAML to point to the appsettings.json file and then run a new build to see how Trivy will behave.

Please let me know either way. Thanks.

[mykolaichuk]

The pipeline configuration was the same for both runs.

1. The first build was without the Sendgrid API key in the appsettings.json file, indeed.
2. Yes, trivy was able to detect the Sendgrid API key in the second run.

By opening this issue I wanted to flag and get confirmation from you that Microsoft Security DevOps task uses trivy with its build-in rules set, meaning that Azure-specific secrets (like Storage account connection string, Azure SQL connection strings and other Azure services) won't be detected. I apologize for the confusion.

So, are there any plans to make secret detection more effective in a Microsoft Security DevOps task?

[JiandongJiang]

Thanks for the confirmation. That clarifies it.

Yes, the MSDO task uses Trivy with its build-in rules as of now. Previously, the MSDO task by default included the CredScan tool as the Secret Scanning/Detection option which provides better detection on secrets, e.g., Azure-specific secrets. But, effective September 20th, 2023, the Secret Scanning option (CredScan) within Microsoft Security DevOps (MSDO) Extension for Azure DevOps is deprecated. MSDO Secret Scanning is replaced by the Configure GitHub Advanced Security for Azure DevOps features offering. Due to that, there is no current plan to make secret detection more effective in a Microsoft Security DevOps task.