Skip to main content

Troubleshooting

The CI job can't authenticate​

GitHub or GitLab (OIDC). The repository isn't connected to the project, or the pinned branch or ref doesn't match the one running. Open the project > Integration, check the connected repository, and look at Settings > CI / Pipeline for the full list. On GitHub the job also needs permissions: id-token: write.

Azure DevOps or Bitbucket (CI key).

  • The key is expired or revoked. Create a new one in CI keys.
  • The key belongs to a different project (403, code PROJECT_SCOPE_MISMATCH). Each key works for one project only.
  • MUSHA_API_KEY isn't set in the pipeline, or isn't exposed to the step. Keys start with msk_live_.

402 response. The subscription is canceled or suspended. Check Settings > Billing. See Trial and cancellation.

The scan returns 400​

Read the message: it names the field. The usual causes are a missing Idempotency-Key header (it must be a UUID), a missing scan_type, branch or project_id, or an empty archive. See Scans API.

Every finding is treated as new​

Musha couldn't work out which lines the pull request added, so it treats the findings as new instead of pre-existing. The usual cause is a shallow checkout. Use fetch-depth: 0 on GitHub, GIT_DEPTH: "0" on GitLab, fetchDepth: 0 on Azure DevOps and clone: depth: full on Bitbucket. See Technical debt.

Scan completed but no findings​

Is the scan type right? A repository with only Terraform needs iac or full, not sca.

Are the ecosystems enabled? Open Settings > Ecosystems and check that the ones you need are on. A disabled ecosystem is skipped.

Does the archive contain your manifests? If you build the archive yourself, check it:

tar -tzf scan.tar.gz | grep -E 'go\.mod|package-lock\.json|\.tf$'

Is the archive too large? The limit is 50 MB. Exclude generated or binary directories:

tar -czf scan.tar.gz \
  --exclude='.git' \
  --exclude='node_modules' \
  --exclude='vendor' \
  --exclude='*.jar' \
  --exclude='dist' \
  .

The job passed but the scan was blocked​

Only the GitHub action fails the job when a scan is blocked. Other CI needs an extra check. See GitLab CI.

PR comment not posted​

Is pr_id sent? The comment is only posted when the pull request number is part of the request. The generated pipelines send it. If you wrote your own, check it.

Is your Git provider connected? Musha posts the comment through your connection in Settings > Integrations. Without it the scan still runs, silently, with no comment.

Does the connected account have write access? On GitHub it needs at least Write access to the repository. The scan detail in the app shows whether the comment was posted and, if not, why.

A 429 response​

You reached a limit: the hourly cap, or the monthly scan quota for your plan. The response says which. See Limits. Musha never charges for extra scans; to scan more, change plan.

Scheduled scans not running​

Is the schedule on? Open Settings > Scan Policy. The default is off.

Is the Git connection still valid? Scheduled scans clone the repository with your connection. If the token was revoked or expired, they fail. Reconnect in Settings > Integrations.

Check Health. In Settings > Health, a project with three or more consecutive failed scans appears with a diagnostic message.

Findings not resolving automatically​

Musha resolves a finding when a scan completes and the vulnerability is gone. Make sure that:

  1. The scan completed successfully.
  2. The ecosystem that found it is still enabled.
  3. The files that held the vulnerability were part of the scan. For dependencies, that includes the lockfile (package-lock.json, Cargo.lock and so on), since it tells Musha the exact installed version.

Still stuck?​

Email support@mushasec.com with:

  • Your organization name
  • The scan ID, from the app URL or the API response
  • The X-Request-ID header of the failed request
  • The CI log of the failing step