## Problem When an analyzer fails to output a SARIF file, we print an error `open /tmp/[analyzer].sarif: no such file or directory`. This is what people report, but it can mask a number of other issues. ## Proposal When a SARIF file can't be found, we should help people along the first step of debugging by printing a friendlier error log, perhaps: ``` Error: SARIF file not found. This usually means the analyzer crashed before saving its report. To debug, please set the SECURE_LOG_LEVEL CI variable to "debug". See https://docs.gitlab.com/ee/user/application_security/#secure-job-failing-with-exit-code-1. ``` ## Other alternatives - Grab logs from the subprocess and print them all out if we detect an error. - More? ## Context This issue arises from https://gitlab.com/gitlab-org/gitlab/-/issues/351711#note_910425914: > I agree that this situation occurs when we don't get an output from `kics`, though we'll potentially see it anywhere where we use a SARIF output and convert it. In short, the module responsible for converting SARIF to our internal JSON format assumes the output file will be there, and it doesn't gracefully handle the situation where that contract is broken. This also confused a customer in https://gitlab.zendesk.com/agent/tickets/293570: "We shouldn't be expected to have a `semgrep.sarif` file in the root of our app repo". ## Implementation detail When the analyzer operation fails with `SECURE_LOG_LEVEL` CI variable's value being `info`(default) then it logs the following message informing users to enable `debug` mode to know more insights for debugging: ``` Analyzer has exited with error: <message>. To debug, set 'SECURE_LOG_LEVEL' CI variable to "debug". See https://docs.gitlab.com/ee/user/application_security/#secure-job-failing-with-exit-code-1 for more details. ``` More discussion on this decision made [here](https://gitlab.com/gitlab-org/gitlab/-/issues/359392#note_946606980).