Why are hotspots capped at medium?

Because a pattern rule cannot prove that untrusted input reaches the code it matched. Rating it high would put a guess on the same level as a demonstrated flaw. Hotspots are still worth reviewing — they are just not allowed to crowd out the findings that are proven.

Does secret detection look at git history?

No. The scan reads the current state of the branch from a shallow clone, so a secret that was committed and later removed is not found. It also does not test whether a detected credential is live. If a secret has ever been pushed, rotate it — removing it from the file is not enough.

Can we write our own rules?

Not from the console today. The rule set is maintained by Onam; tell us about patterns specific to your codebase and we can discuss adding them.

Will a new scan remember the findings we already triaged?

Not reliably today. Each scan produces its own list of findings and the console shows the latest scan per project; triage decisions are not yet carried from one scan to the next.

Static Analysis (SAST)

Which findings in this scan are real, and which only look suspicious?

Static analysis that tells you what it can prove — and what it cannot.

Onam's static analysis runs community security packs, curated taint rules and reviewed pattern rules over your source, then splits the result: security issues it can show, and hotspots a person needs to confirm. Secret detection runs in the same pass.

See it in my cloud Read the docs

SAST

source code

SCA + SBOM

dependencies

IaC

templates

DAST

running apps

Why it matters How it works What you get FAQ

Why this matters

A pattern rule flags every call to eval, every string that looks like SQL, every file that mentions a password.

Some of those are real. Most are not, and the scanner cannot tell which, so it calls all of them high. The developer opens the report, sees the noise, and closes it — along with the one finding that was a genuine injection path from a request parameter to a database query.

When every match is an alert

A scanner that gives a regex hit the same severity as a proven injection teaches the team to ignore both. The fix is not fewer rules — it is being honest about what each rule can prove.

Severity follows evidence

How does it actually work?

The mechanism, not the marketing

1
The scanner makes a shallow clone of the branch you chose and skips what is not your code: dependency and vendor folders, build output, minified files and anything over half a megabyte.
2
Files are routed by extension. Python, JavaScript, TypeScript, Java, C#, Go, C, C++ and Ruby go to static analysis on the open-source Semgrep engine; Terraform, YAML, JSON and Dockerfiles go to the IaC checker in the same job.
3
Three rule sources run together. Community security packs cover the OWASP Top 10, a general security audit, secrets and Node.js. Onam-curated taint rules follow untrusted input to a dangerous sink in Python, JavaScript/TypeScript, Java, C#, Go and Ruby. Onam-reviewed pattern rules add breadth, each one triaged by hand — rules judged code-quality or accessibility are dropped, not shown.
4
Severity follows evidence. Taint and AST findings keep the severity their rule asserts. A pattern match is capped at medium, or low if its rule has not been reviewed, and is listed as a hotspot rather than a security issue. Several pattern rules firing on the same line are collapsed into one.
5
Secret detection runs in the same pass: the community secrets pack plus Onam's own patterns for cloud keys, private-key blocks, GitHub, Slack and Stripe tokens, Google credentials, hard-coded JWTs and generic secret assignments.
6
Each finding is stored with its file, line, rule, message, CWE, OWASP category, confidence and a short code snippet, and appears in the scan view, the project view and the platform-wide alerts list.

What do you actually get?

Specific outputs, measurable outcomes

Two lists, not one

Security issues you can act on now, Hotspots to review when you have time

Severity you can trust

pattern matches can never be rated high or critical

Taint rules where they matter most

Python, JavaScript/TypeScript, Java, C#, Go and Ruby

CWE and OWASP mapping

on every finding where the rule records them

Secrets in the same scan

cloud keys, private keys, SaaS tokens and hard-coded credentials

Less noise by design

vendored code, build output and minified files are not scanned

Rule guidance per finding

what the issue is, why it matters and a safe example

An AI fix prompt per finding

copy it into the assistant your team already uses

Fix branches on request

AI Code Fix rewrites flagged files onto a separate branch

The flow, in one picture

How Static Analysis (SAST) fits together

Three rule sources — community security packs, curated taint rules and reviewed pattern rules — produce two lists: security issues and hotspots to review — Three rule sources, two kinds of result. Only rules that can show a flaw produce a security issue.

Illustrative layout of a code scan result: summary tiles, a security findings table and a finding detail with a copyable AI fix prompt — Illustrative — a stylised view of a scan result, not a screenshot. Names and findings are invented.

Read the docs All of Code Security

FAQ

Questions we get a lot

Python, JavaScript, TypeScript, Java, C#, Go, C, C++ and Ruby. Python, JavaScript/TypeScript, Java, C#, Go and Ruby have Onam-curated taint rules in addition to community and pattern rules. C and C++ are covered by community and pattern rules only, so more of their results land in the hotspot list. Other languages, such as PHP, Kotlin, Rust, Swift and Scala, are not analysed today.

Ready to see it live

Ready to see Static Analysis (SAST) on your code?

Give us a repository and we will scan it with you, then go through the security issues and the hotspots together.

Book a live demo →See pricing

Related capabilities

Onam Code Security Dependencies and SBOM (SCA)Dynamic testing (DAST)Onam AI Code Fix SAST docs