Effective scan configurations for asset scans

[pbalogh-sa]

Problem Statement

It would be nice if the used scanner configurations were stored alongside with the asset scans.
With this feature, the config will be available in the case of the standalone mode.

Proposed Solution

Need to define a new object for the effective scanner config (e.g. EffectiveScannerConfig). This object should be a part of AssetScan.

AssetScan:
  type: object
  allOf:
    - type: object
      properties:
        id:
          type: string
        revision:
          type: integer
        asset:
          $ref: '#/components/schemas/AssetRelationship'
            ...
    - $ref: '#/components/schemas/AssetScanTemplate'
    - $ref: '#/components/schemas/EffectiveScanConfig'

EffectiveScanConfig:
   type: object
   properties:
     effectiveScanFamiliesConfig:
       $ref: '#/components/schemas/EffeciveScanFamiliesConfig'

EffeciveScanFamiliesConfig:
  type: object
  description: The configuration of the scanner families within a scan config
  properties:
    sbom:
      $ref: '#/components/schemas/ExtendedSBOMConfig'
    vulnerabilities:
      $ref: '#/components/schemas/ExtendedVulnerabilitiesConfig'
    ...
          
EffectiveSBOMConfig:
  type: object
  properties:
    enabled:
      type: boolean
    analyzers:
      type: array
      items:
        type: string
    inputs:
      type: array
      items:
        $ref: '#/components/schemas/Input'
   scanerConfig:
     .... actual families config struct

Alternatives Considered

We can extend the ScanFamiliesConfig that part of the AssetScanTemplate

ScanFamiliesConfig:
  type: object
  description: The configuration of the scanner families within a scan config
  properties:
    sbom:
      $ref: '#/components/schemas/SBOMConfig'
    vulnerabilities:
      $ref: '#/components/schemas/VulnerabilitiesConfig'
   ....

And instead of:

SBOMConfig:
  type: object
  properties:
    enabled:
      type: boolean
    analyzers:
      type: array
      items:
        type: string

Use this

SBOMConfig:
  type: object
  properties:
    enabled:  
      type: boolean
    analyzers:
      type: array
      items:
        type: string
    inputs:
      type: array
      items:
        $ref: '#/components/schemas/Input'
   scanerConfig:
     .... actual families config struct

In this case we have to patch the ScanFamiliesConfig with the effective configurations.

[Tehsmash]

We have the user facing scan configuration in the ScanFamiliesConfig, this is (and should be) a sub-set of the possible vmclarity-scanner/cli configuration and can even have abstract concepts that the CLI will never know about.

When the orchestrator runs a scan it is the provider that is responsible for creating the scan yaml config. If automount in the CLI is enabled this can modify the configuration further at run time.

This "real" or "effective" configuration is what we want to push back to the API to see what the scanner/cli actually ran. Similarly when a user configures the CLI/scanner for CI/CD what they configured the CLI can't necessarily be converted directly back to the ScanFamiliesConfig, and probably shouldn't be because it wasn't an orchestrated flow, so in this case it'll also use this new field.

The UI should be updated to display both the configured ScanFamiliesConfig and what the AssetScan ran using this new field and not the ScanFamiliesConfig.

My only major concern with going this route is that it ties the scanning API objects to the vmclarity-cli configuration. Today there is no requirement for a provider to use the vmclarity-cli to scan the target system, as long as they can configure whatever they are scanning according to the user's ScanFamiliesConfig and export the results back in the correct format. I think we need to determine if we want the API to remain abstract and if so then the "Effective" configuration needs to be abstract too.

[chrisgacsal]

After having an offline chat with @Tehsmash we come up with a solution which we think serve the purpose without expoding the API spec with ScannerConfig specific objects.

The idea is to add a generic annotations field added to all root level objects like ScanConfig, Scan, AssetScan, etc with similarly to what Kubernetes API objects have. It would allow to us to store additional information in objects without extending the API spec. The annotations filed can be used by VMClarity components or external integrations to store additional information which might be relevant only to them.

So in this case the actual ScannerConfig which was used to perform the scan could be stored as a string (in JSON format) using a key like openclarity.io/vmclarity-scanner/config. Any presenter like the WebUI or the CLI (in the future) could use this key to lookup for the actual config in the annotations field.

I will create a separate issue for adding annotations field to the API spec which needs to be implemented prior moving forward with this issue.