Code, dependencies and secrets

sentrasec scan against a path runs three scanners together and reports them as one result set. It needs no credentials and sends no code anywhere — useful before you have registered an app, and the fastest way to see what the engine finds.

$ sentrasec scan .

What a run looks like

The tail of every run summarises per scanner, so you can see at a glance which one produced what:

3. [MEDIUM] CMDI003 v1.0.0 @ app.py:4   category:   Injection   confidence: Medium   kg_node:    vuln:command-injection (Vulnerability)   snippet:    subprocesssentrasec: findings crit=1 high=1 med=1 low=0 info=0 fail_on=none exit=0scan 7a09b6ca · path=. · findings=3 · secrets=1 sast=2 sca=0 exit=0

Static analysis

The SAST engine is taint-tracking rather than pattern-matching: it follows untrusted input from a source to a dangerous sink across assignments and function boundaries, and joins branches on the control-flow graph so a value tainted on only one path is still reported. That is why findings carry a specific line and a snippet rather than a whole file.

37 rule files ship embedded in the binary, covering injection families — command injection, SQL injection, XSS, SSRF, path traversal, unsafe deserialisation — plus hardcoded-credential patterns. Each finding carries a rule_id, a CWE and OWASP classification, and a knowledge-graph node id.

Secret detection

Credentials are matched by provider-specific shape, not by entropy alone, so a Stripe key is reported as a Stripe key. Matched values are redacted in output — the snippet shows enough to locate the string without reprinting the secret into your terminal scrollback or a CI log.

Dependencies

Lockfiles are parsed into a dependency inventory — npm, pip, Composer and the other ecosystems the lockfile reader supports — and AI/LLM packages are classified as their own category, which is what the AI tooling surface builds on.

CVE matching is currently disabled. Turning a dependency inventory into vulnerability findings requires the graph corpus, and that enrichment path is off pending SE-KG-01. A run today reports sca=0 even against a known-vulnerable pinned version. Dependency inventory is accurate; treat the absence of SCA findings as “not checked”, never as “not vulnerable”.

In CI

--fail-on sets exit code 3 at or above the severity you name. SARIF output publishes into GitHub code scanning as pull-request annotations.

$ sentrasec scan . --fail-on high$ sentrasec scan . --format sarif > results.sarif

Through the API

The local run prints and exits. To record results against a registered app so they appear in the console with history and lifecycle tracking, run the same scanners through the API — see Run a scan.

$ sentrasec scan --kind all --app-id app_...