Running a Scan
This command enables you to specify one or more discovery strategies. For example, using the
If the maximum number of scans that can be run simultaneously is exceeded, the scan is placed in the queue. The concurrent scans limitation can be set either for the entire organization or for this particular project in the project settings. The new scan will start as soon as you manually stop another running scan or when the current scan is completed.
|The unique identifier used to authenticate a user. The token (API key) can be issued in your organization’s dashboard.|
|The name of the scan|
|The archive ID, which can be received via the |
|Specifies a list of specific URLs that should be included during crawler discovery. You can see how it works in our how-to video.|
|Specifies a list of Repeater UUIDs that should be connected with the scan|
|Bright cluster (domain name)|
|Allows specifying the Bright project for a scan using the project ID. You can find the project ID in the Projects section in the Bright app.|
|Allows connecting a ticketing service with an associated repository for a scan. It enables you to get the reports on every detected vulnerability in automatically opened tickets/issues of the associated repository. You can see how it works in our how-to video.|
Note: You can only connect a ticketing service (system) that was previously integrated with the Bright app. Read more about integrating Bright with ticketing systems here.
If you want to connect several repositories for one scan, you can specify them one after another:
- To connect a ticketing service and a repository for a scan, the token (API key) that you use for the scan must include the
|Enables you to use automatic smart decisions, such as parameter skipping, detection phases, and so on to minimize scan time. When set to |
|Defines which part of the request to attack (see here for more details).|
Note: This argument can be passed multiple times in the same command.
|The DAST module tests for specific scenarios, such as OWASP top 10 and other common scenarios. The fuzzer module generates various new scenarios in order to test for unknown issues, providing automated AI-guided fuzz testing.|
|The list of specific hosts to be included in the scan.|
|Extra headers to be passed with the archive file. It can also be used to remove a header by providing a name without content. For example, -H "Host:".|
Warning: Headers set with this option override the archive headers and are set in all the requests.
|Specifies a list of relevant tests to execute during a scan.|
|Specifies the ID of the authentication object to be connect to the scan. Find more info about using an authentication object at Manging Your Authentications.|
|Specifies the path to the configuration file. By default, the CLI tries to discover the config in the|
|Allows setting the level of logs to report. Any logs of a higher level than the one specified are shown. The options to select : 0, 1, 2, 3, 4, "silent", "error", "warn", "notice", "verbose".|
|Allows the Bright CLI to proceed and operate even if the server connection is considered insecure.|
|SOCKS URL to proxy all traffic.|
Note: SOCKS4, SOCKS5, SOCKS4a, SOCKS5h are currently supported. By default, if you specify
|(Deprecated). Set the API endpoint domain, for VPC, use: --api https://private-domain.brightsece.com|
|Enables you to manage exclusions from a scan.|
If you want to ignore some of the parameter names during the tests, use
- To remove default exclusions, pass an empty string.
- To apply patterns for all HTTP methods, you can set an empty array to “methods”. For example
Updated 13 days ago