This commit is contained in:
2026-04-07 14:50:23 +09:00
commit b4e485502b
4778 changed files with 2017091 additions and 0 deletions

9
safekiso-server/node_modules/snyk/help/README.md generated vendored Normal file
View File

@@ -0,0 +1,9 @@
# CLI Help files
Snyk CLI Help files are managed by GitBook connected to the [snyk/user-docs](https://github.com/snyk/user-docs) repository.
It's recommended to make all CLI Help changes there. Changes from GitBook are automatically [synced to the Snyk CLI repository with a GitHub Action](https://github.com/snyk/snyk/actions/workflows/sync-cli-help-to-user-docs.yml). The Action creates a PR that needs to be approved and merged. This Action could also be manually triggered.
If you need to make changes tied to a specific PR, you can make them in this repository first, merge the changes and then move them over to the GitBook.
CLI help files are a standard Markdown.

View File

@@ -0,0 +1,73 @@
# CLI help
Snyk CLI scans and monitors your projects for security vulnerabilities and license issues.
For more information visit the [Snyk website](https://snyk.io)
For details see the [CLI documentation](https://docs.snyk.io/features/snyk-cli)
## How to get started
1. Authenticate by running `snyk auth`.
2. Test your local project with `snyk test`.
3. Get alerted for new vulnerabilities with `snyk monitor`.
## Available commands
To learn more about each Snyk CLI command, use the `--help` option, for example, `snyk auth --help`.
**Note:** The help on the docs site is the same as the `--help` in the CLI.
### [`snyk auth`](auth.md)
Authenticate Snyk CLI with a Snyk account.
### [`snyk test`](test.md)
Test a project for open-source vulnerabilities and license issues.
**Note**: Use `snyk test --unmanaged` to scan all files for known open-source dependencies (C/C++ only).
### [`snyk monitor`](monitor.md)
Snapshot and continuously monitor a project for open-source vulnerabilities and license issues.
### [`snyk container`](container.md)
These commands test and continuously monitor container images for vulnerabilities and generate an SBOM for a container image.
### [`snyk iac`](iac.md)
These commands find and report security issues in Infrastructure as Code files; detect, track, and alert on infrastructure drift and unmanaged resources; and create a .driftigore file.
### [`snyk code`](code.md)
The `snyk code test` command finds security issues using Static Code Analysis.
### [`snyk sbom`](sbom.md)
Generate or test an SBOM document in ecosystems supported by Snyk.
### [`snyk log4shell`](log4shell.md)
Find Log4Shell vulnerability.
### [`snyk config`](config.md)
Manage Snyk CLI configuration.
### [`snyk policy`](policy.md)
Display the `.snyk` policy for a package.
### [`snyk ignore`](ignore.md)
Modify the `.snyk` policy to ignore stated issues.
## Debug
Use `-d` option to output the debug logs.
## Configure the Snyk CLI
You can use environment variables to configure the Snyk CLI and also set variables to configure the Snyk CLI to connect with the Snyk API. See [Configure the Snyk CLI](https://docs.snyk.io/features/snyk-cli/configure-the-snyk-cli)

View File

@@ -0,0 +1,55 @@
# snyk apps -- Create and manage your Snyk Apps
# Usage
`snyk apps <COMMAND> [<OPTIONS>]`
## Description
Snyk Apps are integrations that extend the functionality of the Snyk platform. They provide you with an opportunity to mould your Snyk experience to suit your specific needs.
[For more information see our user docs](https://docs.snyk.io/features/integrations/snyk-apps)
## Commands
**_Note: All `apps` commands are only accessible behind the `--experimental` flag and the behaviour can change at any time, without prior notice. You are kindly advised to use all the commands with caution_**
### `create`
Create a new Snyk App.
## Options
### `--interactive`
Use the command in interactive mode.
### `--org=<ORG_ID>`
(Required for the `create` command)
Specify the `<ORG_ID>` to create the Snyk App under.
### `--name=<SNYK_APP_NAME>`
(Required for the `create` command)
The name of Snyk App that will be displayed to the user during the authentication flow.
### `--redirect-uris=<REDIRECT_URIS>`
(Required for the `create` command)
A comma separated list of redirect URIs. This will form a list of allowed redirect URIs to call back after authentication.
### `--scopes=<SCOPES>`
(Required for the `create` command)
A comma separated list of scopes required by your Snyk App. This will form a list of scopes that your app is allowed to request during authorization. You can read more about the allowed scopes in our [docs](https://docs.snyk.io/snyk-apps/getting-started-with-snyk-apps/create-an-app-via-the-api#requesting-scopes).
## Examples
### `Create Snyk App`
\$ snyk apps create --experimental --org=48ebb069-472f-40f4-b5bf-d2d103bc02d4 --name='My Awesome App' --redirect-uris=https://example1.com,https://example2.com --scopes=org.read,org.report.read
### `Create Snyk App Interactive Mode`
\$ snyk apps create --experimental --interactive

View File

@@ -0,0 +1,49 @@
# Auth
## Usage
`snyk auth [<API_TOKEN>] [<OPTIONS>]`
## Description
The `snyk auth` command authenticates your machine to associate the Snyk CLI with your Snyk account.
Running `$ snyk auth` opens a browser window with prompts to log in to your Snyk account and authenticate. No repository permissions are needed at this stage, only your email address.
When you have authenticated, you can start using the CLI; see [Getting started with the CLI](https://docs.snyk.io/snyk-cli/getting-started-with-the-cli)
**Note:** Beginning with version 1.1293, the Snyk CLI uses OAuth when authenticating through the browser.
OAuth provides improved security by issuing shorter-lived expiring authorizations with the convenience of automatic refresh.
Earlier versions of the Snyk CLI (< 1.1293) obtained a non-expiring API token through a legacy browser interaction.
The Snyk API token can still be used as a fallback option. You must explicitly add an option to enable it as follows: `snyk auth --auth-type=token`.
## Options
### `--auth-type=<TYPE>`
Specify the \<TYPE> of authentication to use. Supported types are `oauth` (the default beginning with version 1.1293.0) AND `token`.
### `--client-secret=<SECRET>` and `--client-id=<ID>`
You can set the client secret and the id can be set in order to use the [OAuth2 Client Credentials Grant](https://docs.snyk.io/enterprise-configuration/service-accounts/service-accounts-using-oauth-2.0#oauth-2.0-with-client-secret)
Both values must be provided together. They are only valid together with `--auth-type=oauth;`otherwise they will be ignored.&#x20;
For information about how to get the `<SECRET>` and the `<ID>`, see [Service accounts using OAuth 2.0](https://docs.snyk.io/enterprise-setup/service-accounts/service-accounts-using-oauth-2.0#oauth-2.0-with-client-secret)
## Token value
In some environments and configurations, you must use the `<API_TOKEN>`; see [Authenticate the CLI with your account](https://docs.snyk.io/snyk-cli/authenticate-the-cli-with-your-account)
The value may be a user token or a service account token; see [Service accounts](https://docs.snyk.io/enterprise-setup/service-accounts)
In a CI/CD environment, use the `SNYK_TOKEN` environment variable; see [Configure the Snyk CLI](https://docs.snyk.io/snyk-cli/configure-the-snyk-cli)
After setting this environment variable, you can use CLI commands.
## Debug
Use the `-d` option to output the debug logs.

View File

@@ -0,0 +1,78 @@
# Code test
## Usage
`snyk code test [<OPTIONS>] [<PATH>]`
## Description
The `snyk code test` command tests source code for any known security issues (Static Application Security Testing).
## Exit codes
Possible exit codes and their meaning:
**0**: success (scan completed), no vulnerabilities found\
**1**: action_needed (scan completed), vulnerabilities found\
**2**: failure, try to re-run the command. Use `-d` to output the debug logs.\
**3**: failure, no supported projects detected
## Configure the Snyk CLI
## Debug
Use the `-d` option to output the debug logs.
## Options
### `--org=<ORG_ID>`
Specify the `<ORG_ID>`to run Snyk commands tied to a specific Snyk Organization. The `<ORG_ID>` influences private test limits.
If you have multiple Organizations, you can set a default from the CLI using:
`$ snyk config set org=<ORG_ID>`
Set a default to ensure all newly tested projects are tested under your default Organization. If you need to override the default, use the `--org=<ORG_ID>` option.
Default: `<ORG_ID>` that is the current preferred Organization in your [Account settings](https://app.snyk.io/account)
**Note:** You can also use `--org=<orgslugname>.` The `ORG_ID` works in both the CLI and the API. The Organization slug name works in the CLI, but not in the API.
`orgslugname` must match the slug name as displayed in the URL of your org in the Snyk UI: `https://app.snyk.io/org/[orgslugname]`. The orgname does not work.
For more information see the article [How to select the Organization to use in the CLI](https://docs.snyk.io/snyk-cli/scan-and-maintain-projects-using-the-cli/how-to-select-the-organization-to-use-in-the-cli)
### `--json`
Print results on the console as a JSON data structure.
Example: `$ snyk code test --json`
### `--json-file-output=<OUTPUT_FILE_PATH>`
Save test output as a JSON data structure directly to the specified file, regardless of whether or not you use the `--json` option.
Use to display the human-readable test output using stdout and, at the same time, save the JSON data structure output to a file.
For SAST, if no issues are found, Snyk does not create a `json` file. In contrast, for open-source, Snyk creates a file whether or not issues are found.
Example: `$ snyk code test --json-file-output=vuln.json`
### `--sarif`
Return results in SARIF format.
Example: `$ snyk code test --sarif`
### `--sarif-file-output=<OUTPUT_FILE_PATH>`
Save test output in SARIF format directly to the \<OUTPUT_FILE_PATH> file, regardless of whether or not you use the `--sarif` option.
Use to display the human-readable test output using stdout and, at the same time, save the SARIF format output to a file.
### `--severity-threshold=<low|medium|high>`
Report only vulnerabilities at the specified level or higher.
**Note**: The Snyk Code configuration issues do not use the `critical` severity level.

View File

@@ -0,0 +1,13 @@
# Code
## Description
The `snyk code test` command finds security issues using Static Code Analysis.
For more information, see [CLI for Snyk Code](https://docs.snyk.io/snyk-cli/scan-and-maintain-projects-using-the-cli/using-snyk-code-from-the-cli)
## `snyk code` command and the help docs
The single`snyk code` command is identified here with the help options:
[`code test`](code-test.md); `code test --help`: Test source code for any known security issues (Static Application Security Testing).

View File

@@ -0,0 +1,50 @@
# Config environment
**Note:** This command will be available as of CLI version 1.1293.0.
If you are not in the system default environment, SNYK-US-01, use the `snyk config environment` command to set your environment before you run `snyk auth`.
## Usage
`snyk config environment <ENVIRONMENT>`
## Description
The `snyk config environment` command is provided for your convenience to make changing the endpoint used in the CLI easier and safer.
The outcome is almost the same as `snyk config set endpoint=<URL>` but in addition, the `snyk config environment` command does the following:
- Supports aliases for environments to avoid the use of full URLs
- Performs basic checks to avoid ambiguous or unexpected configuration
- Clears existing authentication and organization settings, which are expected to be environment-specific
## Debug
Use the `-d` option to output the debug logs.
## Option
`--no-check`
Skip the basic checks for ambiguous or unexpected configuration.
Use only if the reported configuration issues are intentional and can be ignored. Otherwise, the configuration might not work as expected.
## Supported environment URLs mappings
- default => https://api.snyk.io&#x20;
- SNYK-US-01 => https://api.snyk.io&#x20;
- SNYK-US-02 => https://api.us.snyk.io&#x20;
- SNYK-AU-01 => https://api.au.snyk.io&#x20;
- SNYK-EU-01 => https://api.eu.snyk.io&#x20;
- SNYK-GOV-01 => https://api.snykgov.io
## Examples
```
snyk config environment default
snyk config environment SNYK-EU-01
snyk config environment SNYK-AU-01
snyk config environment SNYK-AU-01 --no-check
snyk config environment https://api.eu.snyk.io
```

View File

@@ -0,0 +1,69 @@
# Config
## Usage
`snyk config <SUBCOMMAND> [<OPTIONS>]`
## Description
The `snyk config` command manages your local Snyk CLI config file, a JSON file located at `$XDG_CONFIG_HOME` or `~/.config` followed by `configstore/snyk.json`
Example: `~/.config/configstore/snyk.json`
This command does not manage the `.snyk` file that is part of your project. See the [`snyk policy` ](policy.md)and [`snyk ignore`](ignore.md) commands.
## Debug
Use the `-d` option to output the debug logs.
## Subcommands
### `get <KEY>`
Print a config value.
### `set <KEY>=<VALUE>`
Create a new config value.
### `unset <KEY>`
Remove a config value.
### `clear`
Remove all config values.
### `environment`
Change the endpoint to use. Run `config environment --help` or see the [Config environment help page](https://docs.snyk.io/snyk-cli/commands/config-environment)
## Supported `<KEY>` values
### `api`
API token to use when calling Snyk API.
### `endpoint`
Define the API endpoint to use.
### `disable-analytics`
Turn off analytics reporting.
### `org`
Specify the `<ORG_ID>` to run Snyk commands tied to a specific Snyk Organization.&#x20;
### `oci-registry-url`
Configure the OCI registry used in IaC scanning with custom rules.
### `oci-registry-username`
Configure the username for an OCI registry used in IaC scanning with custom rules.
### `oci-registry-password`
Configure the password for an OCI registry used in IaC scanning with custom rules.

View File

@@ -0,0 +1,171 @@
# Container monitor
## Usage
`snyk container monitor [<OPTIONS>] [<IMAGE>]`
## Description
The `snyk container monitor` command captures the container image layers and dependencies in a project and monitors that snapshot for vulnerabilities, sending the results to [snyk.io](https://snyk.io)
Use the `container monitor` command before integrating your code into production, to take a snapshot of the code to be monitored in order to avoid pushing vulnerabilities into production. Choose a test frequency in your Settings if you want to change the frequency from the default, which is daily.
If you make changes to your code, you must run the `container monitor` command again.
For more information, see [Snyk CLI for container security](https://docs.snyk.io/products/snyk-container/snyk-cli-for-container-security)
## Exit codes
Possible exit codes and their meaning:
**0**: success, image layers and dependencies captured\
**2**: failure, try to re-run the command. Use `-d` to output the debug logs.\
**3**: failure, no supported projects detected
## Configure the Snyk CLI
You can use environment variables to configure the Snyk CLI and set variables for connecting with the Snyk API.
There are environment variables that apply to the container command; see [Configure the Snyk CLI](https://docs.snyk.io/features/snyk-cli/configure-the-snyk-cli)
## Debug
Use the `-d` option to output the debug logs.
## Options
### `--org=<ORG_ID>`
Specify the `<ORG_ID>` to run Snyk commands tied to a specific Snyk Organization. The `<ORG_ID>` influences some features availability and private test limits.
If you have multiple organizations, you can set a default from the CLI using:
`$ snyk config set org=<ORG_ID>`
Set a default to ensure all newly tested and monitored projects are tested and monitored under your default Organization. If you need to override the default, use the `--org=<ORG_ID>` option.
Default: `<ORG_ID>` that is the current preferred Organization in your [Account settings](https://app.snyk.io/account)
**Note:** You can also use `--org=<orgslugname>.` The `ORG_ID` works in both the CLI and the API. The Organization slug name works in the CLI, but not in the API.
`orgslugname` must match the slug name as displayed in the URL of your org in the Snyk UI: `https://app.snyk.io/org/[orgslugname]`. The orgname does not work.
For more information see the article [How to select the Organization to use in the CLI](https://docs.snyk.io/snyk-cli/scan-and-maintain-projects-using-the-cli/how-to-select-the-organization-to-use-in-the-cli)
### `--file=<FILE_PATH>`
For more detailed advice, include the path to the Dockerfile for the image.
### `--project-name=<PROJECT_NAME>`
Specify a custom Snyk project name.
### `--policy-path=<PATH_TO_POLICY_FILE>`
Manually pass a path to a `.snyk` policy file.
### `--json`
Print results on the console as a JSON data structure.
Example: `$ snyk container test --json`
**Note**: If you use an option that sets project attributes and your role lacks permission to edit project attributes the `monitor` command fails. For instructions on how to proceed see [Permissions (role) required to edit Project attributes from the Snyk CLI](https://docs.snyk.io/snyk-admin/manage-permissions-and-roles/manage-member-roles#permissions-role-required-to-edit-project-attributes-from-the-snyk-cli)
### `--target-reference=<TARGET_REFERENCE>`
Specify a reference that differentiates this project, for example, a branch name or version. Projects having the same reference can be grouped based on that reference.
For more information see [Group projects by branch or version for monitoring](https://docs.snyk.io/snyk-cli/scan-and-maintain-projects-using-the-cli/group-projects-by-branch-or-version-for-monitoring)
### `--project-environment=<ENVIRONMENT>[,<ENVIRONMENT>]...>`
Set the project environment to one or more values (comma-separated). To clear the project environment set `--project-environment=`
Allowed values: `frontend`, `backend`, `internal`, `external`, `mobile`, `saas`, `onprem`, `hosted`, `distributed`
For more information see [Project attributes](https://docs.snyk.io/snyk-admin/snyk-projects/project-attributes)
### `--project-lifecycle=<LIFECYCLE>[,<LIFECYCLE]...>`
Set the project lifecycle to one or more values (comma-separated). To clear the project lifecycle set `--project-lifecycle=`
Allowed values: `production, development, sandbox`
For more information see [Project attributes](https://docs.snyk.io/snyk-admin/snyk-projects/project-attributes)
### `--project-business-criticality=<BUSINESS_CRITICALITY>[,<BUSINESS_CRITICALITY>]...>`
Set the project business criticality to one or more values (comma-separated). To clear the project business criticality set `--project-business-criticality=`
Allowed values: `critical`, `high`, `medium`, `low`
For more information see [Project attributes](https://docs.snyk.io/snyk-admin/snyk-projects/project-attributes)
### `--project-tags=<TAG>[,<TAG>]...>`
Set the project tags to one or more values (comma-separated key value pairs with an "=" separator).
Example: `--project-tags=department=finance,team=alpha`
To clear the project tags set `--project-tags=`
For more information including allowable characters see [Project tags](https://docs.snyk.io/snyk-admin/snyk-projects/project-tags)
### `--tags=<TAG>[,<TAG>]...>`
This is an alias for `--project-tags`
### `--app-vulns`
Allow detection of vulnerabilities in your application dependencies from container images, as well as from the operating system, all in one single scan.
In CLI versions 1.1090.0 (2023-01-24) and higher, Snyk scans for application dependencies in your image by default; you do not need to specify the `--app-vulns` option.
In CLI versions 1.962.0 through v1.1089.0, use the `--app-vulns` option with the `--json` option to see the operating system as well as application vulnerabilities in JSON format in the results.
For more information see [Detecting application vulnerabilities in container images](https://docs.snyk.io/scan-using-snyk/snyk-container/use-snyk-container-from-the-web-ui/detect-application-vulnerabilities-in-container-images)
### `--exclude-app-vulns`
Allow disabling scans for app vulnerabilities; in CLI versions 1.1090.0 (2023-01-24) and higher, `app-vulns` is enabled by default.
In earlier releases, cannot be used with `--app-vulns`.
For more information see [Detecting application vulnerabilities in container images](https://docs.snyk.io/scan-using-snyk/snyk-container/use-snyk-container-from-the-web-ui/detect-application-vulnerabilities-in-container-images)
### `--exclude-node-modules`
Allow disabling the scan of `node_modules` directories inside node.js container images.
In CLI versions v1.1292.0 and higher, `node_modules` scanning is enabled by default.
&#x20;When `node_modules` scanning is disabled, Snyk reports vulnerabilities for npm Projects sourced from application file pairs: `[package.json, package-lock.json], [package.json, yarn.lock]`.
### `--nested-jars-depth`
When `app-vulns` is enabled, use the `--nested-jars-depth=n` option to set how many levels of nested jars Snyk is to unpack. Depth must be a number.
### `--exclude-base-image-vulns`
Do not show vulnerabilities introduced only by the base image. Works for operating system packages only. Available when using `snyk container test` only. Provided for compatibility with `snyk container test`. Using this option with `snyk container monitor` will not have any effect
### `--platform=<PLATFORM>`
For multi-architecture images, specify the platform to test.
Supported platforms are: `linux/amd64`, `linux/arm64`, `linux/riscv64`, `linux/ppc64le`, `linux/s390x`, `linux/386`, `linux/arm/v7`, or `linux/arm/v6`
### `--username=<CONTAINER_REGISTRY_USERNAME>`
Specify a username to use when connecting to a container registry. This is ignored in favor of local Docker binary credentials when Docker is present.
### `--password=<CONTAINER_REGISTRY_PASSWORD>`
Specify a password to use when connecting to a container registry. This is ignored in favor of local Docker binary credentials when Docker is present.
## Example for the container monitor command
**Scan and monitor Docker images**
`$ snyk container monitor <image>`

View File

@@ -0,0 +1,92 @@
# Container SBOM
## Prerequisites
**Feature availability:** This feature is currently in Early Access and is available to customers on Snyk Enterprise plans.
**Note:** In order to use the SBOM generation feature, you must use a minimum of CLI version 1.1226.0.
The `snyk container sbom` feature requires an internet connection.
## Usage
`$ snyk container sbom --format=<cyclonedx1.4+json|cyclonedx1.4+xml|cyclonedx1.5+json|cyclonedx1.5+xml|cyclonedx1.6+json|cyclonedx1.6+xml|spdx2.3+json> [--org=<ORG_ID>] [--exclude-app-vulns] <IMAGE>`
## Description
The `snyk container sbom` command generates an SBOM for a container image.
Supported formats include CycloneDX v1.4 (JSON or XML), CycloneDX v1.5 (JSON or XML), CycloneDX v1.6 (JSON or XML), and SPDX v2.3 (JSON).
An SBOM can be generated for operating system dependencies as well as application dependencies within the image. Unmanaged dependencies are not supported.
## Exit codes
Possible exit codes and their meaning:
**0**: success (process completed), SBOM created successfully\
**2**: failure, try to re-run the command. Use `-d` to output the debug logs.
## Debug
Use the `-d` or `--debug` option to output the debug logs.
## Options
### `--format=<cyclonedx1.4+json|cyclonedx1.4+xml|cyclonedx1.5+json|cyclonedx1.5+xml|cyclonedx1.6+json|cyclonedx1.6+xml|spdx2.3+json>`
Required. Specify the output format for the SBOM to be produced.
Set the desired SBOM output format. Available options are `cyclonedx1.4+json`, `cyclonedx1.4+xml`, `cyclonedx1.5+json`, `cyclonedx1.5+xml`, `cyclonedx1.6+json`, `cyclonedx1.6+xml`, and `spdx2.3+json`
### `[--org=<ORG_ID>]`
Specify the `<ORG_ID>` (name or UUID) to run Snyk commands tied to a specific Snyk Organization. The `<ORG_ID>` influences some features availability and private test limits.
Use this option when your default Organization does not have API entitlement.
If this option is omitted, the default Organization for your account will be used.
This is the `<ORG_ID>` that is the current preferred Organization in your [Account settings](https://app.snyk.io/account)&#x20;
Set a default to ensure all newly tested projects are tested under your default Organization. If you need to override the default, use the `--org=<ORG_ID>` option.
If you have multiple organizations, you can set a default from the CLI using:
`$ snyk config set org=<ORG_ID>`
**Note:** You can also use `--org=<orgslugname>.` The `ORG_ID` works in both the CLI and the API. The Organization slug name works in the CLI, but not in the API.
For more information, see the article [How to select the Organization to use in the CLI](https://docs.snyk.io/snyk-cli/scan-and-maintain-projects-using-the-cli/how-to-select-the-organization-to-use-in-the-cli)
### `[--exclude-app-vulns]`
Snyk scans and generates an SBOM for operating system dependencies as well as application dependencies in your image by default.
You can disable generation for application dependencies by adding `--exclude-app-vulns`.
For more information about application scanning, see [Detect application vulnerabilities in container images](https://docs.snyk.io/scan-using-snyk/snyk-container/use-snyk-container-from-the-web-ui/detect-application-vulnerabilities-in-container-images)
### `<IMAGE>`
Required. The image for which you will generate an SBOM document.
**Note:** The image should be specified in the format of `repo:tag`.
## Examples for the snyk container sbom command
### Create a CycloneDX JSON document for an image
`$ snyk container sbom --format=cyclonedx1.6+json redis:latest`
### Create a CycloneDX JSON document for an image and redirect stdout to a file
`$ snyk container sbom --format=cyclonedx1.6+json redis:latest > mySBOM.json`
### Create a SPDX JSON document for an image while excluding application dependencies
`$ snyk container sbom --format=spdx2.3+json redis:latest --exclude-app-vulns`
### Refer to a container image by its digest
`$ snyk container sbom --format=cyclonedx1.6+xml alpine@sha256:c5c5fda71656f28e49ac9c5416b3643eaa6a108a8093151d6d1afc9463be8e33`

View File

@@ -0,0 +1,171 @@
# Container test
## Usage
`snyk container test [<OPTIONS>] [<IMAGE>]`
## Description
The `snyk container test` command tests container images for any known vulnerabilities.
## Exit codes
Possible exit codes and their meaning:
**0**: success (scan completed), no vulnerabilities found\
**1**: action_needed (scan completed), vulnerabilities found\
**2**: failure, try to re-run command. Use `-d` to output the debug logs.\
**3**: failure, no supported projects detected
## Configure the Snyk CLI
You can use environment variables to configure the Snyk CLI and set variables for connecting with the Snyk API.
There are environment variables that apply to the container command; see [Configure the Snyk CLI](https://docs.snyk.io/features/snyk-cli/configure-the-snyk-cli)
## Debug
Use the `-d` option to output the debug logs.
## Options
### `--print-deps`
Print the dependency tree before sending it for analysis.
### `--org=<ORG_ID>`
Specify the `<ORG_ID>` to run Snyk commands tied to a specific Snyk Organization. The `<ORG_ID>` influences some features availability and private test limits.
If you have multiple Organizations, you can set a default from the CLI using:
`$ snyk config set org=<ORG_ID>`
Set a default to ensure all newly tested and monitored projects are tested and monitored under your default Organization. If you need to override the default, use the `--org=<ORG_ID>` option.
Default: `<ORG_ID>` that is the current preferred Organization in your [Account settings](https://app.snyk.io/account)
**Note:** You can also use `--org=<orgslugname>.` The `ORG_ID` works in both the CLI and the API. The Organization slug name works in the CLI, but not in the API.
`orgslugname` must match the slug name as displayed in the URL of your org in the Snyk UI: `https://app.snyk.io/org/[orgslugname]`. The orgname does not work.
For more information see the article [How to select the Organization to use in the CLI](https://docs.snyk.io/snyk-cli/scan-and-maintain-projects-using-the-cli/how-to-select-the-organization-to-use-in-the-cli)
### `--file=<FILE_PATH>`
For more detailed advice, include the path to the Dockerfile for the image.
### `--project-name=<PROJECT_NAME>`
Specify a custom Snyk project name.
### `--policy-path=<PATH_TO_POLICY_FILE>`
Manually pass a path to a `.snyk` policy file.
### `--json`
Print results on the console as a JSON data structure.
Example: `$ snyk container test --json`
### `--json-file-output=<OUTPUT_FILE_PATH>`
Save test output in JSON format as a JSON data structure directly to the specified file, regardless of whether or not you use the `--json` option.
Use to display the human-readable test output using stdout and at the same time save the JSON data structure output to a file.
Example: `$ snyk container test --json-file-output=vuln.json`
### `--sarif`
Return results in SARIF format.
### `--sarif-file-output=<OUTPUT_FILE_PATH>`
Save test output in SARIF format directly to the `<OUTPUT_FILE_PATH>` file, regardless of whether or not you use the `--sarif` option.
This is especially useful if you want to display the human-readable test output using stdout and at the same time save the SARIF format output to a file.
### `--severity-threshold=<low|medium|high|critical>`
Report only vulnerabilities at the specified level or higher.
### `--fail-on=<all|upgradable>`
Fail only when there are vulnerabilities that can be fixed.
- `all`: fail when there is at least one vulnerability that can be either upgraded or patched.
- `upgradable`: fail when there is at least one vulnerability for which Snyk has a computed remediation available.
To fail on any Snyk discoverable vulnerability (the default behavior), do not use the `--fail-on` option. If vulnerabilities do not have a Snyk-computed fix and this option is being used, tests pass.
**Note**: If you test code constrained by metadata that Snyk cannot respect with `snyk test`, Snyk will not propose a fix, in order to avoid breaking your code. You may be able to identify and apply a fix manually.
### `--app-vulns`
Allow detection of vulnerabilities in your application dependencies from container images, as well as from the operating system, all in one single scan.
In CLI versions 1.1090.0 (2023-01-24) and higher, Snyk scans for application dependencies in your image by default; you do not need to specify the `--app-vulns` flag.
In CLI versions 1.962.0 through v1.1089.0, use the `--app-vulns` option with the `--json` option to see the operating system as well as application vulnerabilities in JSON format in the results.
### `--exclude-app-vulns`
Allow disabling scans for app vulnerabilities; in CLI versions 1.1090.0 (2023-01-24) and higher, `app-vulns` is enabled by default.
In earlier releases, cannot be used with `--app-vulns`.
### `--exclude-node-modules`
&#x20;Allow disabling the scan of `node_modules` directories inside node.js container images.
In CLI versions v1.1292.0 and higher, `node_modules` scanning is enabled by default.
&#x20;When `node_modules` scaning is disabled, Snyk reports vulnerabilities for npm Projects sourced from application file pairs: `[package.json, package-lock.json], [package.json, yarn.lock]`.
### `--nested-jars-depth`
When `app-vulns` is enabled, use the `--nested-jars-depth=n` option to set how many levels of nested jars Snyk is to unpack. Depth must be a number.
### `--exclude-base-image-vulns`
Do not show vulnerabilities introduced only by the base image. Available when using `snyk container test` only. Works for operating system packages only.
### `--platform=<PLATFORM>`
For multi-architecture images, specify the platform to test.
Supported platforms are: `linux/amd64`, `linux/arm64`, `linux/riscv64`, `linux/ppc64le`, `linux/s390x`, `linux/386`, `linux/arm/v7`, or `linux/arm/v6`
### `--username=<CONTAINER_REGISTRY_USERNAME>`
Specify a username to use when connecting to a container registry. This is ignored in favor of local Docker binary credentials when Docker is present.
### `--password=<CONTAINER_REGISTRY_PASSWORD>`
Specify a password to use when connecting to a container registry. This is ignored in favor of local Docker binary credentials when Docker is present.
## Examples for the container test command
### Scan Docker images
`$ snyk container test <image>`
### Option to get more information including base image remediation
`--file=path/to/Dockerfile`
### Scan a Docker image created using the given Dockerfile and with a specified policy path
`$ snyk container test app:latest --file=Dockerfile`
`$ snyk container test app:latest --file=Dockerfile --policy-path=path/to/.snyk`
### Refer to a container image by its digest
`$ snyk container test app@sha256:17cb37098f0efb819c075eea4ff2a495be909a396e86ece317a6e3a8968e025c --file=Dockerfile`
For more information and examples, see [Advanced Snyk Container CLI usage](https://docs.snyk.io/snyk-container/snyk-cli-for-container-security/advanced-snyk-container-cli-usage)
See also [Detect application vulnerabilities in container images](https://docs.snyk.io/scan-using-snyk/snyk-container/use-snyk-container-from-the-web-ui/detect-application-vulnerabilities-in-container-images)

View File

@@ -0,0 +1,15 @@
# Container
## Description
The `snyk container` commands test and continuously monitor container images for vulnerabilities and generate an SBOM for a container image.
For more information, see [Snyk CLI for Snyk Container](https://docs.snyk.io/snyk-cli/scan-and-maintain-projects-using-the-cli/snyk-cli-for-snyk-container)
## `snyk container` commands and the help docs
The `snyk container` commands are listed here with the help options:
- [`container test`](container-test.md), `container test --help`: tests for any known vulnerabilities
- [`container monitor`](container-monitor.md), `container monitor --help`: captures the container image layers and dependencies and monitors for vulnerabilities on [snyk.io](https://snyk.io)
- [`container sbom`](container-sbom.md), `container sbom --help`: generates an SBOM for a container image

View File

@@ -0,0 +1,84 @@
# IaC capture
## Usage
**Feature availability:** This feature is available in Snyk CLI version v1.1117.0 or greater.
`snyk iac capture [<OPTIONS>] [<PATH>]`
## Description
The `snyk iac capture` command generates a mapping artifact that contains the minimum amount of information needed to generate resource mappings from code to Cloud from Terraform state files, such as resource IDs and names, and sends the mapping artifact to Snyk.
Snyk uses this information to link Cloud issues to their originating IaC files. The links can be viewed in the Snyk Web UI.
For more information, see [Fix Cloud issues in IaC](https://docs.snyk.io/scan-using-snyk/scan-infrastructure/iac+-code-to-cloud-capabilities/fix-cloud-issues-in-iac)
For a list of related commands, see the [snyk iac](iac.md) help; `iac --help`
## Exit codes
Possible exit codes and their meaning:
**0**: success\
**1**: failed to capture one or more Terraform states
## Configure the Snyk CLI
You can use environment variables and set variables for connecting with the Snyk API; see [Configure the Snyk CLI](https://docs.snyk.io/snyk-cli/configure-the-snyk-cli)
## Debug
Use the `-d` option to output the debug logs.
## Options
### `--org=<ORG_ID>`
Specify the `<ORG_ID>` to run Snyk commands tied to a specific Snyk Organization. Overrides the default `<ORG_ID>` that is the current preferred Organization in your [Account settings](https://app.snyk.io/account)
Note that you can also use `--org=<orgslugname>`. The `ORG_ID` works in both the CLI and the API. The Organization slug name works in the CLI, but not in the API.
For more information, see the article [How to select the Organization to use in the CLI](https://docs.snyk.io/snyk-cli/scan-and-maintain-projects-using-the-cli/how-to-select-the-organization-to-use-in-the-cli)
### `--stdin`
Generate the mapping artifact from Terraform state in the standard input instead of looking for state files in the `PATH`.
```
$ terraform state pull | snyk iac capture --stdin
```
### `PATH`
Optional argument to generate the mapping artifact from Terraform state file(s) in the PATH. Can either be a path to a directory, a path to a file, or a glob pattern.
```
$ snyk iac capture /path/to/states/**/*.tfstate
```
## Examples for snyk iac capture command
### Capture from all states in the current working directory
```
$ snyk iac capture
```
### Capture from all files ending with .tfstate in a directory
```
$ snyk iac capture /path/to/states/**/*.tfstate
```
### Capture from a single state file
```
$ snyk iac capture /path/to/state.tfstate
```
### Capture from states pulled with Terraform in the standard input
```
$ terraform state pull | snyk iac capture --stdin
```

View File

@@ -0,0 +1,190 @@
# IaC describe
## Usage
**Note:** This feature is available in Snyk CLI version v1.876.0 or greater.
`snyk iac describe [<OPTIONS>]`
## Description
The `snyk iac describe` command detects unmanaged infrastructure resources. It compares resources in your Terraform state file against actual resources in your cloud provider and outputs a report.
- Resources in your Terraform state files are **managed resources**.
- Resources that exist but are not in your Terraform state file are **unmanaged resources**.
For detailed information and examples, see [IaC describe command examples](https://docs.snyk.io/scan-using-snyk/scan-infrastructure/iac+-code-to-cloud-capabilities/detect-drift-and-manually-created-resources/iac-describe-command-examples)
For a list of related commands see the snyk [iac help](iac.md); `iac --help`
## Exit codes
Possible exit codes and their meaning:
**0**: success, no drift found\
**1**: unmanaged resources found\
**2**: failure
## Configure the Snyk CLI
You can use environment variables and set variables for connecting with the Snyk API; see [Configure the Snyk CLI](https://docs.snyk.io/snyk-cli/configure-the-snyk-cli)
## Configure the Terraform provider
You can set environment variables to configure the Terraform provider used by the `describe` command; see [Configure cloud providers](https://docs.snyk.io/scan-using-snyk/scan-infrastructure/iac+-code-to-cloud-capabilities/detect-drift-and-manually-created-resources/configure-cloud-providers)
## Debug
Use the `-d` option to output the debug logs.
## Optional arguments
### `--org=<ORG_ID>`
Specify the `<ORG_ID>` to run Snyk commands tied to a specific Snyk Organization. Overrides the default `<ORG_ID>` that is the current preferred Organization in your [Account settings](https://app.snyk.io/account)
Note that you can also use `--org=<orgslugname>`. The `ORG_ID` works in both the CLI and the API. The Organization slug name works in the CLI, but not in the API.
For more information, see the article [How to select the Organization to use in the CLI](https://docs.snyk.io/snyk-cli/scan-and-maintain-projects-using-the-cli/how-to-select-the-organization-to-use-in-the-cli)
### `--from=<STATE>[,<STATE>...]`
Specify multiple Terraform state files to be read. Glob patterns are supported.
For more information, including **a list of supported IaC sources** and how to use them, see [IAC Sources usage](https://docs.snyk.io/scan-using-snyk/scan-infrastructure/iac+-code-to-cloud-capabilities/detect-drift-and-manually-created-resources/iac-sources-usage)
### `--to=<PROVIDER+TYPE>`
Specify the cloud provider to scan (default: AWS with Terraform).
Supported providers:
- `github+tf` (GitHub with Terraform)
- `aws+tf` (Amazon Web Services with Terraform)
- `gcp+tf` (Google Cloud Platform with Terraform)
- `azure+tf` (Azure with Terraform)
### `--tf-provider-version`
Specify a Terraform provider version to use. If none is specified, default versions are used as follows:
- aws@3.19.0
- github@4.4.0
- google@3.78.0
- azurerm@2.71.0
### `--tf-lockfile`
Read the Terraform lock file (`.terraform.lock.hcl`) from a custom path (default: current directory).
If parsing the lockfile fails, errors are logged and scan continues.
**Note**: When you are using both the `--tf-lockfile` and `--tf-provider-version` options together, `--tf-provider-version` takes precedence.
### `--fetch-tfstate-headers`
Use a specific HTTP header or headers for the HTTP backend when fetching Terraform state.
### `--tfc-token`
Specify an API token to authenticate to the Terraform Cloud or Enterprise API.
### `--tfc-endpoint`
Read the current state for a given workspace from Terraform Enterprise by passing the `tfc-endpoint` value that is specific to your org's Terraform Enterprise installation.
### `--config-dir`
Change the directory path used for `iac describe` configuration (default `$HOME`). This can be useful, for example, if you want to invoke this command in an AWS Lambda function where you can only use the `/tmp` folder.
## Options for including and excluding resources
### `--service=<SERVICE>[,<SERVICE>...]`
Specify the services to inspect for unmanaged resources.
This option cannot be used with a `.snyk` drift ignore rule; the content in `.snyk` will be ignored.
Supported services: `aws_s3`, `aws_ec2`, `aws_lambda`, `aws_rds`, `aws_route53`, `aws_iam` , `aws_vpc`, `aws_api_gateway`, `aws_apigatewayv2`, `aws_sqs`, `aws_sns`, `aws_ecr`, `aws_cloudfront`, `aws_kms`, `aws_dynamodb`, `azure_base`, `azure_compute`, `azure_storage`, `azure_network`, `azure_container`, `azure_database`, `azure_loadbalancer`, `azure_private_dns`, `google_cloud_platform`, `google_cloud_storage`, `google_compute_engine`, `google_cloud_dns`, `google_cloud_bigtable`, `google_cloud_bigquery`, `google_cloud_functions`, `google_cloud_sql`, `google_cloud_run`
### `--filter`
Use filter rules.
Filter rules allow you to build a JMESPath expression to include or exclude a set of resources from the report.
For more information, see [Filter results](https://docs.snyk.io/scan-using-snyk/scan-infrastructure/iac+-code-to-cloud-capabilities/detect-drift-and-manually-created-resources/filter-rules)
### `--strict`
Enable strict mode.
The `iac describe` command ignores service-linked resources by default (like service-linked AWS IAM roles, their policies, and policy attachments). To include those resources in the report you can enable **strict mode**. Note that this can create noise when used with an AWS account.
## Options for policies
### `--ignore-policy`
Ignore all set policies, the current policy in the `.snyk` file, org level ignores, and the project policy in the Snyk Web UI.
### `--policy-path=<PATH_TO_POLICY_FILE>`
Manually pass a path to a `.snyk` policy file.
## Options for output
### `--quiet`
Output only the scan result to stdout.
### `--json`
Output the report as a JSON data structure to stdout.
### `--html`
Output the report as html to stdout.
### `--html-file-output=<OUTPUT_FILE_PATH>`
Output the report as html into a file.
## Examples for snyk iac describe command
For more examples, see [IaC describe command examples](https://docs.snyk.io/scan-using-snyk/scan-infrastructure/iac+-code-to-cloud-capabilities/detect-drift-and-manually-created-resources/iac-describe-command-examples)
### Detect unmanaged resources on AWS with a single local Terraform state
```
$ snyk iac describe --from="tfstate://terraform.tfstate"
```
### Specify AWS credentials
```
$ AWS_ACCESS_KEY_ID=XXX AWS_SECRET_ACCESS_KEY=XXX snyk iac describe
```
### Use an AWS named profile
```
$ AWS_PROFILE=profile_name snyk iac describe
```
### Use a single Terraform state stored on an S3 backend
```
$ snyk iac describe --from="tfstate+s3://my-bucket/path/to/state.tfstate"
```
### Aggregate multiple Terraform states
```
$ snyk iac describe --from="tfstate://terraform_S3.tfstate,tfstate://terraform_VPC.tfstate"
```
### Aggregate many Terraform states using glob pattern
```
$ snyk iac describe --from="tfstate://path/to/**/*.tfstate"
```

View File

@@ -0,0 +1,15 @@
# IAC report
## Usage
`snyk iac report [<OPTIONS>]`
## Description
Test for any known security issue and share results to the Snyk App.
This is an alias for `snyk iac test --report`.
For more information see the [iac test command help](iac-test.md) for the `--report` option; `iac test --help`
For a list of related commands see the [snyk iac](iac.md) help; `iac --help`

View File

@@ -0,0 +1,49 @@
# IaC rules init
## Usage
**Feature availability:** This feature is in Early Access.
`snyk iac rules init [<OPTIONS>]`
## Description
The `snyk iac rules init` command is an interactive command for initializing a new custom rules project structure, a new rule in an existing custom rules project, a new spec in an existing custom rules project, or a new relation in an existing custom rules project.
For a list of related commands run `snyk iac --help`
## Configure the Snyk CLI
You can use environment variables and set variables for connecting with the Snyk API; see [Configure the Snyk CLI](https://docs.snyk.io/snyk-cli/configure-the-snyk-cli)
## Debug
Use the `-d` option to output the debug logs.
## Examples for snyk iac rules init interactive experience
### **Initialize a new custom rules project structure**
```
snyk iac rules init
```
### Among "project," "rule," "rule spec," and "relation", select project structure option
`What do you want to initialize?`
`Filter: Type to filter choices`
&#x20; `project`
&#x20; `rule`
&#x20; `rule spec`
&#x20; `relation`
### Give the name of the project structure
`What do you want to initialize? project`
`Project name: project1 ✔`

View File

@@ -0,0 +1,41 @@
# IaC rules push
## Usage
**Feature availability:** This feature is in Early Access.
`snyk iac rules push [<OPTIONS>]`
## Description
The `snyk iac rules push` command bundles rules written in Rego and uploads changes to the Snyk platform.
For a list of related commands run `snyk iac --help`
## Configure the Snyk CLI
You can use environment variables and set variables for connecting with the Snyk API; see [Configure the Snyk CLI](https://docs.snyk.io/snyk-cli/configure-the-snyk-cli)
## Debug
Use the `-d` option to output the debug logs.
## Options
### `--delete`
Delete a previously-pushed bundle from an Organization. The Organization can be manually overridden by using the `--org` flag.
## Examples for snyk iac rules push command
### Bundle and upload a new bundle
```
$ snyk iac rules push
```
### Delete a bundle
```
$ snyk iac rules push --delete
```

View File

@@ -0,0 +1,37 @@
# IaC rules test
## Usage
**Feature availability:** This feature is in Early Access.
`snyk iac rules test [<OPTIONS>]`
## Description
The `snyk iac rules test` command runs all the tests written in Rego.
For a list of related commands run `snyk iac --help`
## Configure the Snyk CLI
You can use environment variables and set variables for connecting with the Snyk API; see [Configure the Snyk CLI](https://docs.snyk.io/snyk-cli/configure-the-snyk-cli)
## Debug
Use the `-d` option to output the debug logs.
## Options
See also subsequent sections for options for specific build environments, package managers, languages, and `[<CONTEXT-SPECIFIC OPTIONS>]` which you specify last.
### `--update-expected`
Overwrite the expected spec files to ensure that the test passes in the next run. This assumes that the tests were written correctly.
## Example for snyk iac rules test command
**Run tests for all rules**
```
snyk iac rules test
```

View File

@@ -0,0 +1,255 @@
# IaC test
## Usage
`snyk iac test [<OPTIONS>] [<PATH>]`
## Description
The `snyk iac test` command tests for any known security issue.
For a list of related commands see the [snyk iac](iac.md) help; `iac --help`
For more information see [Snyk CLI for IaC](https://docs.snyk.io/snyk-cli/scan-and-maintain-projects-using-the-cli/snyk-cli-for-iac)
## Exit codes
Possible exit codes and their meaning:
**0**: success (scan completed), no vulnerabilities found\
**1**: action_needed (scan completed), vulnerabilities found\
**2**: failure, try to re-run the command. Use `-d` to output the debug logs.\
**3**: failure, no supported projects detected
## Configure the Snyk CLI
You can use environment variables to configure the Snyk CLI and set variables for connecting with the Snyk API. See [Configure the Snyk CLI](https://docs.snyk.io/snyk-cli/configure-the-snyk-cli)
## Debug
Use the `-d` option to output the debug logs.
## Options
### `--detection-depth=<DEPTH>`
Indicate how many subdirectories to search. `DEPTH` must be a number, 1 or greater; zero (0) is the current directory.
Default: no limit.
Example: `--detection-depth=3` limits search to the specified directory (or the current directory if no `<PATH>` is specified) plus three levels of subdirectories; zero (0) is the current directory.
### `--org=<ORG_ID>`
Specify the `<ORG_ID>` to run Snyk commands tied to a specific Snyk Organization. The `<ORG_ID>` influences private test limits.
If you have multiple Organizations, you can set a default from the CLI using:
`$ snyk config set org=<ORG_ID>`
Set a default to ensure all newly tested projects are tested under your default Organization. If you need to override the default, use the `--org=<ORG_ID>` option.
Default: `<ORG_ID>` that is the current preferred Organization in your [Account settings](https://app.snyk.io/account)
**Note:** You can also use `--org=<orgslugname>.` The `ORG_ID` works in both the CLI and the API. The Organization slug name works in the CLI, but not in the API.
`orgslugname` must match the slug name as displayed in the URL of your org in the Snyk UI: `https://app.snyk.io/org/[orgslugname]`. The orgname does not work.
For more information see the article [How to select the Organization to use in the CLI](https://docs.snyk.io/snyk-cli/scan-and-maintain-projects-using-the-cli/how-to-select-the-organization-to-use-in-the-cli)
### `--ignore-policy`
Ignore all set policies, the current policy in the `.snyk` file, rg level ignores, and the project policy on snyk.io.
### `--policy-path=<PATH_TO_POLICY_FILE>`
Manually pass a path to a `.snyk` policy file.
### `--json`
Print results on the console as a JSON data structure.
Example: `$ snyk iac test --json`
### `--json-file-output=<OUTPUT_FILE_PATH>`
Save test output as a JSON data structure directly to the specified file, regardless of whether or not you use the `--json` option.
Use to display the human-readable test output using stdout and at the same time save the JSON data structure output to a file.
Example: `$ snyk iac test --json-file-output=vuln.json`
### `--sarif`
Return results in SARIF format.
### `--sarif-file-output=<OUTPUT_FILE_PATH>`
Save test output in SARIF format directly to the \<OUTPUT_FILE_PATH> file, regardless of whether or not you use the `--sarif` option.
This is especially useful if you want to display the human-readable test output using stdout and at the same time save the SARIF format output to a file.
Note: If you use an option that sets project attributes and your role lacks permission to edit project attributes the `iac test` command fails. For instructions on how to proceed see [Permissions required to edit Project attributes from the Snyk CLI](https://docs.snyk.io/snyk-admin/user-roles/user-role-management#permissions-required-to-edit-project-attributes-from-the-snyk-cli)
### `--project-business-criticality=<BUSINESS_CRITICALITY>[,<BUSINESS_CRITICALITY>]...>`
This can be used in combination with the `--report` option.
Set the project business criticality project attribute to one or more values (comma-separated). To clear the project business criticality set `--project-business-criticality=`
Allowed values: `critical, high, medium, low`
For more information see [Project attributes](https://docs.snyk.io/snyk-admin/snyk-projects/project-attributes)
### `--project-environment=<ENVIRONMENT>[,<ENVIRONMENT>]...>`
This can be used in combination with the `--report` option.
Set the project environment project attribute to one or more values (comma-separated). To clear the project environment set `--project-environment=`
Allowed values: `frontend`, `backend`, `internal`, `external`, `mobile`, `saas`, `onprem`, `hosted`, `distributed`
For more information see [Project attributes](https://docs.snyk.io/manage-issues/introduction-to-snyk-projects/project-attributes)
### `--project-lifecycle=<LIFECYCLE>[,<LIFECYCLE>]...>`
This can be used in combination with the `--report` option.
Set the project lifecycle project attribute to one or more values (comma-separated). To clear the project lifecycle set `--project-lifecycle=`
Allowed values: `production`, `development`, `sandbox`
For more information see [Project attributes](https://docs.snyk.io/manage-issues/introduction-to-snyk-projects/project-attributes)
### `--project-tags=<TAG>[,<TAG>]...>`
This can be used in combination with the `--report` option.
Set the project tags to one or more values (comma-separated key value pairs with an "=" separator).
Example: `--project-tags=department=finance,team=alpha`
To clear the project tags set `--project-tags=`
For more information including allowable characters see [Project tags](https://docs.snyk.io/manage-issues/introduction-to-snyk-projects/project-tags)
### `--remote-repo-url=<URL>`
Set or override the remote URL for the repository.
Example: `--remote-repo-url=https://gitlab.com/example/project` will create a target for given URL and on the UI it would be visible as `/example/project/` .
Can be used in combination with the `--report` option.
### `--report`
**NEW** option: Share results with the Snyk Web UI.
This creates a project in your Snyk account with a snapshot of the current configuration issues or appends the snapshot to an existing project.
After using this option, log in to the Snyk website and view your projects to see the snapshot.
Example: `$ snyk iac test --report`
Note: This option cannot be used in combination with the `--rules` option.
### `--rules=<PATH_TO_CUSTOM_RULES_BUNDLE>`
Use this dedicated option for Custom Rules scanning to enable the IaC scans to use a custom rules bundle generated with the `snyk-iac-rules` SDK. See [`snyk-iac-rules` SDK](https://github.com/snyk/snyk-iac-rules#readme)
This option cannot be used if the custom rules settings were configured with the Snyk UI. Default: If the `--rules` option is not specified, scan the configuration files using the internal Snyk rules only.
Example: Scan the configuration files using custom rules and internal Snyk rules.
`--rules=bundle.tar.gz`
Note: This option can not be used in combination with the `--report` option.
### `--severity-threshold=<low|medium|high|critical>`
Report only vulnerabilities at the specified level or higher.
### `--scan=<TERRAFORM_PLAN_SCAN_MODE>`
Use this dedicated option for Terraform plan scanning modes to control whether the scan analyzes the full final state (for example, `planned-values`), or the proposed changes only (for example, `resource-changes`).
Default: If the `--scan` option is not specified, scan the proposed changes only by default. Example 1: `--scan=planned-values` (full state scan)\
Example 2: `--scan=resource-changes` (proposed changes scan)
### `--target-name=<TARGET_NAME>`
This can be used in combination with the `--report` option.
Set or override the project name for the repository.
Note: This option supersedes`--remote-repo-url`, if both options are used together.
### `--target-reference=<TARGET_REFERENCE>`
This can be used in combination with the `--report` option.
Specify a reference that differentiates this project, for example, a branch name or version. Projects having the same reference can be grouped based on that reference.
Example, setting to the current Git branch:
`snyk iac test myproject/ --report --target-reference="$(git branch --show-current)"`
Example, setting to the latest Git tag:
`snyk iac test myproject/ --report --target-reference="$(git describe --tags --abbrev=0)"`
### `--var-file=<PATH_TO_VARIABLE_FILE>`
Load a terraform variable definitions file that is located in a different directory from the scanned one.
Example:
`$ snyk iac test myproject/staging/networking --var-file=myproject/vars.tf`
## Examples for snyk iac test command
For more information see [Snyk CLI for Infrastructure as Code](https://docs.snyk.io/scan-cloud-deployment/snyk-infrastructure-as-code/snyk-cli-for-infrastructure-as-code)
### Test a CloudFormation file
```
$ snyk iac test /path/to/cloudformation_file.yaml
```
### Test a Kubernetes file
```
$ snyk iac test /path/to/kubernetes_file.yaml
```
### Test a Terraform file
```
$ snyk iac test /path/to/terraform_file.tf
```
### Test a Terraform plan file
```
$ terraform plan -out=tfplan.binary
$ terraform show -json tfplan.binary > tf-plan.json
$ snyk iac test tf-plan.json
```
### Test an ARM file
```
$ snyk iac test /path/to/arm_file.json
```
### Test matching files in a directory
```
$ snyk iac test /path/to/directory
```
### Test matching files in a directory using a local custom rules bundle
```
$ snyk iac test /path/to/directory --rules=bundle.tar.gz
```

View File

@@ -0,0 +1,44 @@
# IaC update-exclude-policy
## Usage
`snyk iac update-exclude-policy [<OPTIONS>]`
## Description
The `snyk iac update-exclude-policy` generates exclude policy rules to be used by `snyk iac describe`.
For a list of related commands see the [snyk iac](iac.md) help; `iac --help`
For more information see [Ignore resources](https://docs.snyk.io/products/snyk-infrastructure-as-code/detect-drift-and-manually-created-resources/ignore-resources)
## Exit codes
Possible exit codes and their meaning:
**0**: success, exclude rules generated successfully\
**1**: error, something wrong happened during exclude rules generation
## Configure the Snyk CLI
You can use environment variables to configure the Snyk CLI and set variables for connecting with the Snyk API. See [Configure the Snyk CLI](https://docs.snyk.io/snyk-cli/configure-the-snyk-cli)
## Debug
Use the `-d` option to output the debug logs.
## Options
### `--exclude-missing`
Exclude missing resources.
### `--exclude-unmanaged`
Exclude resources not managed by IaC.
## Example
```
$ snyk iac describe --json | snyk iac update-exclude-policy
```

View File

@@ -0,0 +1,20 @@
# IaC
## Usage
`snyk iac <COMMAND> [<OPTIONS>] [<PATH>]`
## Description
The `snyk iac` commands find and report security issues in Infrastructure as Code files; detect, track, and alert on infrastructure drift and unmanaged resources; and create a .driftigore file.
For more information see [Snyk CLI for IaC](https://docs.snyk.io/snyk-cli/scan-and-maintain-projects-using-the-cli/snyk-cli-for-iac)
## `snyk iac` commands and the help docs
All the `snyk iac` commands are listed here with the help options:
- [iac test](iac-test.md); `iac test --help`: tests for any known security issue
- [iac describe](iac-describe.md); `iac describe --help`: detects infrastructure drift and unmanaged cloud resources\
Example: `snyk iac describe --only-unmanaged`
- [iac update-exclude-policy](iac-update-exclude-policy.md); `iac update-exclude-policy --help`: auto-generates `.snyk` exclusions for cloud resources

View File

@@ -0,0 +1,195 @@
# Ignore
## Usage and description
### Ignore
`snyk ignore --id=<ISSUE_ID> [--expiry=] [--reason=] [--policy-path=<PATH_TO_POLICY_FILE>] [--path=<PATH_TO_RESOURCE>] [OPTIONS]`
The `snyk ignore` command modifies the `.snyk` policy file to ignore a specified issue according to its Snyk ID for all occurrences, its expiry date, a reason, or according to paths in the filesystem for the policy, the issue, or both.
**Note:** Ignoring issues or vulnerabilities using the `.snyk` file is not supported for Snyk Code.
### Exclude
`snyk ignore [--expiry=] [--reason=] [--policy-path=<PATH_TO_POLICY_FILE>] [--file-path=<PATH_TO_RESOURCE>] [OPTIONS]`
You can exclude directories or files from scanning using the `--file-path` option. This option is available only for Snyk Code (SAST) tests or Open Source `--unmanaged` tests; it will not work for other test types.
## Examples of updates to the `.snyk` file
### Updates for ignores
The `snyk ignore` command for an `ISSUE_ID` updates your local `.snyk` file to contain a block similar to the following:
```yaml
ignore:
'<ISSUE_ID>':
- '*':
reason: <REASON>
expires: <EXPIRY>
```
When you use the `--path` option for an ignore, the block is similar to this:
```yaml
ignore:
'<ISSUE_ID>':
- '<PATH_TO_RESOURCE>':
reason: <REASON>
expires: <EXPIRY>
```
### Update for an exclude
When you use the `--file-path` option the block is similar to this:
```yaml
exclude:
'<GROUP>':
- <FILE MATCHING-PATTERN>
- <FILE MATCHING-PATTERN>:
expires: <EXPIRY>
created: <CREATION TIME>
```
**Note**: Ignoring issues or vulnerabilities using the `.snyk` file is not supported for Snyk Code.
The `--file-path` option excludes directories or files from scanning and is available only for Snyk Code (SAST) tests or Open Source `--unmanaged` tests; it will not work for other test types.
## Debug
Use the `-d` option to output the debug logs.
## Options
### `--id=<ISSUE_ID>`
Snyk ID for the issue to ignore, omitted if the `ignore` command used with `--file-path`, otherwise required.
### `--expiry=<EXPIRY>`
Expiry date in `YYYY-MM-DD` format.
Supported formats:
[ISO 8601](https://www.iso.org/iso-8601-date-and-time-format.html)
[RFC 2822](https://tools.ietf.org/html/rfc2822)
Default: 30 days or none if used with `--file-path`
### `--reason=<REASON>`
Human-readable `<REASON>` to ignore this issue.
Default: none
**Note**: Not supported for Snyk Code.
### `--policy-path=<PATH_TO_POLICY_FILE>`
Path to a `.snyk` policy file to pass manually.
Default: none
### `--path=<PATH_TO_RESOURCE>`
Path to resource inside the depgraph for which to ignore the issue.
Use to narrow the scope of the ignore rule. When no resource path is specified, all resources are ignored.
For ecosystems which use the semver convention for versioning, you can specify component versions in the path using [https://github.com/npm/node-semver#versions](https://github.com/npm/node-semver#versions)
If used, follows the `--policy-path` option.
Default: all
### `--file-path=<PATH_TO_RESOURCE>`
Filesystem for which to exclude directories or files from scanning. Used only by `snyk code` and `snyk test --unmanaged`
Default: none
### `--file-path-group=[global|code|iac-drift]`
Grouping used in combination with `--file-path`, otherwise omitted.
Default: global
## Examples for `snyk ignore` command
### Ignore a specific vulnerability with the expiry and reason specified
```
$ snyk ignore --id='npm:qs:20170213' --expiry='2021-01-10' --reason='Module not affected by this vulnerability'
```
### Ignore a specific vulnerability with the expiry, a resource path, and reason specified
```
$ snyk ignore --id='SNYK-JS-PATHPARSE-1077067' --expiry='2021-01-10' --path='nyc@11.9.0 > istanbul-lib-report@1.1.3 > path-parse@1.0.5' --reason='Module not affected by this vulnerability
```
### Ignore a specific vulnerability with an expiry date and path specified
```
$ snyk ignore --id='SNYK-JS-PATHPARSE-1077067' --expiry='2021-01-10' --path='nyc@11.9.0
```
### Ignore a specific vulnerability with a resource path specified (Windows)&#x20;
In this example, `snyk iac test` on Windows returned a Path containing single quotes and a File specification containing back slashes:
Rule: [https://security.snyk.io/rules/cloud/SNYK-CC-TF-118](https://security.snyk.io/rules/cloud/SNYK-CC-TF-118)\
Path: resource > aws_iam_role\[OrganizationAccountAccessRole] > assume_role_policy\['Statement']\[0]\
File: terraform\environment\com\iam.tf
The corresponding `snyk ignore` command would be:
`snyk ignore --id=SNYK-CC-TF-118 --path="terraform\environment\com\iam.tf > resource > aws_iam_role[OrganizationAccountAccessRole] > assume_role_policy['Statement'][0]"`
### Ignore a specific vulnerability with a resource path specified (Linux, Mac OS)&#x20;
In this example, `snyk iac test` on Linux or Mac OS returned a Path containing single quotes and a File specification containing forward slashes:
Rule: [https://security.snyk.io/rules/cloud/SNYK-CC-TF-118](https://security.snyk.io/rules/cloud/SNYK-CC-TF-118)\
Path: resource > aws_iam_role\[OrganizationAccountAccessRole] > assume_role_policy\['Statement']\[0]\
File: terraform/environment/com/iam.tf
The corresponding `snyk ignore` command would be:
`snyk ignore --id=SNYK-CC-TF-118 --path="terraform/environment/com/iam.tf > resource > aws_iam_role[OrganizationAccountAccessRole] > assume_role_policy['Statement'][0]"`
### Ignore a specific vulnerability for 30 days
```
$ snyk ignore --id=npm:tough-cookie:20160722
```
### Ignore a specific file until 2031-01-20
Ignore a specific file.
The rule created in the `.snyk` file is used by `snyk test --unmanaged` until 2031-01-20, with a description as a reference for the future.
```
$ snyk ignore --file-path='./deps/curl-7.58.0/src/tool_msgs.c' --expiry='2031-01-20' --reason='patched file'
```
### Ignore files or folders using glob expression - Snyk Code and `unmanaged` only
To ignore files matching a glob expression, add them to a specific group.
This applies to Snyk Code; it does not apply to Snyk Open Source except `unmanaged`, to Container, or to IaC.
```
$ snyk ignore --file-path='./**/vendor/**/*.cpp' --file-path-group='global'
```
## More information about the `snyk ignore` command
For more information see:
- [Ignore vulnerabilities using Snyk CLI](https://docs.snyk.io/snyk-cli/scan-and-maintain-projects-using-the-cli/ignore-vulnerabilities-using-the-snyk-cli)
- [IaC ignores using the .snyk policy file](https://docs.snyk.io/snyk-cli/scan-and-maintain-projects-using-the-cli/snyk-cli-for-iac/iac-ignores-using-the-.snyk-policy-file)

View File

@@ -0,0 +1,31 @@
# Log4shell
## Usage
`snyk log4shell`
## Description
The `snyk log4shell` command finds traces of the Log4J library that are affected by the Log4Shell vulnerability [CVE-2021-44228](https://security.snyk.io/vuln/SNYK-JAVA-ORGAPACHELOGGINGLOG4J-2314720)
The command finds traces of the Log4J library even if it is not declared in the manifest files (such as `pom.xml` or `build.gradle`).
## Managed projects
To test for Log4Shell vulnerabilities in Java projects using their package manager manifest files, use the `snyk test` command. See the [test command help](test.md) (`snyk test --help`) and [Java and Kotlin](https://docs.snyk.io/scan-using-snyk/supported-languages-and-frameworks/java-and-kotlin)
To test unmanaged files, use `snyk test --scan-all-unmanaged`
See the Maven options section of the [test command help](test.md); `snyk test --help`
## Exit codes
Possible exit codes and their meaning:
**0**: success (scan completed), Log4Shell not found\
**1**: action_needed (scan completed), Log4Shell found\
**2**: failure, try to re-run the command. Use `-d` to output the debug logs.
## Debug
Use the `-d` option to output the debug logs.

View File

@@ -0,0 +1,482 @@
# Monitor
## Usage
`snyk monitor [<OPTIONS>]`
## Description
The `snyk monitor` command creates a project in your Snyk account to be continuously monitored for open-source vulnerabilities and license issues, sending the results to [snyk.io](https://snyk.io)
Use the `monitor` command before integrating a project into production, to take a snapshot of the code to be monitored in order to avoid pushing vulnerabilities into production. Choose a test frequency in your Settings if you want to change the frequency from the default, which is daily.
A PR check will also do a test.
After running the `snyk monitor` command, log in to the Snyk website and view your projects to see the monitor.
If you make changes to your code, you must run the `monitor` command again.
For Snyk Container, see [`snyk container` help](https://docs.snyk.io/snyk-cli/commands/container)
The `monitor` command is not supported for Snyk Code.
For Snyk Infrastructure as Code follow the instructions in "Regularly testing IaC files" on [Snyk CLI for IaC](https://docs.snyk.io/snyk-cli/scan-and-maintain-projects-using-the-cli/snyk-cli-for-iac)
## Exit codes
Possible exit codes and their meaning:
**0**: success, snapshot created\
**2**: failure, try to re-run the command. Use `-d` to output the debug logs.\
**3**: failure, no supported projects detected
## Configure the Snyk CLI
You can use environment variables to configure the Snyk CLI and set variables for connecting with the Snyk API. See [Configure the Snyk CLI](https://docs.snyk.io/snyk-cli/configure-the-snyk-cli)
## Code execution warning
Before scanning your code, review the [Code execution warning for Snyk CLI](https://docs.snyk.io/snyk-cli/code-execution-warning-for-snyk-cli)
## Debug
Use the `-d` option to output the debug logs.
## Options
See also subsequent sections for options for specific build environments, package managers, languages and `[<CONTEXT-SPECIFIC OPTIONS>]` which you specify last.
### `--all-projects`
Auto-detect all projects in the working directory, including Yarn workspaces.
For more information see the article [Does the Snyk CLI support monorepos or multiple manifest files?](https://support.snyk.io/s/article/Does-the-Snyk-CLI-support-monorepos-or-multiple-manifest-files)
### `--fail-fast`
Use with `--all-projects` to cause scans to be interrupted when errors occur and to report these errors back to the user.
The exit code is 2 and the scan ends. No vulnerability information is reported for projects that did not produce errors.
To perform the scan, resolve the error and scan again.
**Note**: If you do not use `--fail-fast`, Snyk scans all the projects but does not report any vulnerabilities for projects it could not scan due to misconfiguration or another error.
### `--detection-depth=<DEPTH>`
Use with `--all-projects` or `--yarn-workspaces` to indicate how many subdirectories to search. `DEPTH` must be a number, `1` or greater; zero (0) is the current directory.
Default: no limit.
Example: `--detection-depth=3` limits search to the specified directory (or the current directory if no `<PATH>` is specified) plus three levels of subdirectories; zero (0) is the current directory.
### `--exclude=<NAME>[,<NAME>]...>`
Can be used with `--all-projects` and `--yarn-workspaces` to indicate directory names and file names to exclude. Must be comma-separated, and cannot include a path.
Example: `$ snyk test --all-projects --exclude=dir1,file2`
This will exclude any directories and files named `dir1` and `file2` when scanning for project manifest files such as: `./dir1`, `./src/dir1`, `./file2`, `./src/file2` and so on.
**Note**: `--exclude=dir1` will find both `./dir1`, and `./src/dir1`.\
However, `--exclude=./src/dir1` will result in an error because it includes a path.
### `--prune-repeated-subdependencies`, `-p`
Prune dependency trees, removing duplicate sub-dependencies.
Continues to find all vulnerabilities, but may not find all of the vulnerable paths.
Use this option if any big projects fail to be tested.
Default: false
### `--print-deps`
Print the dependency tree before sending it for analysis.
### `--remote-repo-url=<URL>`
Set or override the remote URL for the repository.
Example: `--remote-repo-url=https://gitlab.com/example/project` will create a target for given URL, and on the UI it would be visible as `/example/project/` .
### `--dev`
Include development-only dependencies. Applicable only for some package managers, for example, `devDependencies` in npm or `:development` dependencies in Gemfile.
**Note**: This option can be used with Maven, npm, and Yarn projects.
Default: false, scan only production dependencies.
### `--org=<ORG_ID>`
Specify the `<ORG_ID>` to run Snyk commands tied to a specific Snyk Organization. The `<ORG_ID>` influences some features availability and private test limits.
If you have multiple Organizations, you can set a default from the CLI using:
`$ snyk config set org=<ORG_`ID`>`
Set a default to ensure all newly monitored projects are created under your default Organization. If you need to override the default, use the `--org=<ORG_ID>` option.
Default: `<ORG_ID>` that is the current preferred Organization in your [Account settings](https://app.snyk.io/account)
**Note:** You can also use `--org=<orgslugname>.` The `ORG_ID` works in both the CLI and the API. The Organization slug name works in the CLI, but not in the API.
`orgslugname` must match the slug name as displayed in the URL of your org in the Snyk UI: `https://app.snyk.io/org/[orgslugname]`. The orgname does not work.
For more information, see the article [How to select the Organization to use in the CLI](https://docs.snyk.io/snyk-cli/scan-and-maintain-projects-using-the-cli/how-to-select-the-organization-to-use-in-the-cli)
### `--file=<FILE>`
Specify a package file.
When testing locally or monitoring a project, you can specify the file that Snyk should inspect for package information. When the file is not specified, Snyk tries to detect the appropriate file for your project.
See also the section on [Options for Python projects](https://docs.snyk.io/snyk-cli/commands/monitor#options-for-python-projects)
### `--package-manager=<PACKAGE_MANAGER_NAME>`
Specify the name of the package manager when the filename specified with the `--file=<FILE>` option is not standard. This allows Snyk to find the file.
Example: `$ snyk monitor --file=req.txt --package-manager=pip`
For more information see [Options for Python projects](https://docs.snyk.io/snyk-cli/commands/monitor#options-for-python-projects)
### `--unmanaged`
For C++ only, scan all files for known open source dependencies.
For options you can use with `--unmanaged` see [Options for scanning using `--unmanaged`](https://docs.snyk.io/snyk-cli/commands/monitor#options-for-scanning-using-unmanaged)
### `--ignore-policy`
Ignore all set policies, the current policy in the `.snyk` file, org level ignores, and the project policy on snyk.io.
### `--trust-policies`
Apply and use ignore rules from the Snyk policies in your dependencies; otherwise ignore rules in the dependencies are only shown as a suggestion.
### `--project-name=<PROJECT_NAME>`
Specify a custom Snyk project name.
Example: `$ snyk monitor --project-name=my-project`
### `--target-reference=<TARGET_REFERENCE>`
Specify a reference that differentiates this project, for example, a branch name or version. Projects having the same reference can be grouped based on that reference. Supported for Snyk Open Source and use with `--unmanaged`.
For more information, see [Group projects by branch or version for monitoring](https://docs.snyk.io/snyk-cli/scan-and-maintain-projects-using-the-cli/group-projects-by-branch-or-version-for-monitoring)
### `--policy-path=<PATH_TO_POLICY_FILE>`
Manually pass a path to a `.snyk` policy file.
### `--json`
Print results on the console as a JSON data structure.
**Note**: If you use an option that sets project attributes and your role lacks permission to edit project attributes the `monitor` command fails. For instructions on how to proceed see [Permissions (role) required to edit Project attributes from the Snyk CLI](https://docs.snyk.io/snyk-admin/manage-permissions-and-roles/manage-member-roles#permissions-role-required-to-edit-project-attributes-from-the-snyk-cli)
### `--project-environment=<ENVIRONMENT>[,<ENVIRONMENT>]...>`
Set the project environment project attribute to one or more values (comma-separated). To clear the project environment set `--project-environment=`
Allowed values: `frontend, backend, internal, external, mobile, saas, onprem, hosted, distributed`
For more information see [Project attributes](https://docs.snyk.io/getting-started/introduction-to-snyk-projects/view-project-information/project-attributes)
### `--project-lifecycle=<LIFECYCLE>[,<LIFECYCLE>]...>`
Set the project lifecycle project attribute to one or more values (comma-separated). To clear the project lifecycle set `--project-lifecycle=`
Allowed values: `production, development, sandbox`
For more information see [Project attributes](https://docs.snyk.io/snyk-admin/snyk-projects/project-tags)
### `--project-business-criticality=<BUSINESS_CRITICALITY>[,<BUSINESS_CRITICALITY>]...>`
Set the project business criticality project attribute to one or more values (comma-separated). To clear the project business criticality set `--project-business-criticality=`
Allowed values: `critical, high, medium, low`
For more information see [Project attributes](https://docs.snyk.io/snyk-admin/snyk-projects/project-tags)
### `--project-tags=<TAG>[,<TAG>]...>`
Set the project tags to one or more values (comma-separated key value pairs with an "=" separator).
Example, `--project-tags=department=finance,team=alpha`
To clear the project tags set `--project-tags=`
For more information including allowable characters see [Project tags](https://docs.snyk.io/snyk-admin/snyk-projects/project-tags)
### `--tags=<TAG>[,<TAG>]...>`
This is an alias for `--project-tags`
## Options for Maven projects
**Note**: The `--dev` option can be used with Maven projects. See also the [`--dev` option help](https://docs.snyk.io/snyk-cli/commands/monitor#dev)
### `--maven-aggregate-project`
Use `--maven-aggregate-project` instead of `--all-projects` when scanning Maven aggregate projects, that is, projects that use modules and inheritance.
Using `--maven-aggregate-project` instructs Snyk to perform a compilation step to ensure all modules within the project are resolvable by the Maven reactor. This ensures a comprehensive scan that includes dependencies of all sub-modules.
Be sure to run the scan in the same directory as the root `pom.xml` file.
Snyk reports the test results per individual `pom.xml` file within the aggregate project.
**Note:** You can use `--all-projects` when scanning Maven aggregate projects, but you cannot use `--all-projects` with `--maven-aggregate-project`.
### `--scan-unmanaged`
To monitor individual JAR, WAR, and AAR files, use the following:
```
--scan-unmanaged --file=<JAR_FILE_NAME>
```
### `--scan-all-unmanaged`
Auto-detect Maven, JAR, WAR, and AAR files recursively from the current folder.
```
--scan-all-unmanaged
```
**Note**: Custom-built JAR files, even with open-source dependencies, are not supported.
## Options for Gradle projects
### `--sub-project=<NAME>`, `--gradle-sub-project=<NAME>`
For Gradle multi project configurations, monitor a specific sub-project.
### `--all-sub-projects`
For multi project configurations, monitor all sub-projects.
Both a build.gradle file and a settings.gradle file, or equivalent files, based on the package manager, must exist in the current directory.
### `--all-projects`
See also the `--all-projects` option information in the Options section of this help.
Use for monorepos. This detects all supported manifests.
For Gradle monorepos Snyk looks only for root level **build.gradle / build.gradle.kts** files and applies the same logic as `--all-sub-projects` behind the scenes.
This option is designed to be run in the root of your monorepo.
For more details, see the following support article: [Scanning Gradle projects in CLI with `--exclude` option does not exclude sub-projects](https://support.snyk.io/s/article/Scanning-Gradle-projects-in-CLI-with---exclude-option-does-not-exclude-sub-projects)
### `--configuration-matching=<CONFIGURATION_REGEX>`
Resolve dependencies using the first configuration that matches the specified Java regular expression.
Example: `^releaseRuntimeClasspath$`
### `--configuration-attributes=<ATTRIBUTE>[,<ATTRIBUTE>]...`
Select certain values of configuration attributes to install dependencies and perform dependency resolution.
Example: `buildtype:release,usage:java-runtime`
### `--init-script=<FILE`
Use for projects that contain a Gradle initialization script.
## Options for NuGet projects
### `--assets-project-name`
When you are monitoring a .NET project using NuGet `PackageReference` uses the project name in `project.assets.json` if found.
### `--packages-folder`
Specify a custom path to the packages folder.
### `--project-name-prefix=<PREFIX_STRING>`
When monitoring a .NET project, use this option to add a custom prefix to the name of files inside a project along with any desired separators.
Example: `snyk monitor --file=my-project.sln --project-name-prefix=my-group/`
This is useful when you have multiple projects with the same name in other `.sln` files.
## Options for .NET projects
### `--dotnet-runtime-resolution`
**Note:** This option in in Early Access and may change until it is released.
Required. You must use this option when you test .NET projects using [Runtime Resolution Scanning](https://docs.snyk.io/getting-started/supported-languages-and-frameworks/.net/improved-.net-scanning)
Example: `snyk test --dotnet-runtime-resolution`
### `--dotnet-target-framework`
**Note:** This option in in Early Access and may change until it is released.
Optional. You may use this option if your solution contains multiple `<TargetFramework>` directives. If you do not specify the option `--dotnet-target-framework`, all supported Target Frameworks will be scanned.
The Target Framework specified with this option should be defined following the standard [naming convention](https://learn.microsoft.com/en-us/dotnet/standard/frameworks#supported-target-frameworks)
Example: `snyk test --dotnet-runtime-resolution --dotnet-target-framework=net6.0`
## Options for npm projects
**Note**: You can use the following options with npm projects:
`--dev`. See the [`--dev` option help](https://docs.snyk.io/snyk-cli/commands/monitor#dev)
`--all-projects` to scan and detect npm projects and all other projects in the directory. See the [`--all-projects` option help](https://docs.snyk.io/snyk-cli/commands/monitor#all-projects)
`--prune-repeated-subdependencies, -p`. See the [--prune-repeated subdependencies option help](https://docs.snyk.io/snyk-cli/commands/monitor#prune-repeated-subdependencies-p)
### `--strict-out-of-sync=true|false`
Control monitoring out-of-sync lockfiles.
Default: true
## Options for pnpm projects
**Snyk CLI pnpm support is in Early Access**. To enable it, in your Snyk account navigate to Settings, select Snyk Preview, and install CLI v1.1293.0 or above.
**Note**: You can use the following options with pnpm projects:
`--dev`. See the [`--dev` option help](https://docs.snyk.io/snyk-cli/commands/monitor#dev)
`--all-projects` to scan and detect pnpm projects and all other projects in the directory. See the [`--all-projects` option help](https://docs.snyk.io/snyk-cli/commands/monitor#all-projects)
`--prune-repeated-subdependencies, -p`. See the [--prune-repeated subdependencies option help](https://docs.snyk.io/snyk-cli/commands/monitor#prune-repeated-subdependencies-p)
### `--strict-out-of-sync=true|false`
Control monitoring out-of-sync lockfiles.
Default: true
## Options for Yarn projects
**Note**: You can use the following options with Yarn projects:
`--dev.` See the [`--dev` option help](https://docs.snyk.io/snyk-cli/commands/monitor#dev)
`--prune-repeated-subdependencies, -p.` See the [--prune-repeated subdependencies option help](https://docs.snyk.io/snyk-cli/commands/monitor#prune-repeated-subdependencies-p)
### `--strict-out-of-sync=true|false`
Control monitoring out-of-sync lockfiles.
Default: true
### `--yarn-workspaces`
Detect and scan only Yarn Workspaces when a lockfile is in the root.
You can specify how many sub-directories to search using `--detection-depth`.
You can exclude directories and files using `--exclude`.
Default:`--all-projects` automatically detects and scans Yarn Workspaces.with other projects.
## Option for CocoaPods projects
### `--strict-out-of-sync=true|false`
Control monitoring out-of-sync lockfiles.
Default: false
## Options for Python projects
### `--command=<COMMAND>`
Indicate which specific Python commands to use based on the Python version.
Snyk uses Python in order to scan and find your dependencies. If you are using multiple Python versions, use this parameter to specify the correct Python command for execution.
Default: `python` This executes your default python version. Run `python -V` to find out what your default version is.
Example: `snyk monitor --command=python3`
### `--skip-unresolved=true|false`
Skip packages that cannot be found in the environment, for example, private packages that cannot be accessed from the machine running the scan.
### `--file=<FILE_for_Python>`
For a Python project, specify a particular file to monitor.
Default: Snyk scans the requirements.txt file at the top level of the project.
**Important:** When specifying a value for the `--file` parameter that is not the default file, you must also include the `--package-manager=pip` option. The test will fail without this parameter.
Always specify this parameter with the value `pip` when using a custom `--file` value. For example:
```bash
snyk test --file=requirements-dev.txt --package-manager=pip
```
This allows Snyk to correctly recognize and scan your specified manifest file, such as when you have renamed it to `requirements-dev.txt`.
### `--package-manager=pip`
Add`--package-manager=pip` to your command if the file name is not `requirements.txt`.
This option is mandatory if you specify a value for the `--file` parameter that is not to a `requirements.txt` file. The test fails without this parameter. Specify this parameter with the value `pip`.
For complete information about the command see [`--package-manager=<PACKAGE_MANAGER_NAME>`](https://docs.snyk.io/snyk-cli/commands/monitor#package-manager-less-than-package_manager_name-greater-than)\`\`
## Options for scanning using `--unmanaged`
The following `snyk monitor` options can be used with `--unmanaged` as documented in this help.
`--org=<ORG_ID>`
`--json`
`--remote-repo-url=<URL>`
`--target-reference=<TARGET_REFERENCE>`
`--project-name=<c-project>`
There are also special options.
### `--max-depth`
Specify the maximum level of archive extraction.
Usage: `--max-depth=1`
Use 0 (zero, the default) to disable archive extraction completely.
### `--print-dep-paths`
Display dependencies.
Use this option to see what files contributed to each dependency identified.
To see how confident Snyk is about the identified dependency and its version, use the `--print-deps` or `--print-dep-paths` option.
## Options for build tools
### `-- [<CONTEXT-SPECIFIC_OPTIONS>]`
Use a double dash (`--`) after the complete Snyk command to pass options (arguments, flags) that follow directly to the build tool, for example Gradle or Maven.
The format is `snyk <command> -- [<context-specific_options>]`
Example: `snyk monitor -- --build-cache`
**Note:** Do not use double quotes in any `-- [<context-specific_options>]`.
Example: Use `snyk monitor --org=myorg -- -s settings.xml` NOT `snyk monitor --org=myorg -- "-s settings.xml"`

View File

@@ -0,0 +1,17 @@
# Policy
## Usage
`snyk policy [<PATH_TO_POLICY_FILE>] [<OPTIONS>]`
## Description
The `snyk policy` command displays the `.snyk` policy file for a package.
## Argument: `<PATH_TO_POLICY_FILE>`
Manually pass a path to a `.snyk` policy file.
## Debug
Use `-d` option to output the debug logs.

View File

@@ -0,0 +1,87 @@
# SBOM monitor
**Feature availability:** This feature is available to customers on Snyk Enterprise plans.
## Usage
`snyk sbom monitor --experimental [<OPTIONS>]`
## Description
The `snyk sbom monitor` command creates a target and projects in your Snyk account to be continuously monitored for open-source vulnerabilities and license issues, sending the results to [snyk.io](https://snyk.io)
Use the `sbom monitor` command to take a snapshot of dependencies detected in your SBOM to be monitored. Choose a test frequency in your Settings if you want to change the frequency from the default, which is daily.
After running the `snyk sbom monitor` command, log in to the Snyk website and view your projects to see the monitor and related issues.
If you make changes to your SBOM, you must run the `sbom monitor` command again.&#x20;
## Exit codes
Possible exit codes and their meaning:
**0**: success, snapshot created\
**2**: failure, try to re-run the command. Use `-d` to output the debug logs.
## Configure the Snyk CLI
You can use environment variables to configure the Snyk CLI and set variables for connecting with the Snyk API. See [Configure the Snyk CLI](https://docs.snyk.io/snyk-cli/configure-the-snyk-cli)
## Debug
Use the `-d` option to output the debug logs.
## Options
### `--experimental`
Required. Use experimental command features. This option is required because the command is in its experimental phase.
### `--file=<FILE_PATH>`
Required. Specify the file path of the SBOM document.
The `snyk sbom monitor` command accepts the following file formats:
- CycloneDX: JSON version 1.4, 1.5, and 1.6
- SPDX: JSON version 2.3
Packages and components within the provided SBOM file must be identified by a Package URL (`purl`).
Supported purl types are: `apk`, `cargo`, `cocoapods`, `composer`, `deb`, `gem`, `generic`, `golang`, `hex`, `maven`, `npm`, `nuget`, `pub`, `pypi`, `rpm`, `swift`
Example: `$ snyk sbom monitor --experimental --file=bom.cdx.json`&#x20;
### `--remote-repo-url=<URL>`
Set or override the remote URL for the repository.
Example: `--remote-repo-url=https://gitlab.com/example/project` will create a target for given URL, and on the UI it would be visible as `/example/project/` .
### `--target-reference=<TARGET_REFERENCE>`
Specify a reference that differentiates this project, for example, a branch name or version. Projects having the same reference can be grouped based on that reference.&#x20;
For more information, see [Group projects by branch or version for monitoring](https://docs.snyk.io/snyk-cli/scan-and-maintain-projects-using-the-cli/group-projects-by-branch-or-version-for-monitoring)
### `--policy-path=<PATH_TO_POLICY_FILE>`
Manually pass a path to a `.snyk` policy file.
### `--org=<ORG_ID>`
Specify the `<ORG_ID>` to run Snyk commands tied to a specific Snyk Organization. The `<ORG_ID>` influences some features availability and private test limits.
If you have multiple Organizations, you can set a default from the CLI using:
`$ snyk config set org=<ORG_ID>`
Set a default to ensure all newly monitored projects are created under your default Organization. If you need to override the default, use the `--org=<ORG_ID>` option.
Default: `<ORG_ID>` that is the current preferred Organization in your [Account settings](https://app.snyk.io/account)
**Note:** You can also use `--org=<orgslugname>.` The `ORG_ID` works in both the CLI and the API. The Organization slug name works in the CLI, but not in the API.
`orgslugname` must match the slug name as displayed in the URL of your org in the Snyk UI: `https://app.snyk.io/org/[orgslugname]`. The orgname does not work.
For more information, see the article [How to select the Organization to use in the CLI](https://docs.snyk.io/snyk-cli/scan-and-maintain-projects-using-the-cli/how-to-select-the-organization-to-use-in-the-cli)

View File

@@ -0,0 +1,54 @@
# SBOM test
**Feature availability:** This feature is available to customers on Snyk Enterprise plans.
## Usage
`snyk sbom test --experimental --file=<FILE_PATH> [<OPTIONS>]`
## Description
The `snyk sbom test` command checks SBOM files for vulnerabilities in open-source packages.
## Exit codes
Possible exit codes and their meaning:
**0**: success (scan completed), no vulnerabilities found\
**1**: action_needed (scan completed), vulnerabilities found\
**2**: failure, try to re-run the command
## Configure the Snyk CLI
You can use environment variables to configure the Snyk CLI and set variables for connecting with the Snyk API. See [Configure the Snyk CLI](https://docs.snyk.io/snyk-cli/configure-the-snyk-cli)
## Debug
Use the `-d` or `--debug` option to output the debug logs.
## Options
### `--experimental`
Required. Use experimental command features. This option is currently required as the command is in its experimental phase.
### `--file=<FILE_PATH>`
Required. Specify the file path of the SBOM document.
The `snyk sbom test` command accepts the following file formats:
- **CycloneDX:** JSON version 1.4, 1.5, and 1.6
- **SPDX:** JSON version 2.3
Packages and components within the provided SBOM file must be identified by a PackageURL (purl).
Supported purl types are: `apk`, `cargo`, `cocoapods`, `composer`, `deb`, `gem`, `generic`, `golang`, `hex`, `maven`, `npm`, `nuget`, `pub`, `pypi`, `rpm`, `swift`.
Example: `$ snyk sbom test --experimental --file=bom.cdx.json`
### `--json`
Print results on the console as a JSON data structure.
Example: `$ snyk sbom test --experimental --file=bom.cdx.json --json`

View File

@@ -0,0 +1,315 @@
---
description: Generate an SBOM document from a local file system.
---
# SBOM
## Prerequisites
**Feature availability:** This feature is available to customers on Snyk Enterprise plans.
**Note:** In order to use the SBOM generation feature, you must use a minimum of CLI version 1.1071.0.
The `snyk sbom` feature requires an internet connection.
## Usage
`$ snyk sbom --format=<cyclonedx1.4+json|cyclonedx1.4+xml|cyclonedx1.5+json|cyclonedx1.5+xml|cyclonedx1.6+json|cyclonedx1.6+xml|spdx2.3+json> [--org=<ORG_ID>] [--file=<FILE>] [--unmanaged] [--dev] [--all-projects] [--name=<NAME>] [--version=<VERSION>] [--exclude=<NAME>[,<NAME>...]] [--detection-depth=<DEPTH>] [--prune-repeated-subdependencies|-p] [--maven-aggregate-project] [--scan-unmanaged] [--scan-all-unmanaged] [--sub-project=<NAME>] [--gradle-sub-project=<NAME>] [--all-sub-projects] [--configuration-matching=<CONFIGURATION_REGEX>] [--configuration-attributes=<ATTRIBUTE>[,<ATTRIBUTE>]] [--init-script=<FILE>] [--json-file-output=<OUTPUT_FILE_PATH>] [<TARGET_DIRECTORY>]`
## Description
The `snyk sbom` command generates an SBOM for a local software project in an ecosystem supported by Snyk.
Supported formats include CycloneDX v1.4 (JSON or XML), CycloneDX v1.5 (JSON or XML), CycloneDX v1.6 (JSON or XML), and SPDX v2.3 (JSON).
An SBOM can be generated for all supported Open Source package managers as well as unmanaged software projects.
## Exit codes
Possible exit codes and their meaning:
**0**: success (process completed), SBOM created successfully\
**2**: failure, try to re-run the command. Use `-d` to output the debug logs.
## Debug
Use the `-d` or `--debug` option to output the debug logs.
## Options
### `--format=<cyclonedx1.4+json|cyclonedx1.4+xml|cyclonedx1.5+json|cyclonedx1.5+xml|cyclonedx1.6+json|cyclonedx1.6+xml|spdx2.3+json>`
Required. Specify the output format for the SBOM to be produced.
Set the desired SBOM output format. Available options are `cyclonedx1.4+json`, `cyclonedx1.4+xml`, `cyclonedx1.5+json`, `cyclonedx1.5+xml`, `cyclonedx1.6+json`, `cyclonedx1.6+xml`, and `spdx2.3+json`
### `[--org=<ORG_ID>]`
Specify the `<ORG_ID>` (name or UUID) to run Snyk commands tied to a specific Snyk Organization. The `<ORG_ID>` influences some features availability and private test limits.
Use this option when your default Organization does not have API entitlement.
If this option is omitted, the default Organization for your account will be used.
This is the `<ORG_ID>` that is the current preferred Organization in your [Account settings](https://app.snyk.io/account)
Set a default to ensure all newly tested projects are tested under your default Organization. If you need to override the default, use the `--org=<ORG_ID>` option.
If you have multiple Organizations, you can set a default from the CLI using:
`$ snyk config set org=<ORG_ID>`
**Note:** You can also use `--org=<orgslugname>.` The `ORG_ID` works in both the CLI and the API. The organization slug name works in the CLI, but not in the API.
For more information, see the article [How to select the Organization to use in the CLI](https://docs.snyk.io/snyk-cli/scan-and-maintain-projects-using-the-cli/how-to-select-the-organization-to-use-in-the-cli)
### `[--file=<file>] or [--f=<file>]`
Specify the desired manifest file on which the SBOM will be based.
By default, the `sbom` command detects a supported manifest file in the current working directory.
### `[--unmanaged]`
Generate an SBOM for unmanaged software projects.
### `[--dev]`
Include development-only dependencies in the SBOM output.
Applicable only for some package managers, for example, `devDependencies` in npm or `:development` dependencies in Gemfile.
When `--dev` is used with the SPDX format, the development-only dependencies are included in the `DEV_DEPENDENCY_OF` relationship.
When `--dev` is used with the CycloneDX format, development-only dependencies are not labeled differently from non-development dependencies.
**Note**: This option can be used with Maven, npm, and Yarn projects.
### `[--all-projects]`
Optional. Use for monorepos and directories with multiple projects or manifest files.
Auto-detect all projects in the working directory (including Yarn workspaces) and generate a single SBOM based on their contents.
### `[--name=<NAME>]`
Use in combination with `--all-projects` to provide the name of the software which the SBOM describes. If not specified, this defaults to the name of the current working directory.
### `[--version=<VERSION>]`
Use in combination with `--all-projects` to provide the version of the software that the SBOM describes. This is omitted if not set explicitly.
### `[--exclude=<NAME>[,<NAME>...]]`
Can be used with `--all-projects` to indicate directory names and file names to exclude. Must be comma-separated.
Example: `$ snyk sbom --all-projects --exclude=dir1,file2`
This will exclude any directories named `dir1` and `file2` when scanning for project manifest files.
**Note**: `--exclude=dir1` will find both `./dir1`, and `./src/dir1`.\
However, `--exclude=./src/dir1` will result in an error because it includes a path.
### `[--detection-depth=<DEPTH>]`
Use with `--all-projects` to indicate how many subdirectories to search. `DEPTH` must be a number, 1 or greater; zero (0) is the current directory.
Default: no limit
### `[--prune-repeated-subdependencies|-p]`
Prune dependency trees, removing duplicate sub-dependencies.
### `[--json-file-output]`
Optional. Save the SBOM output as a JSON data structure directly to the specified file. This requires the SBOM `--format` to include `+json`.
### `[<TARGET_DIRECTORY>]`
Optional. Instruct the CLI to autodetect a package manager manifest file to use within the specified directory. If `--file` is set, this option will be ignored.
## Options for Maven projects
### `--maven-aggregate-project`
Use `--maven-aggregate-project` instead of `--all-projects` when scanning Maven aggregate projects, that is, ones that use modules and inheritance.
When scanning these types of projects, Snyk performs a compile to ensure all modules are resolvable by the Maven reactor.
Be sure to run the scan in the same directory as the root pom.xml file.
### `--scan-unmanaged`
To scan individual JAR, WAR, or AAR files, use the following:
`--scan-unmanaged --file=<JAR_FILE_NAME>`
### `--scan-all-unmanaged`
Auto-detect Maven, JAR, WAR, and AAR files recursively from the current folder.
**Note**: Custom-built JAR files, even with open-source dependencies, are not supported.
## Options for Gradle projects
### `--sub-project=<NAME>`, `--gradle-sub-project=<NAME>`
For Gradle multi project configurations, scan a specific sub-project.
### `--all-sub-projects`
For multi project configurations, scan all sub-projects.
### `--all-projects`
See also the `--all-projects` option information in the Options section of this help.
Use for monorepos. This detects all supported manifests.
For Gradle monorepos, Snyk looks only for root level `build.gradle` and `build.gradle.kts` files and applies the same logic as `--all-sub-projects` behind the scenes.
This option is designed to be run in the root of your monorepo.
### `--configuration-matching=<CONFIGURATION_REGEX>`
Resolve dependencies using only configuration(s) that match the specified Java regular expression.
Example: `^releaseRuntimeClasspath$`
### `--configuration-attributes=<ATTRIBUTE>[,<ATTRIBUTE>]...`
Select certain values of configuration attributes to install and resolve dependencies.
Example: `buildtype:release,usage:java-runtime`
### `--init-script=<FILE>`
Use for projects that contain a Gradle initialization script.
## Options for NuGet projects
### `--assets-project-name`
When you are monitoring a .NET project using NuGet `PackageReference`, use the project name in `project.assets.json` if found.
### `--file=<filename>.sln`
Test all .NET projects included in the given `.sln` file. Projects referred to must have supported manifests.
### `--file=packages.config`
Test an individual .NET project.
### `--packages-folder`
Specify a custom path to the packages folder.
This is the folder in which your dependencies are installed, provided you are using `packages.config`. If you have assigned a unique name to this folder, then Snyk can find it only if you enter a custom path.
Use the absolute or relative path, including the name of the folder where your dependencies reside.
## Options for npm projects
### `--strict-out-of-sync=true|false`
Prevent testing out-of-sync lockfiles.
To use this option, you must use a minimum CLI version of 1.1228.0.
If there are out-of-sync lockfiles in the project, the `sbom` command fails when `--strict-out-of-sync=true`.
Default: true
## Options for Yarn projects
### `--strict-out-of-sync=true|false`
Prevent testing out-of-sync lockfiles.
If there are out-of-sync lockfiles in the project, the `sbom` command fails when `--strict-out-of-sync=true`.
Default: true
### `--yarn-workspaces`
Detect and scan Yarn Workspaces only when a lockfile is in the root.
You can specify how many sub-directories to search using `--detection-depth`.
You can exclude directories and files using `--exclude`.
Default: `--all-projects` automatically detects and scans Yarn Workspaces with other projects.
## Options for Python projects
### `--command=<COMMAND>`
Indicate which specific Python commands to use based on the Python version.
Snyk uses Python in order to scan and find your dependencies. If you are using multiple Python versions, use this parameter to specify the correct Python command for execution.
Default: `python` This executes your default python version. Run `python -V` to find out what your default version is.
Example: `snyk sbom --command=python3`
### `--skip-unresolved=true|false`
Skip packages that cannot be found in the environment, for example, private packages that cannot be accessed from the machine running the scan.
### `--file=<filename>`
For a Python project, specify a particular file to test.&#x20;
Default: Snyk scans the `requirements.txt` file at the top level of the project.
When setting this option for Python values, it is required to also set the `--package-manager` option. See below.
### `--package-manager=<package manager>`
Add `--package-manager=pip` to your command if the file name is not `requirements.txt`.
This option is mandatory if you specify a value for the `--file` parameter that is not to a `requirements.txt` file. The SBOM generation fails without this parameter. Specify this parameter with the value `pip`.
## Options for scanning using `--unmanaged`
### `--max-depth`
Specify the maximum level of archive extraction.
Usage: `--max-depth=1`
Use `0` (zero, the default) to disable archive extraction completely.
## Options for build tools
### `-- [<CONTEXT-SPECIFIC_OPTIONS>]`
Use a double dash (`--`) after the complete Snyk command to pass additional options (arguments, flags) that follow directly to the build tool, for example, Gradle or Maven.
Example: `snyk sbom -- -s settings.xml`
## Examples for the snyk sbom command
### Create a CycloneDX JSON document for a local software project
`$ snyk sbom --format=cyclonedx1.6+json`
### Create a CycloneDX JSON document and redirect stdout to a file
`$ snyk sbom --format=cyclonedx1.6+json > mySBOM.json`
### Create an SPDX JSON document and write it to a file
`$ snyk sbom --format spdx2.3+json --json-file-output mySBOM.json`
### Create an SPDX 2.3 JSON document for an unmanaged software project
`$ snyk sbom --unmanaged --format=spdx2.3+json`
### Create a CycloneDX XML document for a Maven project
`$ snyk sbom --file=pom.xml --format=cyclonedx1.6+xml`
### Create a CycloneDX JSON document for a monorepo
`$ snyk sbom --format=cyclonedx1.6+json --all-projects`

View File

@@ -0,0 +1,541 @@
# Test
## Usage
`snyk test [<OPTIONS>]`
## Description
The `snyk test` command checks projects for open-source vulnerabilities and license issues. The test command tries to auto-detect supported manifest files with dependencies and test those.
**Note:** There are specific `snyk test` commands for the Snyk Code, Container, and IaC scanning methods: `code test`, `container test`, and `iac test`.
## Exit codes
Possible exit codes and their meaning:
**0**: success (scan completed), no vulnerabilities found\
**1**: action_needed (scan completed), vulnerabilities found\
**2**: failure, try to re-run the command. Use `-d` to output the debug logs.\
**3**: failure, no supported projects detected
## Configure the Snyk CLI
You can use environment variables to configure the Snyk CLI and set variables for connecting with the Snyk API. See [Configure the Snyk CLI](https://docs.snyk.io/snyk-cli/configure-the-snyk-cli)
## Code execution warning
Before scanning your code, review the [Code execution warning for Snyk CLI](https://docs.snyk.io/snyk-cli/code-execution-warning-for-snyk-cli)
## Debug
Use the `-d` option to output the debug logs.
## Options
See also subsequent sections for options for specific build environments, package managers, languages, and `[<CONTEXT-SPECIFIC OPTIONS>]` which you specify last.
### `--all-projects`
Auto-detect all projects in the working directory, including Yarn workspaces.
For more information see the article [Does the Snyk CLI support monorepos or multiple manifest files?](https://support.snyk.io/s/article/Does-the-Snyk-CLI-support-monorepos-or-multiple-manifest-files)
If you see the invalid string length error, refer to [Invalid string length error when scanning projects](https://docs.snyk.io/snyk-cli/test-for-vulnerabilities/invalid-string-length-error-when-scanning-projects)
### `--fail-fast`
Use with `--all-projects` to cause scans to be interrupted when errors occur and to report these errors back to the user.
The exit code is 2 and the scan ends. No vulnerability information is reported for projects that did not produce errors.
To perform the scan, resolve the error and scan again.
**Note**: If you do not use `--fail-fast`, Snyk scans all the projects but does not report any vulnerabilities for projects it could not scan due to misconfiguration or another error.
### `--detection-depth=<DEPTH>`
Use with `--all-projects` or `--yarn-workspaces` to indicate how many subdirectories to search. `DEPTH` must be a number, 1 or greater; zero (0) is the current directory.
Default: no limit.
Example: `--detection-depth=3` limits search to the specified directory (or the current directory if no `<PATH>` is specified) plus three levels of subdirectories; zero (0) is the current directory.
### `--exclude=<NAME>[,<NAME>]...>`
Can be used with `--all-projects` and `--yarn-workspaces` to indicate directory names and file names to exclude. Must be comma-separated, and cannot include a path.
Example: `$ snyk test --all-projects --exclude=dir1,file2`
This will exclude any directories and files named `dir1` and `file2` when scanning for project manifest files such as: `./dir1`, `./src/dir1`, `./file2`, `./src/file2` and so on.
**Note**: `--exclude=dir1` will find both `./dir1`, and `./src/dir1`.\
However, `--exclude=./src/dir1` will result in an error because it includes a path.
### `--prune-repeated-subdependencies`, `-p`
Prune dependency trees, removing duplicate sub-dependencies.
Continues to find all vulnerabilities, but may not find all of the vulnerable paths.
Use this option if any big projects fail to be tested.
Default: false
### `--print-deps`
Print the dependency tree before sending it for analysis.
### `--remote-repo-url=<URL>`
Set or override the remote URL for the repository.
Example: `--remote-repo-url=https://gitlab.com/example/project` will create a target for given URL and on the UI it would be visible as `/example/project/` .
### `--dev`
Include development-only dependencies. Applicable only for some package managers, for example, `devDependencies` in npm or `:development` dependencies in Gemfile.
**Note**: This option can be used with Maven, npm, and Yarn projects.
Default: false, scan only production dependencies.
### `--org=<ORG_ID>`
Specify the `<ORG_ID>` to run Snyk commands tied to a specific Snyk Organization. The `<ORG_ID>` influences some features availability and private test limits.
If you have multiple Organizations, you can set a default from the CLI using:
`$ snyk config set org=<ORG_ID>`
Set a default to ensure all newly tested projects are tested under your default Organization. If you need to override the default, use the `--org=<ORG_ID>` option.
Default: `<ORG_ID>` that is the current preferred Organization in your [Account settings](https://app.snyk.io/account)
**Note:** You can also use `--org=<orgslugname>.` The `ORG_ID` works in both the CLI and the API. The Organization slug name works in the CLI, but not in the API.
`orgslugname` must match the slug name as displayed in the URL of your org in the Snyk UI: `https://app.snyk.io/org/[orgslugname]`. The orgname does not work.
For more information see the article [How to select the Organization to use in the CLI](https://docs.snyk.io/snyk-cli/scan-and-maintain-projects-using-the-cli/how-to-select-the-organization-to-use-in-the-cli)
### `--file=<FILE>`
Specify a package file.
When you are testing locally or monitoring a project, you can specify the file that Snyk should inspect for package information. When the file is not specified, Snyk tries to detect the appropriate file for your project.
See also the section on [Options for Python projects](https://docs.snyk.io/snyk-cli/commands/test#options-for-python-projects)
### `--package-manager=<PACKAGE_MANAGER_NAME>`
Specify the name of the package manager when the filename specified with the `--file=<FILE>` option is not standard. This allows Snyk to find the file.
Example: `$ snyk test --file=req.txt --package-manager=pip`
For more information see [Options for Python projects](https://docs.snyk.io/snyk-cli/commands/test#options-for-python-projects)
### `--unmanaged`
For C++ only, scan all files for known open source dependencies.
For options you can use with `--unmanaged` see [Options for scanning using `--unmanaged`](https://docs.snyk.io/snyk-cli/commands/test#options-for-scanning-using-unmanaged)
### `--ignore-policy`
Ignore all set policies, the current policy in the `.snyk` file, Org level ignores, and the project policy on snyk.io.
### `--trust-policies`
Apply and use ignore rules from the Snyk policies in your dependencies; otherwise ignore rules in the dependencies are only shown as a suggestion.
### `--show-vulnerable-paths=<none|some|all>`
Display the dependency paths from the top level dependencies down to the vulnerable packages. Not supported with `--json-file-output`.
Default: `some`, a few example paths shown. `false` is an alias for `none`
Example: `--show-vulnerable-paths=none`
### `--project-name=<PROJECT_NAME>`
Specify a custom Snyk project name.
### `--target-reference=<TARGET_REFERENCE>`
Specify a reference that differentiates this project, for example, a branch name or version. Projects having the same reference can be grouped based on that reference. Supported for Snyk Open Source except for use with `--unmanaged`.
For more information see [Group projects by branch or version for monitoring](https://docs.snyk.io/snyk-cli/scan-and-maintain-projects-using-the-cli/group-projects-by-branch-or-version-for-monitoring)
You can use `--target-reference=<TARGET_REFERENCE>` when running tests to apply the same ignores and policies as for a monitored target.
For more information see [Ignore issues](https://docs.snyk.io/scan-using-snyk/find-and-manage-priority-issues/ignore-issues)
### `--policy-path=<PATH_TO_POLICY_FILE>`
Manually pass a path to a `.snyk` policy file.
### `--json`
Print results on the console as a JSON data structure.
Example: `$ snyk test --json`
If you see the invalid string length error, refer to [Invalid string length error when scanning projects](https://docs.snyk.io/snyk-cli/scan-and-maintain-projects-using-the-cli/invalid-string-length-error-when-scanning-projects)
### `--json-file-output=<OUTPUT_FILE_PATH>`
Save test output as a JSON data structure directly to the specified file, regardless of whether or not you use the `--json` option.
Use to display the human-readable test output using stdout and at the same time save the JSON data structure output to a file.
For open source, Snyk creates a file whether or not issues are found. In contrast, for SAST, if no issues are found, Snyk does not create a `json` file.
Example: `$ snyk test --json-file-output=vuln.json`
If you see the invalid string length error, refer to [Invalid string length error when scanning projects](https://docs.snyk.io/snyk-cli/scan-and-maintain-projects-using-the-cli/invalid-string-length-error-when-scanning-projects)
### `--sarif`
Return results in SARIF format.
### `--sarif-file-output=<OUTPUT_FILE_PATH>`
Save test output in SARIF format directly to the \<OUTPUT_FILE_PATH> file, regardless of whether or not you use the `--sarif` option.
This is especially useful if you want to display the human-readable test output using stdout and at the same time save the SARIF format output to a file.
### `--severity-threshold=<low|medium|high|critical>`
Report only vulnerabilities at the specified level or higher.
### `--fail-on=<all|upgradable|patchable>`
Fail only when there are vulnerabilities that can be fixed. Use one of the values as follows:
- `all`: Use to fail when there is at least one vulnerability that can be either upgraded or patched.
- `upgradable`: Use to fail when there is at least one vulnerability for which Snyk has a computed remediation available.
- `patchable`: Use to fail when there is at least one vulnerability that can be patched. Note that when you use `patchable`, the test will also fail if at least one vulnerability can be patched and other vulnerabilities found have a computed remediation available.
To fail on any Snyk-discoverable vulnerability (the default behavior), do not use the `--fail-on` option. If vulnerabilities do not have a Snyk-computed fix and this option is being used, tests pass.
**Note**: If you test code constrained by metadata that Snyk cannot respect with `snyk test`, Snyk will not propose a fix, in order to avoid breaking your code. You may be able to identify and apply a fix manually.
## Options for Maven projects
**Note**: The `--dev` option can be used with Maven projects. See also the [`--dev` option help](https://docs.snyk.io/snyk-cli/commands/test#dev)
### `--maven-aggregate-project`
Use `--maven-aggregate-project` instead of `--all-projects` when scanning Maven aggregate projects, that is, projects that use modules and inheritance.
Using `--maven-aggregate-project` instructs Snyk to perform a compilation step to ensure all modules within the project are resolvable by the Maven reactor. This ensures a comprehensive scan that includes dependencies of all sub-modules.
Be sure to run the scan in the same directory as the root `pom.xml` file.
Snyk reports the test results per individual `pom.xml` file within the aggregate project.
**Note:** You can use `--all-projects` when scanning Maven aggregate projects, but you cannot use `--all-projects` with `--maven-aggregate-project`.
### `--scan-unmanaged`
To test individual JAR, WAR, and AAR files, use the following:
`--scan-unmanaged --file=<JAR_FILE_NAME>`
### `--scan-all-unmanaged`
Auto-detect Maven, JAR, WAR, and AAR files recursively from the current folder.
`--scan-all-unmanaged`
**Note**: Custom-built JAR files, even with open-source dependencies, are not supported.
## Options for Gradle projects
**Note:** If you see the invalid string length error, refer to [Invalid string length error when scanning projects](https://docs.snyk.io/snyk-cli/scan-and-maintain-projects-using-the-cli/invalid-string-length-error-when-scanning-projects)
### `--sub-project=<NAME>`, `--gradle-sub-project=<NAME>`
For Gradle multi project configurations, test a specific sub-project.
### `--all-sub-projects`
For multi project configurations, test all sub-projects.\
\
Both a build.gradle file and a settings.gradle file, or equivalent files, based on the package manager, must exist in the current directory.
### `--all-projects`
See also the `--all-projects` option information in the Options section of this help.
Use for monorepos. This detects all supported manifests.
For Gradle monorepos Snyk looks only for root level **build.gradle / build.gradle.kts** files and applies the same logic as `--all-sub-projects` behind the scenes.
This option is designed to be run in the root of your monorepo.
For more details, see the following support article: [Scanning Gradle projects in CLI with `--exclude` option does not exclude sub-projects](https://support.snyk.io/s/article/Scanning-Gradle-projects-in-CLI-with---exclude-option-does-not-exclude-sub-projects)
### `--configuration-matching=<CONFIGURATION_REGEX>`
Resolve dependencies using the first configuration that matches the specified Java regular expression.
Example: `^releaseRuntimeClasspath$`
### `--configuration-attributes=<ATTRIBUTE>[,<ATTRIBUTE>]...`
Select certain values of configuration attributes to install and resolve dependencies.
Example: `buildtype:release,usage:java-runtime`
### `--init-script=<FILE>`
Use for projects that contain a Gradle initialization script.
## Options for NuGet projects
### `--assets-project-name`
When you are monitoring a .NET project using NuGet `PackageReference` uses the project name in `project.assets.json` if found.
### `--file=<filename>.sln`
Test all .NET projects included in the given `.sln` file. Projects referred to must have supported manifests.
Example: `snyk test --file=myApp.sln`
### `--file=packages.config`
Test an individual .NET project.
### `--packages-folder`
Specify a custom path to the packages folder.
This is the folder in which your dependencies are installed, provided you are using `packages.config`. If you have assigned a unique name to this folder, then Snyk can find it only if you enter a custom path.
Use the absolute or relative path, including the name of the folder where your dependencies reside.
Examples:
`snyk test --packages-folder=../location/to/packages` for Unix OS
`snyk test --packages-folder=..\location\to\packages` for Windows.
### `--project-name-prefix=<PREFIX_STRING>`
When monitoring a .NET project, use this option to add a custom prefix to the name of files inside a project along with any desired separators.
Example: `snyk monitor --file=my-project.sln --project-name-prefix=my-group/`
This is useful when you have multiple projects with the same name in other `.sln` files.
## Options for .NET projects
### `--dotnet-runtime-resolution`
**Note:** This option in Early Access and may change until it is released.
Required. You must use this option when you test .NET projects using [Runtime Resolution Scanning](https://docs.snyk.io/getting-started/supported-languages-and-frameworks/.net/improved-.net-scanning)
Example: `snyk test --dotnet-runtime-resolution`
### `--dotnet-target-framework`
**Note:** This option in Early Access and may change until it is released.
Optional. You may use this option if your solution contains multiple `<TargetFramework>` directives. If you do not specify the option `--dotnet-target-framework`, all supported Target Frameworks will be scanned.
The Target Framework specified with this option should be defined following the standard [naming convention](https://learn.microsoft.com/en-us/dotnet/standard/frameworks#supported-target-frameworks)
Example: `snyk test --dotnet-runtime-resolution --dotnet-target-framework=net6.0`
## Options for npm projects
**Note**: You can use the following options with npm projects:
`--dev`. See the [`--dev` option help](https://docs.snyk.io/snyk-cli/commands/test#dev)
`--all-projects` to scan and detect npm projects and all other projects in the directory. See the [`--all-projects` option help](https://docs.snyk.io/snyk-cli/commands/test#all-projects)
`--fail-on`. See the [--fail-on option help](https://docs.snyk.io/snyk-cli/commands/test#fail-on-less-than-all-or-upgradable-or-patchable-greater-than)
`--prune-repeated-subdependencies, -p`. See the [`--prune-repeated subdependencies` option help](https://docs.snyk.io/snyk-cli/commands/test#prune-repeated-subdependencies-p)
### `--strict-out-of-sync=true|false`
Prevent testing out-of-sync lockfiles.
If there are out-of-sync lockfiles in the project, the `test` command fails when `--strict-out-of-sync=true`.
Default: true
## Options for pnpm projects
**Snyk CLI pnpm support is in Early Access**. To enable it, in your Snyk account navigate to Settings, select Snyk Preview, and install CLI v1.1293.0 or above.
**Note**: You can use the following options with pnpm projects:
`--dev`. See the [`--dev` option help](https://docs.snyk.io/snyk-cli/commands/test#dev)
`--all-projects` to scan and detect pnpm projects and all other projects in the directory. See the [`--all-projects` option help](https://docs.snyk.io/snyk-cli/commands/test#all-projects)
`--fail-on`. See the [--fail-on option help](https://docs.snyk.io/snyk-cli/commands/test#fail-on-less-than-all-or-upgradable-or-patchable-greater-than)
`--prune-repeated-subdependencies, -p`. See the [`--prune-repeated subdependencies` option help](https://docs.snyk.io/snyk-cli/commands/test#prune-repeated-subdependencies-p)
### `--strict-out-of-sync=true|false`
Prevent testing out-of-sync lockfiles.
If there are out-of-sync lockfiles in the project, the `test` command fails when `--strict-out-of-sync=true`.
Default: true
## Options for Yarn projects
**Note**: You can use the following options with Yarn projects:
`--dev`. See the [`--dev` option help](https://docs.snyk.io/snyk-cli/commands/test#dev)
`--fail-on`. See the [--fail-on option help](https://docs.snyk.io/snyk-cli/commands/test#fail-on-less-than-all-or-upgradable-or-patchable-greater-than)
`--prune-repeated-subdependencies, -p`. See the [`--prune-repeated subdependencies` option help](https://docs.snyk.io/snyk-cli/commands/test#prune-repeated-subdependencies-p)
### `--strict-out-of-sync=true|false`
Prevent testing out-of-sync lockfiles.
If there are out-of-sync lockfiles in the project, the `test` command fails when `--strict-out-of-sync=true`.
Default: true
### `--yarn-workspaces`
Detect and scan only Yarn Workspaces when a lockfile is in the root.
You can specify how many sub-directories to search using `--detection-depth.`
You can exclude directories and files using `--exclude`.
Default: `--all-projects` automatically detects and scans Yarn Workspaces.with other projects.
## Option for CocoaPods projects
### `--strict-out-of-sync=true|false`
Control testing out-of-sync lockfiles.
Default: false
## Options for Python projects
### `--command=<COMMAND>`
Indicate which specific Python commands to use based on the Python version.
Snyk uses Python in order to scan and find your dependencies. If you are using multiple Python versions, use this parameter to specify the correct Python command for execution.
Default: `python` This executes your default python version. Run `python -V` to find out what your default version is.
Example: `snyk test --command=python3`
### `--skip-unresolved=true|false`
Skip packages that cannot be found in the environment, for example, private packages that cannot be accessed from the machine running the scan.
### `--file=<FILE_for_Python>`
For a Python project, specify a particular file to test.
Default: Snyk scans the requirements.txt file at the top level of the project.
**Important:** When specifying a value for the `--file` parameter that is not the default file, you must also include the `--package-manager=pip` option. The test will fail without this parameter.
Always specify this parameter with the value `pip` when using a custom `--file` value. For example:
```bash
snyk test --file=requirements-dev.txt --package-manager=pip
```
This allows Snyk to correctly recognize and scan your specified manifest file, such as when you have renamed it to `requirements-dev.txt`.
### `--package-manager=pip`
Add`--package-manager=pip` to your command if the file name is not `requirements.txt`.
This option is mandatory if you specify a value for the `--file` parameter that is not to a `requirements.txt` file. The test fails without this parameter. Specify this parameter with the value `pip`.
For complete information about the command see [`--package-manager=<PACKAGE_MANAGER_NAME>`](https://docs.snyk.io/snyk-cli/commands/test#package-manager-less-than-package_manager_name-greater-than)
## Options for Go projects
The following options are not supported:
`--fail-on=<all|upgradable|patchable>`
## Options for scanning using `--unmanaged`
The following standard `snyk test` options can be used with `--unmanaged` as documented in this help.
`--org=<ORG_ID>`
`--json`
`--json-file-output=<OUTPUT_FILE_PATH>`
`--remote-repo-url=<URL>`
`--severity-threshold=<low|medium|high|critical>`
There are also special options as follows.
### `--max-depth`
Specify the maximum level of archive extraction.
Usage: `--max-depth=1`
Use 0 (zero, the default) to disable archive extraction completely.
### `--print-dep-paths`
Display dependencies.
Use this option to see what files contributed to each dependency identified.
To see how confident Snyk is about the identified dependency and its version, use the `--print-deps` or `--print-dep-paths` option.
## Options for build tools
### `-- [<CONTEXT-SPECIFIC_OPTIONS>]`
Use a double dash (`--`) after the complete Snyk command to pass additional options (arguments, flags) that follow directly to the build tool, for example, Gradle or Maven.
The format is `snyk <command> -- [<context-specific_options>]`
Example: `snyk test -- --build-cache`
**Note:** Do not use double quotes in any `-- [<context-specific_options>]`.
Example: Use `snyk test --org=myorg -- -s settings.xml`
NOT `snyk test --org=myorg -- "-s settings.xml"`
## Examples for the snyk test command
Test a project in the current folder for known vulnerabilities:
`$ snyk test`
Test a specific dependency for vulnerabilities (**npm** only):
`$ snyk test ionic@1.6.5`
Test the latest version of an **npm** package:
`$ snyk test lodash`
Test a public GitHub repository:
`$ snyk test https://github.com/snyk-labs/nodejs-goof`