How scanning works
The scan lifecycle, what gets collected, and how access affects coverage.
The scan lifecycle
- Connect — for instances, CloudShield opens an SSH session with the credentials you provide for that single scan. For repositories, it clones over https.
- Collect — source code is copied into an isolated, per-scan workspace. For instances, installed packages are inventoried at the same time (pip, npm, gems, system packages, and more).
- Scan — the scanner ensemble runs against the local copy. Your instance does the SSH handshake and a file transfer — all analysis happens on CloudShield's worker, so there's no CPU or memory impact on your machine.
- Filter — raw results are merged across scanners, de-duplicated, and scored by the heuristic false-positive engine.
- Triage — findings stream into your dashboard, live.
The workspace is deleted when the scan completes. Most scans return in well under 30 minutes.
Coverage and access
CloudShield scans the common code locations by default: /home, /opt, /srv, and
/var/www (or the paths you specify). The scanner can only read what your SSH user
can read.
- With passwordless sudo, CloudShield scans the full instance, including code owned
by other users and
/root. - Without it, unreadable locations are skipped — and the scan says so, right on the timeline, so you always know what coverage you actually got.
An IP address and an SSH key alone are not always enough for a complete scan. If your code lives in directories your scan user can't read, grant that user read access (or passwordless sudo) and re-run.
Repository scans
Repository targets are cloned with full history over https and analyzed with the same code scanners. Package CVE scanning doesn't apply (there's no installed-package inventory in a repository). Private repositories take a read-only access token, which is handled with the same one-time-use lifecycle as SSH credentials.