The scanners
DL Sentinel has six scanners. All of them run by default. This page says what each one looks at, what it reports and where it stops.
To run only some scanners, list their ids:
sentinel scan . --scanners secrets,dependenciesTo see every rule, with its id, severity and any CWE and OWASP mapping:
sentinel rules
sentinel rules --scanners infraSecrets
Id: secrets · Rules: 22, ids starting with S
Finds credential-like values committed to files: API keys, tokens, passwords and high-entropy strings. It reads every text file that is not excluded, including dotfiles such as .env.
The matched value is replaced with [REDACTED] before the finding is created, so a report never contains the secret itself.
Settings in sentinel.yml under scanners.secrets: allowlist (exact strings or rule ids to ignore) and ignorePaths (extra paths to skip).
Dependencies
Id: dependencies · Rules: 3, D001 to D003
Reads dependency files for npm, pip, Go and Cargo: package.json, package-lock.json, yarn.lock, pnpm-lock.yaml, requirements.txt, requirements-*.txt, go.mod, Cargo.toml and Cargo.lock.
| Rule | Reports |
|---|---|
D001 | A dependency with a known vulnerability |
D002 | The vulnerability check was skipped (severity info) |
D003 | A manifest without a lockfile |
The scanner needs vulnerability data to report D001. Choose where it comes from with scanners.dependencies.dataSource:
| Value | What happens |
|---|---|
none | The default. No data is consulted, and the scanner reports D002 instead of guessing |
file | Reads a local advisory file named in advisoryDbPath |
osv | Asks the public OSV vulnerability database over the internet |
scanners:
dependencies:
dataSource: osvGood to know
osv is the only setting that makes a scan use the network. It sends the names and versions of your dependencies to the OSV service, not your source code.
Source code
Id: source · Rules: 10, ids starting with C
Looks for insecure patterns in .js, .jsx, .ts, .tsx, .mjs, .cjs, .py, .go, .rb, .php and .java files: command injection, eval and dynamic code, SQL built from strings, insecure deserialization, path traversal, weak password hashing, insecure randomness, disabled TLS verification, permissive CORS and world-writable file modes.
Rules are line-based and tuned to avoid false alarms, so they will miss some cases. Coverage differs between languages.
Infrastructure
Id: infra · Rules: 26, ids starting with I
Checks container and infrastructure files:
| Files | Rules |
|---|---|
Dockerfile, Dockerfile.*, *.dockerfile | I001 to I006 |
Docker Compose files (docker-compose.yml, compose.yml and variants) | I010 to I016 |
| Kubernetes manifests (YAML) | I020 to I028 |
Terraform (.tf) | I030 to I033 |
Findings are filed under the category docker or infrastructure. Other YAML files are opened and skipped unless they are Compose files or Kubernetes manifests. The Terraform reader is basic: it does not evaluate expressions, heredocs or dynamic blocks.
The same file parsing powers sentinel graph, which draws your deployment as a diagram. See the command reference.
API
Id: api · Rules: 10, A001 to A010
Analyses OpenAPI 3.x and Swagger 2.0 documents and Postman collections. It finds files named openapi.*, swagger.*, *.openapi.*, api-spec*, *postman_collection*.json, and other YAML or JSON files that identify themselves as API definitions.
It reports missing or weak authentication, API keys in query strings, plain HTTP servers, Basic auth, state-changing operations without authentication, sensitive response fields, missing rate-limit signals, deprecated auth flows, unconstrained inputs and secrets stored in Postman collections.
Every API finding has a qualifier (confirmed, likely or potential), because a definition file alone often cannot show whether the live service is affected.
Smart contract
Id: smart-contract · Rules: 17, ids starting with SC
Analyses Solidity (.sol) files for risks such as reentrancy, tx.origin authentication, unchecked low-level calls, unsafe delegatecall, unprotected selfdestruct, initializers and mint functions, pre-0.8 arithmetic, floating or outdated pragmas, weak randomness, unguarded owner setters, unprotected proxy upgrades and unchecked ERC20 transfer results.
It builds a model of each contract, so it can judge a modifier by what its body does, not by its name. Limits, all chosen to report less rather than guess:
- It reads one file at a time. A base contract or modifier from an
importcannot be read, and an unreadable modifier is assumed to protect the function. - Overloaded functions are matched by name only.
- Effects across functions are followed for at most three calls.
WARNING
No finding does not mean a contract is safe. Get a professional audit before you deploy a contract that holds funds.
Plugins
Other people can write extra scanners as plugins. A plugin is code that runs with your permissions, so load only plugins you have read and trust. Plugins are loaded only with --plugin on the command line, never from sentinel.yml, so a scanned repository cannot make DL Sentinel run its code.
sentinel plugins --plugin ./plugins/acme/dist/index.js # review what it adds, without scanning
sentinel scan . --plugin ./plugins/acme/dist/index.js