Breadcrumbs

Rolling Out SAST Scanning for Selected Repositories

Overview

If you already scan your repositories with Mend SCA and want to gradually enable SAST scanning on selected repositories, follow the steps in this guide to configure SAST without changing your existing SCA setup.

Applies to:

  • Mend for GitHub.com

  • Mend for GitHub Enterprise

How It Works

Your existing global-config.json (in the whitesource-config repository) already controls which repos are scanned by Mend SCA. You can now add a sast sub-key inside ignoredRepos or includedRepos to control SAST scanning independently -- without affecting your SCA setup.

Use this configuration to:

  • Keep SCA running on all your repos as it does today

  • Enable SAST only on a handful of repos to start with

  • Expand SAST coverage gradually by updating a single config file

Option A: Include Only Specific Repos for SAST

Use this approach when you want to start small -- pick a few repos and enable SAST only for them.

  1. Open the whitesource-config repository.

  2. Edit global-config.json.

  3. Add one of the includedRepos.sast examples below.

  4. Commit and push the change.

Inline list

To enable SAST for a short list of repositories, add the sast sub-key under includedRepos in your global-config.json file:

JSON
{
  "includedRepos": {
    "sast": {
      "exactNames": [
        "myorg/service-api",
        "myorg/auth-service"
      ]
    }
  }
}

This enables SAST scanning only for myorg/service-api and myorg/auth-service. All other repos continue with SCA only.

Using a file

If you have a longer list, you can manage it in a separate file instead. Set exactNamesFile to true:

JSON
{
  "includedRepos": {
    "sast": {
      "exactNamesFile": true
    }
  }
}

Then create a file called sast-included-repos.txt in the same whitesource-config repository, with one repo per line:

# Repos to scan with SAST
myorg/service-api
myorg/auth-service
myorg/payments-service

  • Blank lines and lines starting with # are ignored

  • Leading/trailing whitespace is trimmed

Option B: Exclude Specific Repos from SAST

Use this approach when you want SAST on most repos but need to skip a few (e.g. archived repos, generated code, or repos that are out of scope).

  1. Open the whitesource-config repository.

  2. Edit global-config.json.

  3. Add one of the ignoredRepos.sast examples below.

  4. Commit and push the change.

Inline list

JSON
{
  "ignoredRepos": {
    "sast": {
      "exactNames": [
        "myorg/legacy-monolith",
        "myorg/generated-sdk"
      ]
    }
  }
}

SAST runs on all repos except the ones listed.

Using a file

JSON
{
  "ignoredRepos": {
    "sast": {
      "exactNamesFile": true
    }
  }
}

Create sast-ignored-repos.txt in the whitesource-config repository:

# Repos excluded from SAST
myorg/legacy-monolith
myorg/generated-sdk

Combining with Existing SCA Filters

If you already use top-level ignoredRepos or includedRepos for SCA, the sast sub-key works within that existing scope. It cannot expand beyond it.

With ignoredRepos

If you already exclude some repos globally, you can additionally exclude repos from SAST only:

JSON
{
  "ignoredRepos": {
    "exactNames": ["myorg/archived-app"],
    "sast": {
      "exactNames": ["myorg/legacy-monolith", "myorg/generated-sdk"]
    }
  }
}

The result:

Repo

SCA

SAST

myorg/archived-app

No

No

myorg/legacy-monolith

Yes

No

myorg/generated-sdk

Yes

No

Any other repo

Yes

Yes

myorg/archived-app is excluded from everything by the top-level exactNames. myorg/legacy-monolith and myorg/generated-sdk still get SCA but are excluded from SAST by the sast sub-key.

If a repo appears in both the top-level exactNames and sast.exactNames, the top-level exclusion already covers it -- listing it again under sast has no additional effect:

JSON
{
  "ignoredRepos": {
    "exactNames": ["myorg/archived-app"],
    "sast": {
      "exactNames": ["myorg/archived-app", "myorg/legacy-monolith"]
    }
  }
}

Repo

SCA

SAST

myorg/archived-app

No

No

myorg/legacy-monolith

Yes

No

Any other repo

Yes

Yes

With includedRepos

If your config already limits SCA to specific repos, the sast sub-key is additive within that set:

JSON
{
  "includedRepos": {
    "exactNames": ["myorg/repo-a", "myorg/repo-b"],
    "sast": {
      "exactNames": ["myorg/repo-a"]
    }
  }
}

The result:

Repo

SCA

SAST

myorg/repo-a

Yes

Yes

myorg/repo-b

Yes

Yes

Any other repo

No

No

Note: the sast sub-key is additive within the top-level set, so both repo-a and repo-b get SAST.

If the sast sub-key references a repo that is not in the top-level list, it is simply ignored:

JSON
{
  "includedRepos": {
    "exactNames": ["myorg/repo-a", "myorg/repo-b"],
    "sast": {
      "exactNames": ["myorg/repo-c"]
    }
  }
}

Here, repo-c will not get SAST (or SCA) because it is not in the top-level included set.

Important Rules

  • ignoredRepos.sast and includedRepos.sast cannot be used together. Pick one approach: include or exclude.

  • exactNames and exactNamesFile are mutually exclusive within the same sub-key. Use one or the other.

  • Changes take effect on the next push to each repository. Adding or removing a repo from the list does not trigger a scan automatically.

Quick Start Checklist

  1. Decide whether you want to include specific repos (Option A) or exclude specific repos (Option B)

  2. Open your whitesource-config repository

  3. Edit global-config.json and add the sast sub-key as shown above

  4. If using a file-based list, create sast-included-repos.txt or sast-ignored-repos.txt

  5. Commit and push the changes

  6. SAST scanning will apply on the next push to each affected repository

Further Reading