What we still need to verify : 2 points in this profile are not yet confirmed against vendor documentation.
- Exact language coverage per scanner type: verify against vendor documentation
- Current module breakdown across SCA, SAST, IaC and permissions: confirm with vendor
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
Arnica connects to your source control provider through its app or API rather than to your build system. From there it reads repository contents and listens to push and pull request events, so scanning happens on code change rather than inside a pipeline job. The company calls this pipelineless, and the practical consequence is that you do not add steps to build definitions or ask teams to maintain scanner configuration in each repo. Onboarding a new repository is a permission change, not an engineering task.
On top of that connection it runs several analyses: dependency inventory and vulnerability matching against advisory data, secret detection across current code and commit history, static analysis of changed code, infrastructure as code checks, and a distinctly different one, source control posture. That last piece looks at who has write access to what, which identities are stale, which branches lack protection, and whether commits are signed. Findings are attributed to the developer whose commit introduced them and delivered to that person in chat.
Where it fits
This runs continuously against repositories, so it sits between the developer laptop and the pull request rather than at a build gate. A security team owns the policy and the tenant, but day-to-day interaction is with developers in chat. It works best where source control is centralized on one supported provider and teams actually read notifications. If your risk sits in artifacts produced after code leaves source control, this angle will miss it.
Strengths
- Onboarding is genuinely fast because there is no pipeline integration work per repository.
- Commit-level attribution routes each finding to the person who wrote the code rather than to a shared queue.
- Covering source control permissions and branch protection alongside code findings addresses a risk class most scanners ignore entirely.
Limitations
- Because it hooks source control rather than the build, it sees what is committed, not what is resolved at build time. Dependency trees that only materialize during a build are harder to model accurately.
- Breadth across SCA, secrets, static analysis, infrastructure as code and permissions means no single engine is as deep as a dedicated specialist tool in that area.
- It is a single-vendor SaaS with access to your entire codebase, which needs a real review in regulated environments.
Who it suits
A sensible choice for fast-moving engineering organizations on GitHub, GitLab, Azure DevOps or Bitbucket that want broad coverage without a pipeline integration project, and that value developer-directed notification over a central triage workflow. A weaker fit for teams that need deep reachability analysis, that build outside source control, or that require self-hosted deployment.
Used Arnica? Recommend it under your own name and title.
Recommend this tool