Git repository discovery

Connect a Git repository in the application, validate access, then run discovery before scheduling scans. A dry run renders the configured deployment inputs and discovers images only; it never queues scans.

Discovery modes

• Registry image references (recommended) searches repository text and configuration for concrete references under one selected configured registry or custom host/path. It discovers files automatically; no CI, manifest, or other path list is required.
• Auto detects unreferenced Kustomize roots and falls back to Kubernetes workload manifests.
• Kustomize entrypoints renders only operator-selected repository paths.
• Plain Kubernetes manifests extracts images from containers, initContainers, and ephemeralContainers.
• GitLab CI configuration extracts global, default, and job-level image and services declarations. Add one or more relative CI config paths, or leave the paths empty to use .gitlab-ci.yml or .gitlab-ci.yaml at the repository root.

After a dry run, review discovered images, select the ones that should be tracked, then create scans. Excluded images remain visible in the review so their deployment context is retained without scheduling future scans.

Ignored discovery paths

Configure Ignored discovery paths on a Git repository when automatic discovery should skip archived, generated, or deprecated content. Enter one glob per line. Patterns are matched against repository-relative paths, and matching files and directories are skipped before JustScan walks or renders them. For example:

.archive/**
**/deprecated/**

.archive/** skips the .archive directory at the repository root and everything below it. **/deprecated/** skips every deprecated directory at any depth. These patterns apply to automatic Kustomize, manifest, GitLab CI, and registry-reference discovery.

Ignored paths are also enforced for configured Kustomize entrypoints. An explicitly selected entrypoint inside an ignored path is rejected rather than silently skipped. When Auto discovery finds a broken Kustomize root, JustScan reports that root while continuing to discover valid roots elsewhere in the repository.

Registry image-reference discovery

Choose Registry image references when image declarations are spread across deployment files, scripts, and other repository configuration. Select a configured registry from the workspace, or choose Custom registry host or path and enter a prefix such as registry.example.com/team. JustScan searches automatically and still shows the source file and line for each result so the dry-run review is auditable.

Only concrete, fully qualified references below the selected prefix are returned. Include an explicit tag, such as registry.example.com/team/api:1.2.3 or :latest, or a digest, such as registry.example.com/team/api@sha256:.... Unqualified or tagless names, wildcard references, URLs, and unresolved variables or templates are skipped. Prefix matching respects host and repository-path boundaries, so registry.example.com/team does not match registry.example.com/team-other.

Discovery is bounded and intended for source/configuration files. JustScan skips binary or invalid text files, symlinks, .git, common dependency/build/generated directories, files larger than 5 MiB, and stops reading after 64 MiB of text for one discovery. Duplicate references are combined while retaining their source locations.

Configured registry or custom prefix

• A configured registry is selected from the registries available in the repository's workspace. Its configured scan provider and encrypted credentials are used for matching images, and the selected entry is applied to discovered images unless a per-image override replaces it.
• A custom registry prefix is kept as written in each image reference and has no JustScan credential attached. Scans therefore run anonymously. For a private custom host, configure a registry entry and use it as the discovery source, or assign a configured registry as a per-image override after the dry run.

Changing the discovery source causes the next run to evaluate the images with the new registry choice. If a selected configured registry is removed or is no longer available to the workspace, discovery reports an error rather than silently scanning anonymously.

GitLab CI discovery

Use GitLab CI configuration when you want schema-aware discovery limited to CI declarations. Paths are optional: add one or more relative files, directories, or patterns when the repository keeps CI configuration outside the root, or leave the field empty to inspect .gitlab-ci.yml and .gitlab-ci.yaml at the repository root. This mode is separate from the path-free Registry image references mode.

GitLab CI discovery accepts scalar declarations and mappings with a name field. It follows local include files without making network requests for remote or project includes, and resolves variables declared statically in the same CI file. References that still contain runtime variables such as $CI_COMMIT_SHA are skipped because they are not concrete scan targets.

variables:
  REGISTRY: registry.example.com

default:
  image: alpine:3.20

build:
  image:
    name: ${REGISTRY}/team/builder:2.0
  services:
    - docker:27-dind
    - name: ${REGISTRY}/team/cache:3.0

JustScan records the CI file, job, and declaration path for every result. Script commands and unrelated YAML keys are not treated as image declarations.

For a repository that combines GitLab CI with deployment inputs, use multiple sources in .justscan.yaml:

version: 1
discovery:
  sources:
    - type: gitlab_ci
      paths:
        - .gitlab-ci.yml
        - ci/release.yml
    - type: kustomize
      root: deploy

Registry matching outside registry-reference discovery

For images discovered by Auto, Kustomize, manifests, GitLab CI, or Helm, JustScan can compare the image host with registry entries available to the repository's workspace. A matching configured registry supplies its scan provider and credentials automatically. A saved per-image registry override takes precedence over automatic matching. Registry image-reference discovery uses the explicitly selected configured registry or custom prefix described above.

A fully qualified image from an unconfigured custom registry is kept exactly as written and can be scanned anonymously. No registry record or credential is created implicitly.

Per-image registry and credential

If different discovered images need different registry access, expand the image and choose Image registry / credential. The selection is stored for that exact image reference and is used by manual and scheduled repository scans. Choose Automatic matching to return to host-based matching and the default behavior.

Registry entries include their credentials, so create a separate entry in Workspace setup → Registries when two images use the same registry URL with different tokens. Give the entries distinct names, then assign the appropriate entry to each discovered image. The selected registry must be available in the repository's workspace.

Repository-owned configuration

Place a .justscan.yaml file at the repository root when one repository mixes Kustomize, direct Helm charts, and selected manifest paths. It takes precedence over the connector's discovery mode.

version: 1
discovery:
  sources:
    - type: kustomize
      root: envs
    - type: manifests
      paths:
        - manifests
    - type: gitlab_ci
      paths:
        - .gitlab-ci.yml
        - ci/release.yml
    - type: helm
      chart: charts/standalone-service
      releaseName: standalone-service
      values:
        - envs/demo/values.yaml

• A kustomize source accepts a discovery root or explicit paths to kustomization.yaml files.
• A manifests source requires paths to plain Kubernetes YAML files or directories.
• A gitlab_ci source accepts optional CI config paths, directories, or patterns. With no paths, it uses the conventional root GitLab CI filename.
• A helm source requires a chart directory in the same repository. JustScan resolves declared chart dependencies in an isolated temporary directory before rendering; it never writes them back to Git.

Managed Helm sources

Use Managed Helm sources on a Git repository page when the chart and its deployment values do not live together. These source definitions are stored in JustScan rather than .justscan.yaml, so connector IDs and credentials never need to be committed to Git.

For each source, choose one of these chart locations:

• This repository: a chart path in the deployment repository.
• Registered Git repository: another JustScan Git connector in the same workspace.
• Direct Git URL: an HTTPS Git URL. Optional credentials are encrypted at rest and are never returned by the API.

The chart path is always relative to the selected chart source. Values files are always relative to the deployment repository and are applied in the listed order. This lets one shared application chart be rendered with environment-specific values from repositories such as envs/prod/app/values.yaml.

Managed sources run alongside repository-owned .justscan.yaml sources. Editing a managed source does not modify the checked-out repository.

External chart example

Suppose the deployment repository contains an environment values file while the chart is elsewhere:

deployment repository: envs/ki/dev/litellm/values.yaml
chart repository:      apps/litellm

Create a managed Helm source with:

Helm dependencies and private registries

Before rendering a managed or repository-owned Helm chart, JustScan runs helm dependency build in an isolated working directory. Chart.lock is honored when present. OCI and HTTP dependencies from Chart.yaml are downloaded for that render only; no dependency archive, lock file, or credential is written back to Git.

For private OCI or HTTP dependencies, create a Helm registry credential with pull permission. It is separate from a JustScan image registry, so it never appears in image scanning flows. Artifactory OCI access tokens use the Artifactory username and access token together.

In a managed source, Helm dependency credentials has two modes:

• Automatic matching: JustScan selects an accessible Helm credential matching protocol, host, and repository path. Equal matches require an explicit choice.
• A selected credential: choose a specific Helm credential to make credential selection deterministic. It takes precedence for matching dependencies. This is useful when one Artifactory host has separate credentials or permissions for different Helm repositories.

Only Helm credentials in the deployment repository's workspace can be selected. For organization-owned repositories, share the credential with that organization first. See Helm registry credentials.

Dependency authentication failures

• 401 Unauthorized: the registry did not accept the configured credential. Check the registry username and token, and use the registry URL host used by oci:// in Chart.yaml.
• 403 Forbidden: authentication succeeded, but the credential lacks pull access to the dependency repository or chart version. Grant read permission to the chart repository, or select a different registry credential on the managed source.
• Selected registry does not match a dependency host: select a registry with the same host as the oci:// or HTTP dependency URL, or use automatic matching.