The life of a pull request, with Musha in the middle.
Follow a change from the moment someone opens it until it is merged, and see where Musha comes in, what it sees and what it does not.
- Your team
Someone opens a pull request
Nothing changes in how your team works.
- Your CI
The job uploads the code to Musha
It identifies itself with a short-lived token or a scan-only key. Musha never enters the repository.
- Musha
Four engines review what the PR adds
Code, dependencies, infrastructure and secrets. Pre-existing issues are marked as debt, not blamed on the PR.
- Your pull request
A comment with the findings
Severity, location and what to fix. If anything exceeds your threshold, the job fails and the merge stops.
- Your main branch
It gets fixed, or merged
What was already in the backlog does not block. New and critical does. You choose the threshold.
Your CI uploads the code. Musha never enters your repository.
You add a job to your pipeline, generated by Musha for your platform. On every pull request that job sends the code, Musha analyzes it and replies in the same PR.
- Only what changes
- What the PR adds is evaluated. What already existed shows up as technical debt and does not block the change.
- No stored credentials
- On GitHub and GitLab the job identifies itself with a short-lived token bound to that run (OIDC). On Azure DevOps and Bitbucket, with a scan-only key limited to the project.
- The merge stops by itself
- If there are findings above the threshold you defined, the job fails. Your branch rule does the rest.
- Never on bare pushes
- The job runs only on pull requests, on purpose. A push without a PR spends no quota and feeds nothing.
What was already in the repository counts too.
A vulnerability can be published months after a dependency came in through a clean PR. The full scan finds it and puts it in your backlog, without anyone touching the code.
- OAuth connection
- You connect your Git provider from Musha and disconnect it whenever you want.
- Your cadence
- Daily or weekly. No changes to your CI. Optionally, also on every push with a webhook you configure.
- Clone, scan, delete
- The repository lives in a temporary space only while the scan runs. All that remains is the metadata of each finding.
- A backlog with status
- Every finding has a severity and a status. What is already in the backlog does not block your pull requests again.
You decide what stops a merge.
The policy lives in Musha and is enforced on the server. There is nothing to configure in your pipeline.
-
You choose the severity that blocks
By default, only critical.
-
What is already in your backlog does not block
It appears as context in the comment, not as a block.
-
You can accept a risk on a PR
It is recorded and stops blocking.
-
Block pre-existing issues too, if you want
For what is not yet in the backlog. Off by default.
Four engines, on both paths.
Same severity scale and same finding format for all four.
-
Source code
Insecure patterns in your own code.
-
Dependencies
Known vulnerabilities, with the version that fixes them.
-
Infrastructure
Terraform, CloudFormation, Kubernetes, Helm and Dockerfiles.
-
Secrets
Keys and tokens in the code, with the value redacted.
We would rather say it first.
-
It installs nothing.
No agents in your infrastructure and no apps in your Git organization.
-
It does not keep your code.
In the PR scan it never sees it in your repository; in the full scan, the clone is deleted when it finishes.
-
It does not use the credentials it finds.
It reports them, redacted. It never calls an external service with them.
-
It does not replace a pentest.
It is automated analysis; it complements the work of a consultancy.
Put Musha in the middle of your next pull request.
14-day trial. One job in your CI and you are set.