Frequently asked questions

How is Code Security different from Dependency Scanning?

Code Security analyzes your own source code for vulnerabilities and leaked secrets. Dependency Scanning checks the open-source packages you depend on against known CVEs. They scan the same repositories but answer different questions, and their findings are managed on separate pages.

Why can’t I see the secret in a secret finding?

We don’t store suspected secret values. The scanner, which runs in a special ephemeral context, redacts them before uploading its results to Oneleet persistent storage. To see what was flagged, open the file at the line the finding points to. If it’s a real secret, rotate it first, then remove it.

How do I stop scanning a repository, like one we’ve archived?

Remove it from Code Security. Open Code security → Configure → Repositories, select the repository, and choose Remove. Scans stop, and you can re-add the repository at any time.

Don’t just switch off Automatic scans for this. That leaves the repository (and its findings) in Code Security and will show up as a gap in your compliance monitoring.

I changed the scanner sensitivity and hundreds of findings appeared (or disappeared). What happened?

The sensitivity setting is a confidence threshold, and moving it only changes which findings are suppressed. Raising the threshold suppresses more findings. Lowering it (for example to All Issues) unsuppresses them after each repository’s next scan. Toggle the Suppressed filter on the dashboard to see what’s currently hidden.

Does a failing pull request check block merging?

Not by default. Code security pull request checks report a pass or fail as Oneleet Code Security Scan, and dependency pull request checks (in beta) report one as Oneleet Dependency Scan. Your Git provider’s settings decide whether a failure blocks merging. To block merges, make the check required in your branch protection rules on GitHub, or turn on Pipelines must succeed on GitLab.

For the full steps on each provider, see code security pull request checks and dependency pull request checks.

Can I suppress one specific finding without disabling the whole rule?

For secret findings, yes. Add a .gitleaksignore entry for that exact file, rule, and line. For static-analysis rules, ignore rules are scoped by rule ID and path pattern, so you can suppress a rule for one file or directory while keeping it active elsewhere. Inline suppression comments in the code (#nosec and friends) work too, but the platform has no record of them. For a single finding, resolving it as False positive or Accepted risk is usually the better tool anyway, since the decision is documented on the finding itself.

What does Oneleet store about my code?

Each scan gets a fresh, single-use container that’s destroyed within seconds of finishing, and it’s never shared across scans or tenants. It has no credentials to reach anything else in our infrastructure. Your repository is cloned into it only for that scan, using a short-lived GitHub App token on GitHub, your connection’s access token or SSH key on GitLab, or an OAuth access token on Azure DevOps and Bitbucket. The clone is destroyed with the container.

Afterwards, Oneleet keeps the finding metadata (rule, file path, line numbers, and scan history). Code snippets for findings are stored only if you enable Capture code snippets for the repository, and secret values are never stored at all.

Which git providers are supported?

You can connect repositories on GitHub, GitLab (gitlab.com and self-hosted), Azure DevOps, and Bitbucket, and scan them on a schedule or manually. Azure DevOps and Bitbucket are in beta. Pull request checks and autofixes work on GitHub and GitLab, with pull request checks in beta on GitLab. GitLab calls pull requests merge requests, so autofixes open there as merge requests. See Git provider support for the full feature matrix.