Skip to main content

Troubleshooting

Scan stuck in pending​

The scan was received but the worker hasn't picked it up yet. This usually resolves within 60 seconds.

If it stays pending for more than 2–3 minutes:

  1. Check Settings → Health for any system issues flagged by Musha.
  2. Email support@mushasec.com with the scan ID and your X-Request-ID response header.

Scan completed but no findings​

Is the scan type correct? Check that scan_type matches what's in your repo. A repo with only Terraform files needs iac or full, not sca.

Are the right ecosystems enabled? Go to Settings → Repo Scanning and verify the ecosystems you need are checked. Unchecking an ecosystem prevents Musha from scanning it.

Is the tarball packaged correctly? Run locally to confirm the archive contains your manifest files:

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

Is the tarball too large? Maximum is 50 MB. If your repo exceeds this, use changed_files to scan only modified files, or exclude large binary/generated directories:

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

API key errors​

401 Unauthorized

  • The key is expired. Create a new one in Settings → API Keys.
  • The key was revoked. Check the API keys list for its status.
  • You're sending the wrong key format. Musha API keys start with msk_live_.

403 Forbidden

  • Your subscription is expired or canceled. Check Settings → Billing.
  • Your API key doesn't have the role required for this endpoint. Only Admin and Owner roles can create API keys, manage projects, or export findings.

PR comment not posted​

Is pr_id included in the scan request? The PR comment is only posted when pr_id (the numeric PR/MR number) is included in the request. Check your CI workflow.

Is the OAuth integration connected? Musha needs an active OAuth connection to your Git platform to post comments. Go to Settings → Integrations and verify the connection is active (green status).

Does the connected account have write access? The OAuth token must belong to an account with write access to the repository. For GitHub, the account needs at least Write access to post PR comments.

scan_warnings in the response​

scan_warnings contains diagnostic messages from the scanner. Common warnings:

WarningMeaning
"could not resolve dependency: foo@1.2.3"The dependency wasn't found in the OSV database. Not an error — it may just not have any known CVEs.
"no manifests found for ecosystem: node"Node.js ecosystem is enabled but no package-lock.json, yarn.lock, or pnpm-lock.yaml was found in the archive.
"IaC rule evaluation timeout"A specific Rego rule timed out. The finding is skipped. Report to support.

Scheduled scans not running​

Is the scan schedule configured? Go to Projects → [your project] → Settings and verify the schedule is set to Daily or Weekly (not Off).

Is the OAuth integration still valid? Scheduled scans clone the repo using your OAuth token. If the token was revoked or expired, the scan fails. Check Settings → Integrations.

Check System Health Go to Settings → Health — if a project has 3+ consecutive failed scans, it appears there with a diagnostic message.

Findings not resolving automatically​

Musha resolves findings automatically when a scan runs and the vulnerability is no longer present. Requirements:

  1. The scan must complete successfully (not fail or error out).
  2. The same ecosystem that detected the original finding must be enabled in settings.
  3. The same files that contained the vulnerability must be included in the tarball.

If you fixed a dependency but the finding isn't resolving, make sure the lockfile (package-lock.json, Cargo.lock, etc.) is included in the archive — the lockfile is what Musha uses to determine the exact installed version.

Still stuck?​

Email support@mushasec.com with:

  • Your tenant domain / organization name
  • The scan ID (from the API response or the app URL)
  • The X-Request-ID header from the failed API response
  • The CI log output from the curl command

The X-Request-ID is the fastest way for us to find the exact request in our logs.