Running a Scan
This command enables you to specify one or more discovery strategies. For example, using the --crawler option and/or the generated .HAR files, separately or concurrently. This means that you can handle client-side dynamic content, JavaScript, and so on.
Note:
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.
Discovery options
| Option | Description |
|---|---|
-a, --archive | A collection your app's http/websockets logs into HAR file. Usually you can use browser dev tools or our browser web extension. |
--archive=fileId, -a=fileId | The archive ID, which can be received via the archive:upload command. |
--crawler=url, -c=url | Specifies a list of specific URLs that should be included during crawler discovery. |
Additional options
| Option | Description |
|---|---|
--host-filter=hostOrIp, -F=hostOrIp | The list of specific hosts to be included in the scan. |
--header=headerName:headerValue,-H=headerName:headerValue | 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. |
--module | The DAST module tests for specific scenarios, mainly OWASP top 10 and other common scenarios. The Fuzzer module generates various scenarios to test for unknown vulnerabilities, providing automated AI led fuzzing testing. This module can be coupled with the Repeater to find additional vulnerabilities. Default: dastExample: bright-cli scan:run --module fuzzer |
--repeater=repeaterId,--agent=repeaterId | Specifies a list of Repeater UUIDs that should be connected with the scan. Warning: The alias --agent=repeaterIdis depricated. |
--test=testName | Specifies a list of relevant tests to execute during a scan. This is the list of all available tests: "amazon_s3_takeover" "jwt" "broken_saml_auth" "brute_force_login" "business_constraint_bypass" "common_files" "cookie_security" "csrf" "xss" "css_injection" "cve_test" "date_manipulation" "default_login_location" "directory_listing" "email_injection" "excessive_data_exposure" "file_upload" "full_path_disclosure" "graphql_introspection" "header_security" "html_injection" "http_method_fuzzing" "id_enumeration" "iframe_injection" "improper_asset_management" "insecure_tls_configuration" "retire_js" "lrrl" "ldapi" "lfi" "mass_assignment" "nosql" "open_database" "osi" "proto_pollution" "prompt_injection" "rfi" "secret_tokens" "server_side_js_injection" "ssrf" "ssti" "sqli" "stored_xss" "unvalidated_redirect" "version_control_systems" "wordpress" "xxe" "xpathi" "open_cloud_storage" "insecure_output_handling"If this option is not specified, these tests will not be executed by default: "business_constraint_bypass" "cve_test" "date_manipulation" "excessive_data_exposure" "id_enumeration" "mass_assignment" "open_cloud_storage" "prompt_injection" "retire_js" "lrrl"Example: --test default_login_location xss. |
--smart | Enables you to use automatic smart decisions, such as parameter skipping, detection phases, and so on to minimize scan time. When set to false (turned off), all tests are run on all parameters, which increases the coverage at the expense of scan time.Default: --smart true |
--bucket | This key allows the user to supply a list of the buckets to use it to start the scan. The list of bucket's API: - Client-side attacks: client_side- Server-side attacks: server_side- API attacks: api- Legacy attacks: legacy- CVE tests: cve- Advanced attacks: advanced- Business logic attacks: business_logicExample: bright-cli scan:run --bucket api client_sideThe usage of --bucket and --test arguments together is not allowed. |
--ntlm | If using a Repeater, add ntlmflag to keep an open connection between a Repeater and the target. |
--token=apiKey, -t=apiKey | The unique identifier used to authenticate a user. The token (API key) can be issued in your organization’s dashboard. Required option. |
--name=scanName, -n=scanName | The name of the scan. Required option. |
--project, -p | 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. |
--param=path/query/fragment/header/body/artifical-fragment/artifical-query | Note: This argument can be passed multiple times in the same command. Default: --parameter body query fragment. |
--auth=authObjectID,-o=authObjectID | Specifies the ID of the authentication object to be connect to the scan. Find more info about using an authentication object at Managing Your Authentications. |
--template=templateId,-tp=templateId | Template ID. Allows to import scan settings from a template. If any scan settings are specified explicitly, they will override template settings. Examples: scan:run -t apiKey -n scanName -p projectId -tp templateId – start scan with all settings imported from the template.scan:run -t apiKey -n scanName -p projectId -tp templateId --test testName – start scan will all settings but tests imported from the template. |
--exclude | Enables you to manage exclusions from a scan. If you want to ignore some of the parameter names during the tests, use exclude-param. For example, --exclude-param ID$.--exclude-entry-point A list of JSON strings that contain patterns for entry points you would like to ignore during the tests.Important: - 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 {“methods”: [], “patterns”: “users\\/?$”}. |
--api=clusterUrl | (Deprecated). Set the API endpoint domain, for VPC, use: --api <https://private-domain.brightsec.com> |
--integration, -i(Deprecated) | 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. 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. Format: -i "service:repository"Example: -i "github:example-app" If you want to connect several repositories for one scan, you can specify them one after another: -i "github:example-app" -i "jira:example-app"Important: - To connect a ticketing service and a repository for a scan, the token (API key) that you use for the scan must include the integration.repos:read scope.- The --integration (-i) parameter cannot be used without a valid --project (-p) parameter (see above). Make sure that you connect a repository associated with the specified project. |
--entrypoint, -e | 1. Specify Entrypoint IDs: Users can pass a list of entrypoint IDs to run the scan on specific entrypoints. Example: bright-cli scan:run --entrypoint <entrypoint_id1> <entrypoint_id2> <entrypoint_id3>2. Scan Project-Level Entrypoints: If a project is specified and the --entrypoint flag is added without specifying entrypoint IDs, the scan will run on the first 2000 project-level Entrypoints.Example: bright-cli scan:run --project <PROJECT_ID> --entrypoint |
| --concurrency | Number of maximum concurrent requests allowed to be sent to the target, can range between 1 to 50 (default: 10). |
--help | Command option to the scan:run help command.Example: bright-cli scan:run --helpResponse: List entrypoint IDs to scan specific entrypoints, or use with --project to scan the first 2000 project entrypoints if no IDs are specified |
Updated 11 days ago