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

OptionDescription
-a, --archiveA 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=fileIdThe archive ID, which can be received via the archive:upload command.
--crawler=url, -c=urlSpecifies a list of specific URLs that should be included during crawler discovery.

Additional options

OptionDescription
--host-filter=hostOrIp, -F=hostOrIpThe 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.
--moduleThe 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: dast
Example: 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=testNameSpecifies a list of relevant tests to execute during a scan.
Example: --test default_login_location xss.
--smartEnables 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
--bucketThis 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_side
The usage of --bucket and --test arguments together is not allowed.
--ntlmIf using a Repeater, add ntlmflag to keep an open connection between a Repeater and the target.
--token=apiKey, -t=apiKeyThe unique identifier used to authenticate a user. The token (API key) can be issued in your organization’s dashboard.
Required option.
--name=scanName, -n=scanNameThe name of the scan.
Required option.
--project, -pAllows 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
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.

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 Manging Your Authentications.
--template=templateId,-tp=templateIdTemplate 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.
--excludeEnables 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.