Skip to main content

​
Overview

Scans are the security analyses Cysmiq runs against your repositories. Scans start automatically when repositories are onboarded and run on push events to branches and tags. Users with permission to start scans can also scan an unscanned branch head or retry an eligible failed scan. For the table view of scan runs, see Scan list view.

​
Scan types

Cysmiq uses scan types that reflect why a scan ran and which ref it covers:
  • Full scan: Analyzes the entire repository. Runs when a repository is first onboarded or after a reset. It can include secrets, code vulnerabilities, and dependency analysis based on the repository’s enabled scan jobs. Git history scanning runs as a separate scan when enabled.
  • Incremental scan: Analyzes only the changes since the last scan. Faster than full scans while focusing on recent changes.
  • Branch scan: Analyzes a branch ref when Cysmiq needs branch-specific results.
  • Tag scan: Analyzes a tag ref when a VCS tag event triggers scanning.

​
What scans detect

Depending on the repository’s enabled scan jobs, a scan can analyze your code for:
  • Secrets: Leaked credentials, API keys, and tokens
  • Code vulnerabilities: Security issues in your source code
  • Dependencies: Vulnerable packages in your dependency tree
See Secrets, Code, and Dependencies for details on each category.

​
Repository scan jobs

Availability depends on your Cysmiq plan.
Repository settings can control whether Cysmiq runs dependency, secret, code, Secret History, and call-chain analysis. Call-chain analysis can also be limited to selected branches. See Repository scan jobs for the available controls and monorepo behavior.

​
Scan triggers

Metadata-only pull request or merge request edits do not start a new assessment when the compared source and target commits are unchanged. Changes to the compared commits continue to trigger the applicable scan and assessment workflow. Manual scan actions are available from repository branch rows and, for eligible failed scans, from the Scans view. See Repositories and Scan list view.

​
VCS status updates

When a push event is associated with a pull request, Cysmiq can publish scan status updates and pull request decoration to connected VCS providers. See VCS status updates for supported providers, settings, and inheritance behavior.

​
Scan status

Cysmiq tracks scan lifecycle status separately from VCS or pull request result. Lifecycle status describes where the scan is in the analysis pipeline. Result describes the provider check or current pull request evaluation outcome when Cysmiq has that data. Common lifecycle states include:
  • Queued: Waiting to start
  • In Progress: Actively scanning
  • Processing: Post-scan processing
  • Finalizing: Wrapping up results
  • Completed: Finished successfully
  • Completed with Errors: Finished with non-blocking failures
  • Failed: Encountered an error
  • Skipped: Not run due to conditions or limits
  • Aborted: Stopped before completion
  • Cancelled - No SWUs: Stopped because Shift Work Units balance was insufficient
  • Recovering: Retrying after failures
Result labels can come from a pull request evaluation, a provider check, or the scan status when no PR evaluation or provider check outcome is available. Examples include PR passed, PR failed, PR unavailable, PR neutral, PR pending, Check passed, Check failed, Check neutral, Check pending, Scan passed, Scan failed, Scan neutral, and Scan pending.