Code Scanner Capabilities
Cyscale Code Security combines repository security assessments with Cyscale scan findings and the cloud security graph. The goal is to show application security issues in the same context as running containers, Kubernetes workloads, cloud functions, virtual machines, identities, network exposure, vulnerabilities, and compliance controls.
Cyscale supports code scanning for repositories hosted in GitHub, GitLab.com, and self-hosted GitLab instances. Connect the provider, choose which repositories or projects Cyscale can access, then start scans from a repository’s details in Code Security or Inventory. See the setup guides for GitHub and GitLab.
What Cyscale Checks
Cyscale Code Security can bring together provider findings and Cyscale scan results. The Cyscale repository scan currently checks:
- Dependencies and packages: inventories packages and identifies known dependency vulnerabilities.
- Infrastructure as code: checks supported configuration files for misconfiguration.
- Secrets: detects likely secrets in repository files. Secret values are redacted from the source context displayed with findings.
GitHub or GitLab may also provide their own security findings, depending on provider configuration and the access granted to the connector. Those provider findings are distinct from the checks performed by a Cyscale repository scan. Other issue types shown in Code Security may come from those provider integrations or other available evidence.
How Cyscale Discovers Code Risk
After a GitHub or GitLab connector is configured, Cyscale first imports available repository and security context for the connected projects. For GitHub, this can include repository security assessments such as dependency alerts, code scanning alerts, and secret scanning alerts where they are available. For GitLab.com and self-hosted GitLab, Cyscale can use the configured GitLab access to discover selected groups, projects, branches, and security evidence exposed by that instance.
When you start a repository scan, Cyscale uses the access configured for the connected provider to inspect the selected repository. It builds package inventory and checks dependencies, repository files for exposed secrets, and supported infrastructure-as-code files. The scan runs against the repository’s available default branch. Cyscale presents normalized findings with repository, file, line, package, severity, evidence, and remediation context where available.
You do not need to install or configure scanner tools yourself. Secret values are redacted from source context shown with findings. Treat repository contents as sensitive and limit connector access to the projects that should be assessed.
Supported Repository Providers
| Provider | Supported coverage |
|---|---|
| GitHub | GitHub organizations, repositories, provider security alerts, and scanner runs |
| GitLab.com | GitLab SaaS groups and projects, repository discovery, and scanner runs |
| Self-hosted GitLab | Private GitLab instances, reachable projects, repository discovery, and scanner runs |
Runtime and Cloud Correlation
Code findings are most useful when they are connected to what is actually running. Cyscale correlates repositories with runtime assets such as:
- container images
- Kubernetes workloads
- cloud containers
- cloud functions
- virtual machines and disk-backed evidence, where available
Cyscale can infer a repository-to-runtime relationship from names, image metadata, registries, and workload context. Users can also set or change the association manually. Manual links take priority over automatic matches.
Once a repository is linked to runtime, Cyscale can:
- show which code findings affect a running asset
- deduplicate overlapping code and runtime findings
- prioritize defects by cloud exposure, identity access, and workload context
- preserve secret locations in source or runtime evidence
- connect application risk to infrastructure and compliance controls
Associated Controls
The following control areas are represented in the Code Security module:
| Control area | What it answers |
|---|---|
| OSS Dependency | Which packages and versions introduce known vulnerabilities? |
| IaC | Which infrastructure files would deploy unsafe cloud or Kubernetes settings? |
| Secrets | Which repository files contain likely secrets? |
Operational Notes
- Code Security is an account module. If it is not enabled, repository-to-runtime linking does not affect standard cloud, container, or Kubernetes inventory.
- The GitHub App installation must include the repository access needed for the selected repositories.
- GitLab.com and self-hosted GitLab connectors must include access to the groups, projects, and branches you want Cyscale to inspect.
- The connected provider must allow Cyscale to read repository contents for scans.
- Self-hosted GitLab instances must be reachable from the scanning workflow and use TLS settings trusted by that workflow.
- Runtime correlation depends on repository naming, image metadata, workload names, and manual overrides.
Start and review a scan
- Connect GitHub or GitLab and select the repositories to include.
- Open a repository in Code Security or Inventory.
- Start a scan from the repository details and follow its status in Code Security.
- Review findings by severity and type, then open a finding for its file, line, affected package, and suggested remediation when available.
- Use runtime correlation to determine whether the affected repository or package is associated with a deployed workload.
Provider-native findings and Cyscale scan findings can appear together. A missing finding may mean the provider security feature is disabled, the connector cannot access that repository, or the selected scan has not completed.