This action runs a new security scan in Bright, or reruns an existing one.
Bright is a powerful dynamic application & API security testing (DAST) platform that security teams trust and developers love.
Scans any target, whether Web Apps, APIs (REST. & SOAP, GraphQL & more) or mobile, providing actionable reports
Bright works with your existing CI/CD pipelines – trigger scans on every commit, pull request or build with unit testing.
One file. One command. One scan. No UI needed.
Interacts with applications and APIs, instead of just crawling them and guessing. Scans are fast as our AI-powered engine can understand application architecture and generate sophisticated and targeted attacks.
Bright keeps false positives to a minimum, letting you focus on real issues and release better code faster.
Bright tests for all common vulnerabilities, such as SQL injection, CSRF, XSS, and XXE -- as well as uncommon vulnerabilities, such as business logic vulnerabilities.
More information is available on Bright’s:
Required. Scan name.
Example: name: GitHub scan ${{ github.sha }}
Required. Your Bright API authorization token (key). You can generate it in the Organization section in the Bright app. Find more information here.
Example: api_token: ${{ secrets.BRIGHT_TOKEN }}
Required when restarting an existing scan using its ID. You can get the scan ID in the Scans section in the Bright app.
Please make sure only to use the necessary parameters. Otherwise, you will get a response with the parameter usage requirements.
Example: restart_scan: ai3LG8DmVn9Rn1YeqCNRGQ)
Required. An array of discovery types. The following types are available:
archive- uses an uploaded HAR-file for a scancrawler- uses a crawler to define the attack surface for a scanoas- uses an uploaded OpenAPI schema for a scan
If no discovery type is specified,crawleris applied by default.
Example:
discovery_types: |
[ "crawler", "archive" ]A list of tests to run during a scan.
Example:
tests: |
[ "common_files", "id_enumeration" ]Recommended tests:
| Test name | Description | Value | Detectable vulnerabilities |
| Amazon S3 Bucket Takeover | Tests for S3 buckets that no longer exist to prevent data breaches and malware distribution | amazon_s3_takeover |
- Amazon S3 Bucket Takeover |
| Broken JWT Authentication | Tests for secure implementation of JSON Web Token (JWT) in the application | jwt |
- Broken JWT Authentication |
| Broken JWT Authentication | Tests for secure implementation of JSON Web Token (JWT) in the application | jwt |
- Broken JWT Authentication |
| Broken SAML Authentication | Tests for secure implementation of SAML authentication in the application | broken_saml_auth |
- Broken SAML Authentication |
| Brute Force Login | Tests for availability of commonly used credentials | brute_force_login |
- Brute Force Login |
| Business Constraint Bypass | Tests if the limitation of number of retrievable items via an API call is configured properly | business_constraint_bypass |
- Business Constraint Bypass |
| Client-Side XSS (DOM Cross-Site Scripting) |
Tests if various application DOM parameters are vulnerable to JavaScript injections | dom_xss |
- Reflective Cross-site scripting (rXSS) - Persistent Cross-site scripting (pXSS) |
| Common Files Exposure | Tests if common files that should not be accessible are accessible | common_files |
- Exposed Common File |
| Cookie Security Check | Tests if the application uses and implements cookies with secure attributes | cookie_security |
- Sensitive Cookie in HTTPS Session Without Secure Attribute - Sensitive Cookie Without HttpOnly Flag - Sensitive Cookie Weak Session ID |
| Cross-Site Request Forgery (CSRF) | Tests application forms for vulnerable cross-site filling and submitting | csrf |
- Unauthorized Cross-Site Request Forgery (CSRF) - Authorized Cross-Site Request Forgery (CSRF) |
| Cross-Site Scripting (XSS) | Tests if various application parameters are vulnerable to JavaScript injections | xss |
- Reflective Cross-Site Scripting (rXSS) - Persistent Cross-Site Scripting (pXSS) |
| Default Login Location | Tests if login form location in the target application is easy to guess and accessible | default_login_location |
- Default Login Location |
| Directory Listing | Tests if server-side directory listing is possible | directory_listing |
- Directory Listing |
| Email Header Injection | Tests if it is possible to send emails to other addresses through the target application mailing server, which can lead to spam and phishing | email_injection |
- Email Header Injection |
| Exposed AWS S3 Buckets Details (Open Buckets) |
Tests if exposed AWS S3 links lead to anonymous read access to the bucket | open_buckets |
- Exposed AWS S3 Buckets Details |
| Exposed Database Details (Open Database) |
Tests if exposed database connection strings are open to public connections | open_buckets |
- Exposed Database Details - Exposed Database Connection String |
| Full Path Disclosure (FPD) | Tests if various application parameters are vulnerable to exposure of errors that include full webroot path | full_path_disclosure |
- Full Path Disclosure |
| Headers Security Check | Tests for proper Security Headers configuration | header_security |
- Misconfigured Security Headers - Missing Security Headers - Insecure Content Secure Policy Configuration |
| HTML Injection | Tests if various application parameters are vulnerable to HTML injection | html_injection |
- HTML Injection |
| Improper Assets Management | Tests if older or development versions of API endpoints are exposed and can be used to get unauthorized access to data and privileges | improper_asset_management |
- Improper Assets Management |
| Insecure HTTP Method (HTTP Method Fuzzer) |
Tests enumeration of possible HTTP methods for vulnerabilities | http_method_fuzzing |
- Insecure HTTP Method |
| Insecure TLS Configuration | Tests SSL/TLS ciphers and configurations for vulnerabilities | insecure_tls_configuration |
- Insecure TLS Configuration |
| Known JavaScript Vulnerabilities (JavaScript Vulnerabilities Scanning) |
Tests for known JavaScript component vulnerabilities | retire_js |
- JavaScript Component with Known Vulnerabilities |
| Known WordPress Vulnerabilities (WordPress Scan) |
Tests for known WordPress vulnerabilities and tries to enumerate a list of users | wordpress |
- WordPress Component with Known Vulnerabilities |
| LDAP Injection | Tests if various application parameters are vulnerable to unauthorized LDAP access | ldapi |
- LDAP Injection - LDAP Error |
| Local File Inclusion (LFI) | Tests if various application parameters are vulnerable to loading of unauthorized local system resources | lfi |
- Local File Inclusion (LFI) |
| Mass Assignment | Tests if it is possible to create requests with additional parameters to gain privilege escalation | mass_assignment |
- Mass Assignment |
| OS Command Injection | Tests if various application parameters are vulnerable to Operation System (OS) commands injection | osi |
- OS Command Injection |
| Prototype Pollution | Tests if it is possible to inject properties into existing JavaScript objects | proto_pollution |
- Prototype Pollution |
| Remote File Inclusion (RFI) | Tests if various application parameters are vulnerable to loading of unauthorized remote system resources | rfi |
- Remote File Inclusion (RFI) |
| Secret Tokens Leak | Tests for exposure of secret API tokens or keys in the target application | secret_tokens |
- Secret Tokens Leak |
| Server Side Template Injection (SSTI) | Tests if various application parameters are vulnerable to server-side code execution | ssti |
- Server Side Template Injection (SSTI) |
| Server Side Request Forgery (SSRF) | Tests if various application parameters are vulnerable to internal resources access | ssrf |
- Server Side Request Forgery (SSRF) |
| SQL Injection (SQLI) | SQL Injection tests vulnerable parameters for SQL database access | sqli |
- SQL Injection: Blind Boolean Based - SQL Injection: Blind Time Based - SQL Injection - SQL Database Error Message in Response |
| Unrestricted File Upload | Tests if file upload mechanisms are validated properly and denies upload of malicious content | file_upload |
- Unrestricted File Upload |
| Unsafe Date Range (Date Manipulation) |
Tests if date ranges are set and validated properly | date_manipulation |
- Unsafe Date Range |
| Unsafe Redirect (Unvalidated Redirect) |
Tests if various application parameters are vulnerable to injection of a malicious link which can redirect a user without validation | unvalidated_redirect |
- Unsafe Redirect |
| User ID Enumeration | Tests if it is possible to collect valid user ID data by interacting with the target application | id_enumeration |
- Enumerable Integer-Based ID |
| Version Control System Data Leak | Tests if it is possible to access Version Control System (VCS) resources | version_control_systems |
- Version Control System Data Leak |
| XML External Entity Injection | Tests if various XML parameters are vulnerable to XML parsing of unauthorized external entities | xxe |
- XML External Entity Injection |
Required if the discovery type is set to archive or oas. ID of a HAR-file or an OpenAPI schema you want to use for a scan. You can get the ID of an uploaded HAR-file or an OpenAPI schema in the Storage section on app.brightsec.com.
Example:
FILE_ID=$(bright-cli archive:upload \
--token ${{ secrets.BRIGHT_TOKEN }} \
--discard true \
./example.har)
Required if the discovery type is set to crawler. Target URLs to be used by the crawler to define the attack surface.
Example:
crawler_urls: |
[ "http://vulnerable-bank.com" ]Required when the the discovery type is set to archive. Allows selecting specific hosts for a scan.
A list of regex patterns for parameter names you would like to ignore during the tests.
Example:
exclude_params: |
[ "userId", "orgId" ]A list of JSON strings that contain patterns for entry points you would like to ignore during the tests.
Example:
exclude_entry_points: |
[ { "methods": [ "POST" ], "patterns": [ "users\/.+\/?$" ] } ]To remove default exclusions pass an empty array as follows:
Example:
exclude_entry_points: |
[]To apply patterns for all HTTP methods, you can set an empty array to methods:
exclude_entry_points: |
[ { "methods": [], "patterns": [ "users\/.+\/?$" ] } ]Url of the resulting scan
ID of the created scan. This ID could then be used to restart the scan, or for the following GitHub actions:
steps:
- name: Start Bright Scan
id: start
uses: NeuraLegion/[email protected]
with:
api_token: ${{ secrets.BRIGHT_TOKEN }}
name: GitHub scan ${{ github.sha }}
discovery_types: |
[ "crawler", "archive" ]
crawler_urls: |
[ "http://vulnerable-bank.com" ]
file_id: LiYknMYSdbSZbqgMaC9Sj
- name: Get the output scan url
run: echo "The scan was started on ${{ steps.start.outputs.url }}"steps:
- name: Start Bright Scan
id: start
uses: NeuraLegion/[email protected]
with:
api_token: ${{ secrets.BRIGHT_TOKEN }}
name: GitHub scan ${{ github.sha }}
restart_scan: ai3LG8DmVn9Rn1YeqCNRGQ
- name: Get the output scan url
run: echo "The scan was started on ${{ steps.start.outputs.url }}"