Integrate SC-SAST/SC-DAST functionality into SSC module

[rsenden]

Enhancement Request

With the current command structure, users and CI/CD integrations potentially need to run three session login (and logout) commands; they need to create an SC-SAST/SC-DAST session to be able to submit scan requests and wait for scan completion, and then create an SSC session to access the results of those scans.

Also, current structure is not ideal if we implement pipeline-style actions (#549) that cover packaging, submitting scan requests, and exporting results. As described above, such a pipeline-style action would need to manage both SC-SAST (or SC-DAST) and SSC sessions, and we'd need to decide where such actions should live; fcli sc-sast action run scan or fcli ssc action run sast-scan (or both).

We can easily create an SSC command structure that's similar to FoD command structure, for example having commands like:

• fcli ssc sast-scan list/start/wait-for/...
• fcli ssc sast-sensor list/shutdown/...
• fcli ssc dast-scan list/start/wait-for/...
• fcli ssc dast-sensor list/...

To avoid this resulting in a major fcli release, we could potentially just leave the existing sc-sast and sc-dast modules in place (just adding a deprecation notice), and only remove those modules upon the next major fcli release.

Primary difficulty is session management:

• For interacting with SC-SAST controller, we need the static client-auth-token. We can handle this in multiple ways:
  • Have an optional --client-auth-token option on fcli ssc session login; of course SC-SAST commands would throw an error if no client auth token was specified upon login
  • Allow the client auth token to be statically configured through fcli ssc config or fcli config commands
  • Have an explicit --client-auth-token option on every command that needs to interact with SC-SAST Controller
  • Have users store the client-auth-token somewhere in SSC in such a way that all users/token types can retrieve the token, for example application version attribute or, to avoid duplication across many app versions, maybe misuse some other configurable SSC item to store the token, like an invalid custom variable or performance indicator.
  • Ideally, SC-SAST/SSC should allow for the client-auth-token to be configured on SSC, such that fcli can simply retrieve the token from SSC, or even better, SC-SAST should get rid of client-auth-token altogether and instead integrate with SSC access management (see internal fcli-product-issues spreadsheet).
• When submitting an SC-SAST scan request, an SSC token must be provided that remains valid until after the scan has completed and published to SSC. If the user supplies an existing token on the fcli ssc session login command, we can simply use that. If the user supplies user credentials:
  • We currently generate a UnifiedLoginToken, which gets revoked upon session logout; this is not suitable for submitting SAST scan requests as the token may expire or be revoked before the scan has been published to SSC.
  • We could generate both UnifiedLoginToken (for general fcli usage) and a CIToken upon session login, and cache this outside of the session (i.e., shouldn't be revoked on session logout, and to avoid exceeding SSC token limits, we don't want to generate a new token on every login if a previously generated token hasn't expired yet)
  • We could potentially use a longer-lived AutomationToken for both general fcli usage and for submitting SAST requests (but again, we can't revoke this token on session logout if it's been used for submitting scan requests)
  • Utilize some of the same mechanisms as discussed for client-auth-token above; pass token explicitly on scan start command, store token somewhere in SSC, ...
  • Ideally, SC-SAST/SSC should implement a mechanism for publishing scan results that's not based on a client-provided token, such that token revocation/expiry doesn't affect SC SAST capability to publish results (see internal fcli-product-issues spreadsheet).
• For SC-DAST, we currently generate a CIToken when user logs in using username/password, to allow for slightly longer-lived session, but such a CIToken will not provided access to all SSC functionality. We could choose to simply use the UnifiedLoginToken that's used for other SSC commands, or utilize AutomationToken to allow for longer-lived sessions. With the latter, we need to keep in mind that AutomationToken is not available on older SSC versions.

[MikeTheSnowman]

Heyr @rsenden , I just wanted to add my thoughts to the discussion.

• I'm not in favor of fcli needing to support the client-auth-token for SC-SAST. A permenant pre-shared key is a really poor security mechanism and if I remember correctly, I think the SC-SAST engineers are also planning on getting rid of it as well. Maybe we can simply wait for them to produce a replacement for the client-auth-token?
• Because I'm not in favor of supporting the client-auth-token, this also means that we won't be able to fully support older versions of SC-SAST. I'm rather okay with that as it's less technical debt and it incentivize users to upgrade.
• I'm not 100% sure I'm on-board with the idea of consolidating the SC-DAST and SC-SAST command structures into SSC. Yes, I know that we were able to manage consolidating SAST, DAST, MAST, and SCA/OSS commands into FoD... But this resulted in FoD (only in my opinion) having a less than optimal command structure. I would like to raise for consideration the possibility of keeping the existing command structure, but simply having the SC-SAST and SC-DAST modules rely on the sessions generated by the SSC module.
• Finally, given the APIs that are available, I'm in favor of your idea to generate two API tokens. One short-lived token with lots of permissions, and another token that's long-lived with fewer permissions. The ideal scenario that I can think of is to dynamically generate (and cache) revokable, long-lived, tokens with the minimum required permissions needed to complete the execution for a long running fcli command. But with the current APIs available, this isn't possible.

[rsenden]

Hi @MikeTheSnowman, thanks for your input.

Unfortunately, there's no clear plan/ETA if/when SC-SAST will get rid of the client-auth-token, so until then, we have no other choice than to support this token. As a temporary work-around, I've proposed an SSC enhancement to allow the client-auth-token to be stored in SSC, allowing any (REST) client like fcli to retrieve this token (potentially restricted through a new SSC role permission). This way, assuming the user has the proper SSC rights, fcli could retrieve the client-auth-token from SSC instead of requiring the user to specify the client-auth-token token on the fcli sc-sast session login command.

The primary reason for not sharing SSC sessions with SC-SAST module is again due to the client-auth-token, as an SSC session (currently) has no knowledge about the required client-auth-token. For consistency, we're also not sharing SSC sessions with SC-DAST module, having each product module being responsible for its own sessions. Once we can somehow get rid of the requirement for users to explicitly specify the client-auth-token, we can reconsider this.

As for actual command structure, I'm open to both approaches; either integrate SC-SAST/SC-DAST commands into SSC module (to be more consistent with FoD module), or keeping separate sc-sast and sc-dast modules that share their sessions with SSC.