Scan a GitHub repository
Overview
Instead of downloading the CLI, you can let CAST Profiler scan a GitHub repository for you. A GitHub App gives the CAST Profiler service visibility of your repositories, and enabling a repository installs a GitHub Actions workflow that runs the scan and publishes the results. This page covers how that works and the decisions to make before you turn it on.
This route trades control for convenience, so read what changes in your repository before you enable it on anything that matters.
How it works
- Sign in to the CAST Profiler website with your GitHub account.
- Install the CAST Profiler GitHub App , published by CAST-Extend. Until it is installed, the repository list stays empty.
- Your repositories appear as a list. Choose one and confirm the installation.
- CAST Profiler commits a GitHub Actions workflow to that repository and the workflow runs.
- The repository row tracks the run and shows the outcome.
Each repository row reports a status and, once a scan completes, the three most prevalent technologies with their share of the source lines:
| Status | Meaning |
|---|---|
| Not Installed | The workflow has not been added to this repository yet |
| Queued | The workflow run is waiting for a runner |
| In Progress | The scan is running |
| Completed | Results are available |
| Analysis unsuccessful | The workflow run failed |
What changes in your repository
Enabling a repository is not a read-only operation. Confirm all three of these before you proceed:
- A commit is made to your repository. The confirmation dialog says so. The commit adds the workflow file that runs the scan.
- A second commit follows when the workflow goes out of date. CAST Profiler detects an outdated workflow and asks you to confirm an update, which is another commit.
- The scan runs on GitHub Actions runners, not on your own machine. Your source code is checked out onto GitHub’s infrastructure by the workflow, and the derived results are published to the CAST cloud service. This is a different data path from the CLI, where the scan happens on your premises and only the derived file is uploaded.
That last point is the one to settle first. If your organisation’s position is that source code is scanned on premises, use the CLI or the container image and do not enable the App.
Things to check before enabling
- Branch protection. If the default branch requires pull requests or reviews, a direct commit will be rejected and the installation will not complete. Either allow the App to bypass the rule, or use the CLI instead.
- Actions minutes. The workflow consumes your GitHub Actions allowance on every run.
- Repository selection. The App can be installed against selected repositories rather than all of them. Restrict it at install time rather than relying on which rows you click later.
- Monorepos. The workflow scans the repository it is installed in. A repository holding several unrelated applications produces one combined inventory, which is rarely what you want for scoping. Run the CLI against each application folder instead.
Which route to choose
| GitHub App | CLI or container | |
|---|---|---|
| Where the source is scanned | GitHub Actions runners | Your own machine or build agent |
| Writes to your repository | Yes, a workflow file | No |
| Works with an unattended pipeline | Through GitHub Actions only | Any pipeline, any scheduler |
| Works with no network access | No | Yes, with -of |
| Control over the version scanned | The workflow’s trigger | Whatever you check out |
| Setup effort | Lowest | A download or a container pull |
For a one-off look at a repository you already host on GitHub, the App is the fastest route. For onboarding an application into CAST Imaging, for anything on a schedule, and for anything where the source code must not leave your infrastructure, use the CLI or the container image.