Cefense uses a security model fine tuned for this task, driven by a proprietary pipeline built for efficient scans. This page is what that means from the outside: what goes in, what comes out, and what the guarantees are.
What goes in
- A commit. One specific commit on one branch, fetched through the provider API with the credential you granted.
- Source files. Everything that survives the exclusions described in Your first scan.
- Dependency manifests and lockfiles, for the dependency check.
- Infrastructure and configuration files, for the misconfiguration check.
What comes out
A set of findings, each one carrying a location, a severity, a confidence score, the code in question, and remediation guidance. Code findings also carry the traced data flow: where untrusted input enters, where it lands, every step between, and any guard that looked protective but does not defend that particular operation.
Where the finding is a class of vulnerability that has been written about publicly, it is also joined to that research, with the reason for the match. Those are the findings cf matched lists.
Read the evidence for each check
The report combines checks with different evidence. Model and source analysis can record verification of a candidate path. Deterministic checks can report a source pattern or an advisory for an installed package version, and code-quality checks report maintainability observations. Review the evidence label and recorded verification state rather than assuming every row is a reproduced exploit.
The same discipline applies to guards. A protection only counts against the operation it genuinely protects. Escaping a string for HTML on its way into a shell command is not a defence against command injection, and treating it as one would quietly hide a real finding. See Verification.
What is deliberately dropped
Incremental work
Analysis of a file is keyed by its content, so a file that has not changed since it was last analysed does not have to be analysed again. That is what makes scanning on every push practical rather than theoretical. It also means the second scan of a repository is usually much faster than the first.
How much fresh analysis a scan performs is also set by the repository's scan depth: default is the balanced everyday depth, and max keeps going until nothing new turns up.
What Cefense does not claim
- It is not exhaustive. No static analysis is. A clean scan means nothing was found, not that nothing is there.
- It does not execute anything, so it cannot confirm exploitability at runtime. Reachability is traced through the code, not proven against a running system.
- It reports on the commit it scanned. Code written since then has not been looked at.
Have a correction or need help?
Email the docs team