Skip and Enforce Checks

To help you achieve compliance and quality across your organization, Spotter allows you to centrally control which Ansible checks to skip and which to always enforce across all your automation workflows.

That means you can apply rules for all users from a single point of configuration or decide to skip some rules you find redundant. For example, if Spotter finds a potential risk, which you assess and accept, you can decide to skip it from now on, and it won’t keep ‘bothering’ you about it. With Spotter, you’re always in control. See DEMO or read blog .

When skipping or enforcing checks, you can supply the below three parameters to effortlessly tailor your desired level of check control to bypass or reinforce specific checks or sub-checks for a targeted Fully Qualified Collection Name (FQCN):

event: the event code of the check result (e.g., W2600);

subevent_code: check subcode (e.g., B324);

FQCN: fully qualified collection name (e.g., amazon.aws.cloudformation).

Check refinements are possible on three levels:

Organization Level

Establish the basic rules and apply checks across the whole organization. Any checks enforced at this level can’t be ignored when scanning, and any checks that are skipped at the organization level will take precedence over the enforced ones.

Sample of an org-config.json file:

  {
    "skip_checks": [
     {
       "event": "W003",
       "fqcn": "ansible.builtin.uri" 
     } 
    ], 
    "enforce_checks": [
     {
       "event": "E005", 
       "fqcn": "community.crypto.x509_certificate" 
     }
   ] 
  }
        

You use the config set command to upload it and config clear to clear it.

Interested in the current settings for a specific organization? Simply use the config get command to see the current setup:

Scan Level

Fine-tune your scans to meet specific requirements. Checks enforced on scan level cannot be skipped on task level and checks skipped on scan level will override enforced checks on scan level.

On this level, you can skip checks primarily through a configuration file. Whether it’s your project’s personalized .spotter.json, .spotter.yml, or .spotter.yaml file, or a configuration file conveniently provided via the optional --config CLI argument, you’re in control.

Example of spotter.yml config file:

  skip_checks: 
    - event: W003 
      fqcn: ansible.builtin.uri 
    - event: E601 
      fqcn: community.crypto.x509_certificate
  enforce_checks: 
    - event: E005 
    - event: E903
    

It is also possible to effortlessly skip or enforce checks using optional arguments tailored to your needs. Envision seamlessly excluding any checks tied to Ansible module deprecations and redirections or enforce all checks that are related to the use of with_items. This becomes reality through our --skip-checks and --enforce-checks optional arguments, allowing you to specify the exact checks to skip or enforce by their designated IDs (e.g., E1300).

You can also skip or enforce checks for specific Fully Qualified Class Names (FQCNs) or even individual check subcodes by using the pattern: event[fqcn=<fqcn>, subevent_code=<subevent_code>] .

Task Level

Refine checks at the task level to suit individual tasks and scenarios. While you can’t enforce checks on this level, you have the freedom to skip them as needed. You can exercise control within the Ansible content itself. You can use the “noqa” (NO Quality Assurance) YAML comments at the end of any line within your Ansible task using the pattern: # noqa: event[fqcn=<fqcn>, subevent_code=<subevent_code>] , offering unrivaled precision and flexibility.

Example of skipping checks on task level:

 ---
 - name: Sample playbook with comments 
   hosts: localhost
   tasks:
     - name: Get tpayload from the API # noqa: W003, E903 
       uri: 
         url:some-url" 
         method: GET 
         user: "username1"       &nbcommunity.crypto.x509_certificate: # noqa: E601[fqcn=community.crypto.x509_certificate] 
       path: "{{ config_path certificates/server.crt" 
       privatekey_path: "{{ config_path }}/certificates/server.key"
   &nbsnbsp;  provider: assertonly