We currently retrieve the controller URL from SSC, which works fine in most cases unless the controller URL points to some internal DNS/IP or Kubernetes cluster name that is not accessible from the system where fcli is being run.
We should provide an option on the fcli sc-sast session login command to override the controller URL that's being returned by SSC to allow for correct fcli operation in such scenarios.
Alternatively, we could raise an SSC enhancement request to allow both internal and external controller URL to be configured, in which case fcli could use the external controller URL. This would be the preferred approach, as it would avoid the need to explicitly specify the controller URL on each fcli sc-sast session login invocation.
Enhancement Request
We currently retrieve the controller URL from SSC, which works fine in most cases unless the controller URL points to some internal DNS/IP or Kubernetes cluster name that is not accessible from the system where fcli is being run.
We should provide an option on the
fcli sc-sast session logincommand to override the controller URL that's being returned by SSC to allow for correct fcli operation in such scenarios.Alternatively, we could raise an SSC enhancement request to allow both internal and external controller URL to be configured, in which case fcli could use the external controller URL. This would be the preferred approach, as it would avoid the need to explicitly specify the controller URL on each
fcli sc-sast session logininvocation.This issue was originally raised at https://github.com/fortify/github-action/issues/47, but since the GitHub Action utilizes fcli for SC SAST connectivity, this needs to be fixed in fcli first.