> For the complete CircleCI developer hub index, see [llms.txt](https://circleci.com/developer/llms.txt)

# apollo/circleci-secops-orb

Apollo SecOps Circle orb


## Commands

### circleci-stop-if-no-github-auth

Helper command which will `halt` the entire execution of a running `job` if github authentication credentials are not available.
Circle's "when" conditions are great, but you could use this as a pre-step in a workflow to avoid executing a job

| Parameter | Type | Default | Description |
|---|---|---|---|
| `do-when` | string | on_success | Value passed to "when" parameter on jbo. Useful to let job run even after a prior step failed. |

### github-bot-custom-stop-delete-comment

Implements custom logic for the SecOps orb to clear previous bot comments from Security scan results if they're no longer needed


| Parameter | Type | Default | Description |
|---|---|---|---|
| `bot-making-comments` | string |  | name of the bot making all these comments |
| `comment-empty-results` | boolean | false | If true, will comment messages on PRs indicating that no findings were found. Useful if you want positive confirmation that things are good. |
| `do-pr-comments` | boolean | true | If False, disables all PR comments from this check |
| `do-when` | string | on_success | Value passed to "when" parameter on job. Useful to let job run even after a prior step failed |
| `really-delete-comments` | boolean | true |  |
| `title` | string |  | delete comments that start with this header |

### gitleaks-check-local

Run Gitleaks against a local repository.


| Parameter | Type | Default | Description |
|---|---|---|---|
| `base-branch` | string | none | The name of the default branch for the repository |
| `comment-empty-results` | boolean | false | If true, will comment messages on PRs indicating that no findings were found. Useful if you want positive confirmation that things are good. |
| `git-base-revision` | string |  | The commit hash of the earliest commit to be scanned |
| `git-revision` | string |  | The commit hash of the latest commit to be scanned |
| `options` | string |  | Additional options to pass to the Gitleaks CLI |
| `path` | string | ${CIRCLE_WORKING_DIRECTORY} | Path to local Git repository |

### gsm-get-secret

Retrieves a secret from Google Secret Manager (GSM) and either sets it as environment variable or writes it to a file in the current executor.
Expects the gcloud cli to be available and to have already authenticated with a user that has access to the requested secret.


| Parameter | Type | Default | Description |
|---|---|---|---|
| `fail-if-not-found` | string | true | If true, this command will fail if the requested secret is not found. If false and the secret is not found,
the value returned for the requested secret will be "NOT_FOUND_ERR"
 |
| `gcp-project` | string | default | The GCP project containing the secret to be retrieved. If left as its default value, will obtain
this value from the GCP_PROJECT_ID environment variable.
 |
| `secret` | string |  | The name of the secret to be retrieved from GSM |
| `target` | string | env:GSM_SECRET | The location where the retrieved secret value should be written. This value can take two forms:
  - `env:VARIABLE_NAME`: in this form, the secret value will be set as an environment variable of name "VARIABLE_NAME". Change the variable name as needed.
  - `file:/tmp/secret.txt`: in this form, the secret value will be written as a file at /tmp/secret.txt. Change the file name as needed.
 |
| `version` | string | latest | The version of the secret to retrieve |

### osvscan-check-local

Run osv-scanner against a local repository.

osv-scanner checks for vulnerabilities in dependencies by comparing package versions in lockfiles
to vulnerability databases. This job reports on those findings and additionally checks for related,
existing pull requests in Github that appear to resolve the identified vulnerability.

osv-scanner will recursively search for the following lockfiles to scan for vulnerabilities:
buildscript-gradle.lockfile, Cargo.lock, composer.lock, conan.lock, Gemfile.lock, go.mod, gradle.lockfile,
mix.lock, package-lock.json, packages.lock.json, Pipfile.lock, pnpm-lock.yaml, poetry.lock, pom.xml,
pubspec.lock, requirements.txt, and yarn.lock. Additional lockfile formats may be added in the future.
See https://github.com/google/osv-scanner#input-a-lockfile for the most up-to-date list.

By default, this job will fail builds if 1 or more critical-severity vulnerabilities is identified
in lockfiles. This behavior can be overridden via the fail-on-findings and min-fail-severity
parameters.


| Parameter | Type | Default | Description |
|---|---|---|---|
| `comment-empty-results` | boolean | false | If true, will comment messages on PRs indicating that no findings were found. Useful if you want positive confirmation that things are good. |
| `fail-on-findings` | boolean | true | Indicate if this check should fail if there are any findings >= min-fail-severity |
| `min-fail-severity` | enum | CRITICAL | The minimum severity of finding that will cause builds to fail. |
| `path` | string | ${CIRCLE_WORKING_DIRECTORY} | Path to local Git repository |

### semgrep-check-local

Run Semgrep against a local repository.

Semgrep supports scanning all of the common languages in use at Apollo including Kotlin, Java, Typescript, Javascript, Rust, Python, etc.
See https://semgrep.dev/docs/supported-languages/ for the list of all supported languages. Languages labelled "Beta" or "Experimental"
on the linked page are supported. The differences between these support levels are mainly in the number of semgrep-internal features currently
supported for the language and the number of open-source rules available for the language.

This command will not break builds if an unsupported language is present in the repo being scanned. Rulesets are enabled based on
the files in the repository and rules are only executed on files that contain code in supported languages.

The rules Semgrep executes are versioned here: https://github.com/mdg-private/semgrep-scan/tree/main/rules. SecOps regularly
fetches new rules from open-source respositories of high-quality Semgrep rules. Apollo engineers are encouraged to open PRs on the
linked repo to contribute new rules as desired.


| Parameter | Type | Default | Description |
|---|---|---|---|
| `comment-empty-results` | boolean | false | If true, will comment messages on PRs indicating that no findings were found. Useful if you want positive confirmation that things are good. |
| `disabled-signatures` | string |  | A comma-separated list of signatures that you would like to disable |
| `do-diff-scan` | boolean | true | Set to False if you want to scan all files in the repo, not just changed files. |
| `fail-on-findings` | boolean | true | Indicate if this check should fail if there are any findings >= min-fail-severity |
| `git-base-revision` | string |  | The commit hash of the earliest commit to be scanned |
| `min-fail-severity` | enum | ERROR | The minimum severity of finding that will cause builds to fail. |
| `options` | string |  | Additional options to pass to the Semgrep CLI |
| `path` | string | ${CIRCLE_WORKING_DIRECTORY} | Path to local Git repository |
| `run-bestpractice-checks` | boolean | false | If true, add best practice / code-style rules to the list of checks that semgrep performs |
| `run-security-checks` | boolean | true | If true, add security rules to list of checks that semgrep performs |
| `update-rules` | boolean | true | Set to true if rules should be updated prior to scanning. Else, scanning uses the rules built into the executor.
Rules are updated from https://github.com/mdg-private/semgrep-scan/tree/main/rules
 |

### wiz-docker-check-local

Test docker containers against SecOps-defined rules for misconfigurations.


| Parameter | Type | Default | Description |
|---|---|---|---|
| `comment-empty-results` | boolean | false | If true, will comment messages on PRs indicating that no findings were found. Useful if you want positive confirmation that things are good. |
| `container-dir` | string |  | The path in the executor where container tarfiles are located. |
| `fail-on-findings` | boolean | true | Indicate if this check should fail if there are any findings >= min-fail-severity |
| `wiz-policies` | string | Apollo-Default-Vulnerabilities-Policy | One or more Wiz IAC policies to use during this scan. If specifying multiple, they should be comma-separated |

### wiz-iac-check-local

Test infrastructure-as-code against SecOps-defined rules for misconfigurations.


| Parameter | Type | Default | Description |
|---|---|---|---|
| `comment-empty-results` | boolean | false | If true, will comment messages on PRs indicating that no findings were found. Useful if you want positive confirmation that things are good. |
| `do-diff-scan` | boolean | true | Set to False if you want to scan all files in the repo, not just changed files. |
| `fail-on-findings` | boolean | true | Indicate if this check should fail if there are any findings >= min-fail-severity |
| `path` | string | ${CIRCLE_WORKING_DIRECTORY} | Path to local Git repository |
| `wiz-policies` | string | Apollo-Default-IAC-Policy | One or more Wiz IAC policies to use during this scan. If specifying multiple, they should be comma-separated |

## Jobs

### gitleaks

Clone a Git repo and check it for secrets.


| Parameter | Type | Default | Description |
|---|---|---|---|
| `base-branch` | string | none | The name of the default branch for the repository |
| `bot-making-comments` | string | apollo-bot2 | The bot commenting on PRs |
| `comment-empty-results` | boolean | false | If true, will comment messages on PRs indicating that no findings were found. Useful if you want positive confirmation that things are good. |
| `do-alert-secops` | string | true | Allows users of this job to control whether or not alerts are sent to the Apollo SecOps team when secrets are detected in code being scanned. |
| `do-gcp-auth` | boolean | true | When true, this job will authenticate to GCP prior to running the gitleaks scan. This is done so that alerting and reporting can be generated. This relies on some supporting configuration within GCP like GCP Workload Identity, so it can be toggled off via a config option. |
| `do-pr-comments` | boolean | true | If False, disables all PR comments from this check |
| `gcp-service-account-email` | string | ci-reporting@secops-354017.iam.gserviceaccount.com | If the do-gcp-auth parameter is true, use this to set the email of the service account to be used via GCP Workload Identity. This is default-ed to an Apollo-specific account to simplify internal integration. |
| `git-base-revision` | string |  | The commit hash of the earliest commit to be scanned. Use this field to pass in CircleCI's pipeline.git.base_revision parameter if it exists. |
| `git-default-base-revision` | string | HEAD~1 | The commit hash of the earliest commit to be scanned. Use this field to pass in a fallback if CircleCI's pipeline.git.base_revision parameter doesn't exist. |
| `git-revision` | string |  | The commit hash of the latest commit to be scanned |
| `options` | string |  | Additional options to pass to the Gitleaks CLI |
| `pr-title` | string | Detected Secrets | Title text for the PR Comment |

### osvscan

Check application dependencies for vulnerabilities

osv-scanner checks for vulnerabilities in dependencies by comparing package versions in lockfiles
to vulnerability databases. This job reports on those findings and additionally checks for related,
existing pull requests in Github that appear to resolve the identified vulnerability.

osv-scanner will recursively search for the following lockfiles to scan for vulnerabilities:
buildscript-gradle.lockfile, Cargo.lock, composer.lock, conan.lock, Gemfile.lock, go.mod, gradle.lockfile,
mix.lock, package-lock.json, packages.lock.json, Pipfile.lock, pnpm-lock.yaml, poetry.lock, pom.xml,
pubspec.lock, requirements.txt, and yarn.lock. Additional lockfile formats may be added in the future.
See https://github.com/google/osv-scanner#input-a-lockfile for the most up-to-date list.

By default, this job will fail builds if 1 or more critical-severity vulnerabilities is identified
in lockfiles. This behavior can be overridden via the fail-on-findings and min-fail-severity
parameters.


| Parameter | Type | Default | Description |
|---|---|---|---|
| `bot-making-comments` | string | apollo-bot2 | The bot commenting on PRs |
| `comment-empty-results` | boolean | false | If true, will comment messages on PRs indicating that no findings were found. Useful if you want positive confirmation that things are good. |
| `do-pr-comments` | boolean | true | If False, disables all PR comments from this check |
| `fail-on-findings` | boolean | true | Indicate if this check should fail if there are any findings >= min-fail-severity |
| `min-fail-severity` | enum | CRITICAL | The minimum severity of finding that will cause builds to fail. |
| `pr-title` | string | Detected Dependency Vulnerabilities | Title text for the PR Comment |

### semgrep

Perform security and (optionally) best-practice tests on source.

Semgrep supports scanning all of the common languages in use at Apollo including Kotlin, Java, Typescript, Javascript, Rust, Python, etc.
See https://semgrep.dev/docs/supported-languages/ for the list of all supported languages. Languages labelled "Beta" or "Experimental"
on the linked page are supported. The differences between these support levels are mainly in the number of semgrep-internal features currently
supported for the language and the number of open-source rules available for the language.

This job will not break builds if an unsupported language is present in the repo being scanned. Rulesets are enabled based on
the files in the repository and rules are only executed on files that contain code in supported languages.

The rules Semgrep executes are versioned here: https://github.com/mdg-private/semgrep-scan/tree/main/rules. SecOps regularly
fetches new rules from open-source respositories of high-quality Semgrep rules. Apollo engineers are encouraged to open PRs on the
linked repo to contribute new rules as desired.

The default values for the parameters on this job represent SecOps' recommended configuration for long-term
implementation in pipelines and for new projects utilizing this job from the start. If you use the default options for
all non-required parameters, this job will run security tests for the languages identified in the repo being scanned. Languages
present are identified via a combination of filenames and file extensions in the repo. By default this job will operate in a 'diff-aware'
mode which only scans files modified via the commit(s) in a given branch. By default, this job will fail builds if a
finding with severity "ERROR" (read: critical) is found. The combination of these defaults means that jobs will fail if an ERROR-level finding
is introduced in any branch implementing the default values for this check. Pre-existing issues will not be identified or fail builds provided
they exist in files not being modified in the branch.

The goal of the default behavior is to help engineers identify issues early before they are deployed - even to Dev environments. Security
vulnerabilities are generally cheaper and easier to fix the earlier they are found.

This is *strongly* discouraged, but in the event that a team MUST deploy code that contains a vulnerability blocking builds, teams have several options
to silence this job without removing it from their pipeline. Teams can add comments to lines introducing the vulnerability to indicate Semgrep should ignore
the line (details documented here: https://apollographql.atlassian.net/wiki/spaces/SecOps/pages/81330213/Everything+Static+Application+Security+Testing).
Teams can additionally utilize the 'disabled-signatures' parameter on this job to turn specific rules off in the pipeline. The value(s) that need to be
added to this parameter are displayed in both output formats described below. Signatures will usually start with 'rules.providers.semgrep'

SecOps recommends that teams do not use the default configuration for their initial addition of this job into existing repos. SecOps recommends
that initial integration sets 'fail-on-findings' and 'do-diff-scan' to 'false'. Setting fail-on-findings to false will prevent this job from
failing builds. Setting do-diff-scan to false will run Semgrep against all files in the repo, not just files being changed. This combination of settings
will let teams see all findings that _could_ be generated from the repo while ensuring that builds will not fail. As teams address ERROR-level findings
on the repo, they can ratchet the configurations back toward default.

Output from this job is written to two locations. For a tabular view of results, see the 'Results' step of this job. If teams utilize
SecOps' recommended initial deployment configuration for existing repos above, they can see which findings _would_ have failed the build but didn't
due to fail-on-findings being set to false in the tabular view. A JSON-formatted report of all findings is also uploaded to the
scan-results/semgrep.json build artifact.


| Parameter | Type | Default | Description |
|---|---|---|---|
| `bot-making-comments` | string | apollo-bot2 | The bot commenting on PRs |
| `comment-empty-results` | boolean | false | If true, will comment messages on PRs indicating that no findings were found. Useful if you want positive confirmation that things are good. |
| `disabled-signatures` | string |  | A comma-separated list of rules that you would like to disable |
| `do-diff-scan` | boolean | true | Set to False if you want to scan all files in the repo, not just changed files. |
| `do-pr-comments` | boolean | true | If False, disables all PR comments from this check |
| `fail-on-findings` | boolean | true | Indicate if this check should fail if there are any findings >= min-fail-severity |
| `git-base-revision` | string |  | The commit hash of the earliest commit to be scanned. Use this field to pass in CircleCI's pipeline.git.base_revision parameter if it exists. |
| `git-default-base-revision` | string | HEAD~1 | The commit hash of the earliest commit to be scanned. Use this field to pass in a fallback if CircleCI's pipeline.git.base_revision parameter doesn't exist. |
| `min-fail-severity` | enum | ERROR | The minimum severity of finding that will cause builds to fail. |
| `options` | string |  | Additional options to pass to the Semgrep CLI |
| `pr-title` | string | Detected SAST Vulnerabilities | Title text for the PR Comment |
| `run-bestpractice-checks` | boolean | false | If true, add best practice / code-style rules to the list of checks that semgrep performs |
| `run-security-checks` | boolean | true | If true, add security rules to list of checks that semgrep performs |
| `update-rules` | boolean | true | Set to true if rules should be updated prior to scanning. Else, scanning uses the rules built into the executor.
Rules are updated from https://github.com/mdg-private/semgrep-scan/tree/main/rules
 |

### wiz-docker

Test docker containers against SecOps-defined rules for misconfigurations.

Wiz is a security tool owned by the SecOps team to monitor for vulnerabilities, misconfigurations, errors, and incidents
occurring in Apollo's public cloud environments.

Wiz provides the ability to scan built Docker containers for vulnerabilities. Use this job to assess containers
as you're building them in your pipeline to ensure the container doesn't contain vulnerabilities that should
be fixed before the container is used in production. SecOps manages the policy used to determine if jobs should pass/fail
based on the vulnerabilities found. You can ensure jobs will never fail (regardless of SecOps policy) via the
fail-on-findings parameter.

Note that this job relies on your container being built already. You will need to tell CircleCI about
this dependency via the 'requires' keyword.

To pass the built container into this orb, you will need to save the built container as a tar and use CircleCI workspaces to
present the tar to this job. This job will scan a tar file containing a docker image saved to <workspace>/container/<name>.tar.
This directory should contain exactly one tar.

See this job's usage information for an example of building a container, saving it to a tar, exporting it to a workspace,
and running this job to scan it.

Results from this scan are printed to stdout as part of the execution of the job. Additionally, scan results
are uploaded as a build artifact to this job.


| Parameter | Type | Default | Description |
|---|---|---|---|
| `bot-making-comments` | string | apollo-bot2 | The bot commenting on PRs |
| `comment-empty-results` | boolean | false | If true, will comment messages on PRs indicating that no findings were found. Useful if you want positive confirmation that things are good. |
| `container-dir` | string | /tmp/workspace/container | The path in the executor where container tarfiles are located. |
| `do-pr-comments` | boolean | true | If False, disables all PR comments from this check |
| `fail-on-findings` | boolean | true | Indicate if this check should fail if there are any findings that violate Wiz policy |
| `pr-title` | string | Detected Container Vulnerabilities | Additional name to identify comments on GitHub PRs |
| `wiz-policies` | string | Apollo-Default-Vulnerabilities-Policy | One or more Wiz IAC policies to use during this scan. If specifying multiple, they should be comma-separated |

### wiz-iac

Test infrastructure-as-code against SecOps-defined rules for misconfigurations.

Wiz is a security tool owned by the SecOps team to monitor for vulnerabilities, misconfigurations, errors, and incidents
occurring in Apollo's public cloud environments.

Wiz provides the ability to scan IAC files like terraform documents, dockerfiles, etc. to identify vulnerabilities
that will be introduced if the IAC file is executed. Use this job to prevent vulnerabilities from being introduced
via IAC. SecOps manages the policy used to determine if jobs should pass/fail based on the vulnerabilities found.
You can ensure jobs will never fail (regardless of SecOps policy) via the fail-on-findings parameter.

Results from this scan are printed to stdout as part of the execution of the job. Additionally, scan results
are uploaded as a build artifact to this job.


| Parameter | Type | Default | Description |
|---|---|---|---|
| `bot-making-comments` | string | apollo-bot2 | The bot commenting on PRs |
| `comment-empty-results` | boolean | false | If true, will comment messages on PRs indicating that no findings were found. Useful if you want positive confirmation that things are good. |
| `do-diff-scan` | boolean | true | Set to False if you want to scan all files in the repo, not just changed files. |
| `do-pr-comments` | boolean | true | If False, disables all PR comments from this check |
| `fail-on-findings` | boolean | true | Indicate if this check should fail if there are any findings >= min-fail-severity |
| `pr-title` | string | Detected IaC Vulnerabilities | Additional name to identify comments on GitHub PRs |
| `wiz-policies` | string | Apollo-Default-IAC-Policy | One or more Wiz IAC policies to use during this scan. If specifying multiple, they should be comma-separated |

## Executors

### gitleaks-ci

Use containerized Gitleaks to check the repository for secrets.


### osvscan-ci

Use containerized osv-scan to check the repository for vulnerabilities.


### semgrep-ci

Use containerized Semgrep to check the repository for vulnerabilities.


### wiz-ci

Use containerized wizcli to check the repository for vulnerabilities.


## Examples

### using-gitleaks

An example of using gitleaks in your workflow to test code for secrets


```yaml
version: '2.1'
orbs:
  secops: apollo/circleci-secops-orb@2.0.0
workflows:
  check-for-secrets:
    jobs:
      - secops/gitleaks:
          context:
            - platform-docker-ro
            - github-orb
            - secops-oidc
          git-base-revision: >-
            <<#pipeline.git.base_revision >><<pipeline.git.base_revision
            >><</pipeline.git.base_revision >>
          git-revision: << pipeline.git.revision >>
```

### using-osvscan

An example of using osv-scanner in your pipelines to check for vulnerabilities in dependencies.
osv-scanner checks for vulnerabilities in dependencies by comparing package versions in lockfiles to vulnerability databases. This job reports on those findings and additionally checks for related, existing pull requests in Github that appear to resolve the identified vulnerability.
osv-scanner will recursively search for the following lockfiles to scan for vulnerabilities: buildscript-gradle.lockfile, Cargo.lock, composer.lock, conan.lock, Gemfile.lock, go.mod, gradle.lockfile, mix.lock, package-lock.json, packages.lock.json, Pipfile.lock, pnpm-lock.yaml, poetry.lock, pom.xml, pubspec.lock, requirements.txt, and yarn.lock. Additional lockfile formats may be added in the future. See https://github.com/google/osv-scanner#input-a-lockfile for the most up-to-date list.
By default, this job will fail builds if 1 or more critical-severity vulnerabilities is identified in lockfiles. This behavior can be overridden via the fail-on-findings and min-fail-severity parameters.


```yaml
version: '2.1'
orbs:
  secops: apollo/circleci-secops-orb@1.0.0
workflows:
  check-for-vulns:
    jobs:
      - secops/osvscan:
          context:
            - platform-docker-ro
            - github-orb
```

### using-semgrep

An example of using semgrep in your workflow to test code for vulnerabilities.
Semgrep supports scanning all of the common languages in use at Apollo including Kotlin, Java, Typescript, Javascript, Rust, Python, etc. See https://semgrep.dev/docs/supported-languages/ for the list of all supported languages. Languages labelled "Beta" or "Experimental" on the linked page are supported. The differences between these support levels are mainly in the number of semgrep-internal features currently supported for the language and the number of open-source rules available for the language.
This job will not break builds if an unsupported language is present in the repo being scanned. Rulesets are enabled based on the files in the repository and rules are only executed on files that contain code in supported languages.
The rules Semgrep executes are versioned here: https://github.com/mdg-private/semgrep-scan/tree/main/rules. SecOps regularly fetches new rules from open-source respositories of high-quality Semgrep rules. Apollo engineers are encouraged to open PRs on the linked repo to contribute new rules as desired. Rules can also be written for non-security usecases like enforcing best practice and code style.


```yaml
version: '2.1'
orbs:
  secops: apollo/circleci-secops-orb@2.0.5
workflows:
  check-for-vulns:
    jobs:
      - secops/semgrep:
          context:
            - github-orb
            - secops-oidc
          git-base-revision: >-
            <<#pipeline.git.base_revision >><<pipeline.git.base_revision
            >><</pipeline.git.base_revision >>
          git-revision: << pipeline.git.revision >>
```

### using-wiz-docker

An example of using Wiz Docker scanning in your pipeline to check for vulnerabilities.
Wiz is a security tool owned by the SecOps team to monitor for vulnerabilities, misconfigurations, errors, and incidents occurring in Apollo's public cloud environments.
Wiz provides the ability to scan built Docker containers for vulnerabilities. Use this job to assess containers as you're building them in your pipeline to ensure the container doesn't contain critical vulnerabilities that should be fixed before the container is used in production.
Note that this job relies on your container being built already. You will need to tell CircleCI about this dependency via the 'requires' keyword.
To pass the built container into this orb, you will need to use CircleCI workspaces. This job will scan a tar file containing a docker image saved to <workspace>/container/<name>.tar. This directory should contain exactly one tar.
A simple example of building the container, saving it to a tar file, exporting it to a workspace, and scanning the container is provided below.


```yaml
version: '2.1'
orbs:
  secops: apollo/circleci-secops-orb@1.0.0
workflows:
  build-and-scan-container:
    jobs:
      - run:
          command: mkdir -p /tmp/workspace/container
          name: Set up Workspace directory
      - run:
          command: >
            echo "$(date +%Y).$(date +%m).b$CIRCLE_BUILD_NUM" >
            stable_build_number.txt
          name: Make a Docker Tag
      - run:
          command: |
            export IMAGE_TAG=$(cat stable_build_number.txt)
            docker build \
              -t registry/MY_CONTAINER_NAME:$IMAGE_TAG \
              -f Dockerfile .
          name: Build Container
      - run:
          command: |
            export IMAGE_TAG=$(cat stable_build_number.txt)
            docker save -o /tmp/workspace/container/MY_CONTAINER_NAME.tar \
              registry/MY_CONTAINER_NAME:$IMAGE_TAG
          name: Save Container for Analysis
      - persist_to_workspace:
          paths:
            - container/MY_CONTAINER_NAME.tar
          root: /tmp/workspace
      - secops/wiz-docker:
          context:
            - platform-docker-ro
            - wiz
          requires:
            - Build Container
```

### using-wiz-iac

An example of using Wiz Infrastructure-as-Code (IAC) scanning in your pipeline to check for vulnerabilities.
Wiz is a security tool owned by the SecOps team to monitor for vulnerabilities, misconfigurations, errors, and incidents occurring in Apollo's public cloud environments.
Wiz provides the ability to scan IAC files like terraform documents, dockerfiles, etc. to identify vulnerabilities that will be introduced if the IAC file is executed. Use this job to prevent vulnerabilities from being introduced via IAC.


```yaml
version: '2.1'
orbs:
  secops: apollo/circleci-secops-orb@1.0.0
workflows:
  security-scans:
    jobs:
      - secops/wiz-iac:
          context:
            - platform-docker-ro
            - github_orb
            - wiz
```