FoD: Error if starting DAST scan with fod dast-scan start if scan is already running

[kadraman]

Current Behavior

The DAST Automated API does not handle queiring of scan requests, so if a DAST scan is requested whilst one is running, the following error is produced:

Run fcli fod dast-scan start --release "${FOD_RELEASE_NAME}" --store curScan --session github-actions
com.fortify.cli.common.rest.unirest.UnexpectedHttpResponseException: 
Request: POST https://api.ams.fortify.com/api/v3/releases/1012126/dast-automated-scans/start-scan: 
Response: 422 Unprocessable Entity
Response Body:
{"errors":[{"errorCode":-10,"message":"A dynamic scan is currently in progress for this application in release main. A scan cannot be created for this release at this time."}]}
	at com.fortify.cli.common.rest.unirest.config.UnirestUnexpectedHttpResponseConfigurer$UnexpectedHttpResponseInterceptor.onResponse(UnirestUnexpectedHttpResponseConfigurer.java:36)
	at kong.unirest.CompoundInterceptor.lambda$onResponse$1(CompoundInterceptor.java:48)
	at java.base@21.0.2/java.util.ArrayList.forEach(ArrayList.java:1596)
	at kong.unirest.CompoundInterceptor.onResponse(CompoundInterceptor.java:48)
	at kong.unirest.apache.ApacheClient.request(ApacheClient.java:[134](https://github.com/fortify-presales/IWA/actions/runs/9938511500/job/27451483046#step:4:141))
	at kong.unirest.Client.request(Client.java:57)
	at kong.unirest.BaseRequest.request(BaseRequest.java:365)
	at kong.unirest.BaseRequest.asObject(BaseRequest.java:266)
	at com.fortify.cli.fod._common.scan.helper.dast.FoDScanDastAutomatedHelper.startScan(FoDScanDastAutomatedHelper.java:46)
	at com.fortify.cli.fod.dast_scan.cli.cmd.FoDDastAutomatedScanStartCommand.startScan(FoDDastAutomatedScanStartCommand.java:39)
	at com.fortify.cli.fod._common.scan.cli.cmd.AbstractFoDScanStartCommand.getJsonNode(AbstractFoDScanStartCommand.java:36)
	at com.fortify.cli.fod._common.output.cli.cmd.AbstractFoDJsonNodeOutputCommand.getJsonNode(AbstractFoDJsonNodeOutputCommand.java:23)
	at com.fortify.cli.common.output.cli.cmd.AbstractOutputCommand.call(AbstractOutputCommand.java:33)
	at com.fortify.cli.common.output.cli.cmd.AbstractOutputCommand.call(AbstractOutputCommand.java:22)
	at picocli.CommandLine.executeUserObject(CommandLine.java:2118)
	at picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2538)
	at picocli.CommandLine$RunLast.handle(CommandLine.java:2530)
	at picocli.CommandLine$RunLast.handle(CommandLine.java:2492)
	at picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2350)
	at picocli.CommandLine$RunLast.execute(CommandLine.java:2494)
	at picocli.CommandLine.execute(CommandLine.java:2247)
	at com.fortify.cli.app.runner.DefaultFortifyCLIRunner.run(DefaultFortifyCLIRunner.java:49)
	at com.fortify.cli.app.FortifyCLI.execute(FortifyCLI.java:38)
	at com.fortify.cli.app.FortifyCLI.main(FortifyCLI.java:32)
	at java.base@21.0.2/java.lang.invoke.LambdaForm$DMH/sa346b79c.invokeStaticInit(LambdaForm$DMH)
Error: Process completed with exit code 1.

Expected Behavior

We can either fail gracefully by detecting this error or wait until the scan can be started.

However, it would be better if the DAST Automated endpoints supported queueing like the DAST ones.

Steps To Reproduce

No response

Environment

No response

Anything else?

No response

[rsenden]

Not too familiar with DAST scanning; would this likely be a new scan request with exact same target and parameters, or could this be a completely different scan request? If the latter, there's not much that we can do, other than possibly improving the error message and filing an FoD enhancement request to support queuing for DAST scans.

If it's likely the exact same scan request, and FoD API allows for identifying that a scan is already running, and FoD can return similar properties as when starting a new scan, we could potentially (maybe optionally) have this command return a regular scan record with status like 'ALREADY_RUNNING'. The pipeline could then wait for completion of the existing scan; as long as it's the same target and scan parameters, it may not matter much whether that scan was already started before.

Alternatively, again if FoD provides the necessary endpoints, we could provide an option to cancel the existing scan before trying to start a new scan.

Maybe we could just add a single fcli option like --if-scan-running=cancel-existing|continue-with-existing|error (we'll likely want to think about better/shorter option and value names), if we can implement all of these based on existing FoD endpoints? Or maybe something like --existing-scan=cancel|reuse and if this option is not specified, throw an error if a scan is already running.