The affordable no limit web vulnerability scanner.

Use SOOS DAST to:

1. Scan web apps and APIs defined by OpenAPI, SOAP, or GraphQL
2. Containerized solution runs in your environment
3. Manage issues via single-pane web dashboard shared with SOOS SCA
4. Track tickets in Jira or GitHub Issues

You can use the Action as follows:

• Update the .github/workflow/main.ymlfile to include a step like this

on: [push]

jobs:
  soos_dast_analysis_example:
    name: SOOS DAST Analysis Example
    runs-on: ubuntu-latest
    steps:
      - name: Run SOOS DAST Analysis
        uses: soos-io/soos-dast-github-action@v1.2.3
        with:
          client_id: ${{ secrets.SOOS_CLIENT_ID }}
          api_key: ${{ secrets.SOOS_API_KEY }}
          project_name: "DAST-GitHub-Action-Test"
          scan_mode: "baseline"
          api_url: "https://api.soos.io/api/"
          target_url: "https://www.example.com/"

You can choose between three Jobs:

• Baseline Analysis
• Full Analysis
• API Analysis

The soos-io/soos-dast-github-action Action has properties which are passed to the action using with.

It runs the ZAP spider against the specified target for (by default) 1 minute and then waits for the passive scanning to complete before reporting the results.

This means that the script doesn't perform any actual ‘attacks’ and will run for a relatively short period of time (a few minutes at most).

By default, it reports all alerts as WARNings but you can specify a config file which can change any rules to FAIL or IGNORE.

This mode is intended to be ideal to run in a CI/CD environment, even against production sites.

It runs the ZAP spider against the specified target (by default with no time limit) followed by an optional ajax spider scan and then a full active scan before reporting the results.

This means that the script does perform actual ‘attacks’ and can potentially run for a long period of time.

By default, it reports all alerts as WARNings but you can specify a config file which can change any rules to FAIL or IGNORE. The configuration works in a very similar way as the Baseline Analysis

It is tuned for performing scans against APIs defined by OpenAPI, SOAP, or GraphQL via a URL where the spec file is publicly available.

It imports the definition that you specify and then runs an Active Scan against the URLs found. The Active Scan is tuned to APIs, so it doesn't bother looking for things like XSSs.

It also includes 2 scripts that:

• Raise alerts for any HTTP Server Error response codes
• Raise alerts for any URLs that return content types that are not usually associated with APIs

If you need to run a scan against url that needs authorization and the only thing needed is to set an authorization header in the form of authorization: Bearer token-value then this is the most straight forward workflow (note that for this method you should have the bearer token value beforehand).

example workflow:

on: [push]
jobs:
  synchronous-analysis-with-blocking-result:
    name: SOOS DAST Scan
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master
    - name: Run SOOS DAST Baseline Analysis performing bearer token authentication
      uses: soos-io/soos-dast-github-action@v1.2.0
      with:
        client_id: ${{ secrets.SOOS_CLIENT_ID }}
        api_key: ${{ secrets.SOOS_API_KEY }}
        project_name: "DAST-bearer-token"
        scan_mode: "baseline"
        bearer_token: "token-value"
        api_url: "https://api.soos.io/api/"
        target_url: "https://www.example.com/"

Using this option there will be an automated login form authentication performed before running the DAST scan to get the bearer token that will be then added to every request as the authorization header.

This is how a example workflow will look like:

on: [push]

jobs:
  synchronous-analysis-with-blocking-result:
    name: SOOS DAST Scan
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master
    - name: Run SOOS DAST Baseline Analysis performing form authentication
      uses: soos-io/soos-dast-github-action@v1.2.0
      with:
        client_id: ${{ secrets.SOOS_CLIENT_ID }}
        api_key: ${{ secrets.SOOS_API_KEY }}
        project_name: "DAST-login-form"
        scan_mode: "baseline"
        api_url: "https://api.soos.io/api/"
        target_url: "https://example.com/"
        auth_login_url: "https://example.com/login"
        auth_username: "username-to-fill-field"
        auth_password: "password-to-fill-field"
        auth_username_field: "username-html-input-id"
        auth_password_field: "password-html-input-id"
        auth_submit_field: "submit-html-input-id"

In case you need to perform a DAST analysis against an OAuth application this is the workflow that you should follow. In this scenario the DAST tool will perform a request to get the access_token before doing any analysis.

Workflow example:

on: [push]

jobs:
  synchronous-analysis-with-blocking-result:
    name: SOOS DAST Scan
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master
    - name: Run SOOS DAST Baseline Analysis performing OAuth
      uses: soos-io/soos-dast-github-action@v1.2.0
      with:
        client_id: ${{ secrets.SOOS_CLIENT_ID }}
        api_key: ${{ secrets.SOOS_API_KEY }}
        project_name: "DAST-OAuth"
        scan_mode: "baseline"
        api_url: "https://api.soos.io/api/"
        target_url: "https://example.com/"
        oauth_token_url: "https://example.com/token"
        oauth_parameters: "client_secret:value ,client_id:value , grant_type:value"

• ZAP