Frequently asked questions
How is Code Security different from Dependency Scanning?
Section titled “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?
Section titled “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?
Section titled “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?
Section titled “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?
Section titled “Does a failing pull request check block merging?”Only if you make it. The Oneleet Code Security Scan check reports pass or fail. Add it as a required status check in your GitHub branch protection rules to actually block merges. See Pull request checks.
Can I suppress one specific finding without disabling the whole rule?
Section titled “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?
Section titled “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 or your connection’s access token or SSH key on GitLab, and 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?
Section titled “Which git providers are supported?”GitHub gets the full feature set of scheduled and manual scans, pull request checks, and autofixes. GitLab repositories (gitlab.com and self-hosted) can be connected, scanned, and receive autofixes as merge requests, but merge request checks aren’t available yet.