What it covers
A code scan runs a set of independent analyzers over a checkout and merges their findings into one report. Each analyzer answers a narrow question; none of them talks to an AI model. The multi-model panel is a separate, later stage used on smart-contract verifications, not here.
| Area | What runs |
|---|---|
| Static analysis | Semgrep across your languages, filtered so a rule for one language does not fire on another's files. |
| Taint tracking (JS/TS) | An inter-procedural analysis over the real TypeScript AST that reports the step-by-step path from an untrusted input to a dangerous operation, following assignments, template literals, calls across files, and values returned out of a function. |
| Taint tracking (Python, Go, Java, PHP, Ruby, C, C++) | The same question (is there a flow from an untrusted source to a sink) is answered through Semgrep's inter-procedural taint mode. It confirms a flow exists but, in this Semgrep version, cannot report the intermediate steps; every finding here says so explicitly. |
| Dependency vulnerabilities | npm audit and cargo audit against your manifests, with a persistent inventory tracked across scans rather than thrown away when the scan ends. |
| Supply-chain posture | Loose semver ranges in package.json (the door a compromised-maintainer attack walks through), plus a lexical read of install/postinstall command lines. |
| Install-hook behaviour | Goes further than the command line: resolves a hook to the file it actually runs, follows that package's own require/import graph, and judges the combination of what it does: network access, reading credential-shaped environment variables, executing dynamically built code, writing outside its own directory, obfuscation, and sandbox evasion. A single signal (a native module using child_process, for instance) is not by itself a finding; the combinations are. |
| Secrets | Gitleaks over the checkout. A run that is interrupted before finishing is reported as an incomplete run, never folded into a clean result. |
| Leaked credentials in transcripts and logs | A separate, context-based detector for values assigned to a secret-shaped variable name or carrying a provider's key prefix, built to avoid mistaking the hex-heavy content of a Web3 transcript (addresses, transaction hashes) for entropy-based secrets. |
| License compliance | Flags strong and weak copyleft licenses, and dependencies with a missing or unrecognized license field. Does not compute a transitive legal-impact graph. |
| Provenance & signing | Where a package publishes a signed Sigstore attestation, its signature, its binding to the exact tarball you would install, and the chain of custody up to the trust root are verified cryptographically. Most dependencies do not publish one yet; where none exists, nothing is asserted about that package's provenance. |
| Reproducible builds | Checks, for npm packages only, that the published tarball matches the lockfile's recorded integrity hash and that every file on disk under node_modules matches the file of the same name in that tarball. This is not a from-source rebuild; see below. |
| SBOM | A CycloneDX 1.6 bill of materials generated from the tracked dependency inventory, with an explicit completeness flag rather than a silent assumption of completeness. |
| Typosquatting | Your dependency names checked against a curated list of high-value packages frequently impersonated by attackers. |
| Binary analysis | ELF executables and archives found in the checkout: RELRO, NX, PIE, stack canary, FORTIFY, RPATH, the dynamic import table, and embedded credentials. No decompilation and no disassembly-level reasoning; see below. |
| Framework surface (Next.js App Router) | Seven rules reasoned per exported handler: credentials inlined into the browser bundle via NEXT_PUBLIC_*, unguarded Server Actions, middleware bypass, risky next.config settings, server-only environment variables read from client components, missing CSRF protection on cookie-authenticated writes, and unchecked uploads. |
| Custom rule packs | Curated, opt-in packs of additional rules for specific stacks, installed and removed as a unit. |
External tools are detected, not assumed
Semgrep, Gitleaks, and the other external binaries this scan can call are probed the same way they are invoked before every run. A tool that is not installed is never silently skipped into a clean-looking report: the family it would have covered is marked as not run, and a scan that had nothing to show for itself is reported with no score at all rather than a passing grade.
What it stops short of
- The JS/TS taint engine is not path-sensitive: an early-return guard does not clean a value in its model, so a reported flow may be unreachable in practice. It is also not alias-aware beyond direct assignment and not type-directed, and it caps how deep it follows recursive calls.
- For the seven other supported languages, taint tracking confirms a flow exists but cannot show the steps between source and sink in this Semgrep version.
- Binary analysis reads compilation posture, imports, and strings only. It never decompiles, never reasons about control or data flow inside the binary, and does not cover Android, iOS, or firmware images.
- Reproducible-build verification is not a from-source rebuild: it compares published, already-built artifacts to what is on disk. It covers npm only, and it never validates prebuilt native binaries (such as compiled
.nodefiles) against any source. - Provenance verification is only as strong as what a package publishes. Most dependencies do not yet publish a signed attestation; where none exists, this scan reports that fact rather than a verdict.
- None of this proves a finding is exploitable in a running system. That question belongs to a dynamic scan or a professional review, not to static analysis.
- A local absolute filesystem path can only be submitted by an admin account, or by anyone when the platform is running without authentication enforced. Everyone else submits a repository URL or an upload.
- Only an
https://git URL on a public host can be scanned by URL; a private host is refused. A private repository has to be submitted as an upload instead.
How to run it
- 1
Open the Code tab
Go to /scans and choose the Code tab. - 2
Choose how you're submitting the source
Anhttps://git repository URL, an uploaded.tar.gzor.ziparchive, or, for admin accounts only, a local file or folder path. - 3
Start the scan
A repository is cloned into a throwaway directory; an upload is extracted under strict path-traversal and size checks. Every enabled analyzer then runs against that checkout. - 4
The checkout is erased
Whether the scan succeeds or fails, the cloned or extracted source is removed once analysis finishes. What remains in your account is the findings, not the code.
Once the scan completes, see Reading a report for how severity, confidence, and status are assigned to each finding.
Read before relying on any result
Sentinelleai is an automated security monitoring platform. Nothing it produces is an audit, a penetration test, a compliance opinion, or a guarantee that a system is secure. "No findings" means the tools that ran found nothing, never that nothing is there; anything a tool could not check is reported as unknown, not as clean. For decisions that carry real money or real liability, engage qualified professionals and treat Sentinelleai's output as their starting material.