How it works
Musha scans your code on two paths. Both feed the same findings, the same states and the same policy.
| Pull request scan | Full-repository scan | |
|---|---|---|
| Question it answers | Does this change introduce a problem? | What is in the repository right now? |
| How it starts | Your CI job, on every pull request | A schedule you choose, or optionally every push |
| Access to your code | Your CI uploads it. Musha never reads your repository | You connect your Git provider. Musha clones, scans and deletes |
| What it looks at | What the pull request adds | The whole repository |
| Can stop a merge | Yes | No. It feeds the backlog |
Pull request scan
- Someone opens a pull request. Nothing changes in how your team works.
- Your CI job uploads the code. It identifies itself with a short-lived OIDC token (GitHub, GitLab) or a project-scoped, scan-only key (Azure DevOps, Bitbucket). It also sends which lines the pull request added. See Authentication.
- Musha scans it. The scanners run on the uploaded code: dependencies, infrastructure and secrets. The files are deleted from temporary storage when the scan ends, whether it succeeds or not.
- Musha comments on the pull request. The comment shows what blocks, what doesn't, accepted risks and technical debt.
- Your policy decides. If anything is at or above your threshold and the pull request introduced it, the scan is blocked. On GitHub the action then fails the job. See Technical debt.
The job runs on pull requests only, never on a bare push.
Full-repository scan
A vulnerability can be published months after a dependency came in through a clean pull request. The full-repository scan finds it.
- You connect your Git provider in Settings > Integrations (OAuth). You can disconnect at any time.
- You choose the cadence in Settings > Scan Policy: daily or weekly. The default is off.
- Musha clones the repository into a temporary space, scans it and deletes the clone. Only the metadata of each finding is kept.
- Findings go to your backlog with a severity and a state. Findings already in the backlog don't block your pull requests again.
Optionally, you can also scan on every push by adding a webhook in your Git provider. The Integration guide shows the URL and the secret, and the steps for each platform.
Findings
Every finding gets a stable fingerprint, so the same vulnerability seen in consecutive scans is one record. Its state, history and assignee are kept. Resolving it once keeps it resolved unless the vulnerability genuinely comes back. See Vulnerability states.
What Musha does not do
- It installs nothing in your infrastructure or your Git organization.
- It doesn't keep your code. In the pull request scan it only receives what your CI uploads. In the full scan the clone is deleted when it finishes.
- It doesn't use the credentials it finds. Secrets are reported with the value redacted, and Musha never calls an external service with them.
- It doesn't replace a penetration test. It is automated analysis that complements one.