You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What is the scenario you are trying to achieve? GitHub Advanced Security (GHAS) currently supports consumption of SARIF from various tools. This Action runs specific tools and the resulting SARIF is published to Security tab (part of GHAS)
What is the scenario you are trying to achieve? GitHub Advanced Security (GHAS) currently supports consumption of SARIF from various tools. This Action runs specific tools and the resulting SARIF is published to Security tab (part of GHAS)
I have heard it is possible to include SARIF files from other tools, but I'm not able to find any clear documentation about it. It may seem that I could use the PublishBuildArtifacts@1 task and ensure I publish the files to CodeAnalysisLogs/msdo.sarif, but I'm not sure if these only can be viewed in ADO or if they also will be available in Defender for Cloud.
In this case Azure DevOps with Defender for Cloud and Defender for DevOps is used. Scenarios that I want to achieve are:
Add detection of other types of secrets that those defined by MS if you use GHAS for ADO. This is possible if you use GitHub, but not ADO. Therefore a third party tool is needed.
Add DAST capabilities and incude those results in Defender for Cloud. For example run a weekly scan with Zap and publish those results.
This scenario is already supported — it just was not discoverable. The action has an existingFilename input that takes a SARIF file produced by any tool and uploads it to the MSDO backend instead of running the analyzers. It has been declared in action.yml for some time but appeared in no documentation, which is the actual gap here.
- name: Run a third party scannerrun: my-scanner --sarif-output results.sarif
- name: Publish existing SARIFuses: microsoft/security-devops-action@latestwith:
existingFilename: results.sarif
Two behaviors to be aware of, both now written down: this must be its own step, because setting existingFilename skips the analyzer run entirely, and it does not set the sarifFile output — to also surface the file in the Security tab, pass it to github/codeql-action/upload-sarif directly.
That covers the Snyk, Trivy, Prisma Cloud, Semgrep, gitleaks and Dockle cases in the original report, and the ADO + Defender for Cloud scenarios raised in the thread.
Activity
sukhans commentedon Jan 31, 2023
What is the scenario you are trying to achieve? GitHub Advanced Security (GHAS) currently supports consumption of SARIF from various tools. This Action runs specific tools and the resulting SARIF is published to Security tab (part of GHAS)
kimsyversen commentedon Mar 13, 2024
I have heard it is possible to include SARIF files from other tools, but I'm not able to find any clear documentation about it. It may seem that I could use the PublishBuildArtifacts@1 task and ensure I publish the files to CodeAnalysisLogs/msdo.sarif, but I'm not sure if these only can be viewed in ADO or if they also will be available in Defender for Cloud.
In this case Azure DevOps with Defender for Cloud and Defender for DevOps is used. Scenarios that I want to achieve are:
Is this possible, and if yes, how is this solved?
DimaBir commentedon Jul 28, 2026
Documentation for this is up in #272.
This scenario is already supported — it just was not discoverable. The action has an
existingFilenameinput that takes a SARIF file produced by any tool and uploads it to the MSDO backend instead of running the analyzers. It has been declared inaction.ymlfor some time but appeared in no documentation, which is the actual gap here.Two behaviors to be aware of, both now written down: this must be its own step, because setting
existingFilenameskips the analyzer run entirely, and it does not set thesarifFileoutput — to also surface the file in the Security tab, pass it togithub/codeql-action/upload-sarifdirectly.That covers the Snyk, Trivy, Prisma Cloud, Semgrep, gitleaks and Dockle cases in the original report, and the ADO + Defender for Cloud scenarios raised in the thread.