Understand your current inventory

You do not need completed Policy Groups or image mappings to gain useful insight from BIMP. You can start by building an inventory, understanding the risks and inconsistencies it reveals, and using that evidence to define the policy your organization needs.

Until you publish policy, discovered images will appear as Unmanaged.

At a high level, the process is:

1. connect your code providers;
2. select repositories and branches;
3. scan for base images;
4. confirm inventory coverage;
5. download and analyze the findings; and
6. use the findings to define your base-image strategy.

Build your inventory

Complete the discovery steps in onboarding:

1. Create your BIMP organization.
2. Create the initial team that owns the repositories.
3. Set a practical routine for that team.
4. Connect GitHub or GitLab.
5. Select the repositories and branches you want BIMP to scan.
6. Wait for the scan-results panel.

When you reach the policy-mapping step, leave onboarding without creating a mapping. You can return to policy configuration after you have analyzed the inventory.

For the broadest useful view:

• use one BIMP organization for the assessment;
• connect every relevant GitHub organization and GitLab group; and
• select every repository and branch within your assessment scope.

Scanning does not open pull or merge requests. You can stop tracking redundant repositories or branches later.

Confirm your coverage

Before analyzing the inventory, confirm that BIMP successfully scanned the source you expected it to inspect:

• check that every selected repository and branch completed its latest scan;
• check Unmanagable discovered images for references that contain variables BIMP could not resolve; and
• identify untracked branches, unsupported artifacts, or inaccessible repositories that remain outside the inventory.

BIMP scans selected branch content. Repository inventory describes image references in source control; it does not infer which images are currently deployed at runtime.

What to do if a scan is empty or fails

An empty successful scan means BIMP completed the inspection but found no image references it could add to inventory. If you expected results:

1. Open Repositories, find the repository, and confirm that BIMP is tracking the intended branch.
2. Open the branch in GitHub or GitLab and confirm that it contains files with image references.
3. Open Reports → Unmanagable discovered images and check for references that depend on unresolved variables.
4. After correcting the branch or source files, open Settings → Integrations → Code providers and choose Rescan for the connection.

A failed scan means BIMP could not complete the inspection. Open Repositories, find the repository and branch, and review the failure detail. Then:

1. Open Settings → Integrations → Code providers and confirm that the connection is active. For GitLab, use Check token.
2. Open the repository in GitHub or GitLab and confirm that the repository and branch still exist and remain accessible to the BIMP connection.
3. Check the affected JSON or YAML source file in GitHub or GitLab for syntax errors.
4. Return to Settings → Integrations → Code providers and choose Rescan.

If the scan continues to fail, return to Repositories and record the repository, branch, and failure message when contacting BIMP support. Do not treat a failed scan as evidence that the repository contains no base images.

Review your inventory reports

Open Reports and review the inventory from several perspectives:

• Organization base images detected: See which normalized images BIMP discovered, which repositories and branches use them, and when they were last discovered.
• Unmanaged images: Find images that do not have an applicable published mapping. Most or all images may appear here before you configure policy.
• Unmanagable discovered images: Find image expressions BIMP cannot resolve because their values depend on variables supplied outside the repository.
• Digest inventory: Compare tag-only references with references pinned to an image digest.

Start with Organization base images detected to understand the complete image population and repository reach. Use the other reports to identify policy gaps, incomplete discovery, and inconsistent reference practices.

Download a working inventory

Open Unmanaged images and choose Download CSV. The export contains:

• fromImage;
• toImage;
• platformScope; and
• reason.

The initial Target image matches the From image. This is a neutral self-mapping that brings the reference under management; it is not a BIMP recommendation to retain that image.

Use the CSV as a working inventory. Add your research and decisions outside BIMP, then update its targets before importing it as an internal mapping file. The same columns are accepted by BIMP’s mapping import.

Analyze your findings

Use the inventory to answer questions that will shape your policy:

• Which providers and catalogs are in use? Look for duplicate image families, unofficial publishers, and inconsistent provider choices.
• Which registries do teams pull from? Identify public, private, legacy, and team-specific registry locations.
• Which images have the greatest reach? Find images used by many repositories or by critical services.
• Are teams using consistent versions? Compare major versions, old release lines, floating tags, and variants.
• Which references need lifecycle review? Find images approaching or beyond provider support and images without a clear maintenance source.
• How are references pinned? Compare mutable tag-only references with digest-pinned references.
• Where are the blind spots? Review failed scans, unresolved variables, unsupported artifacts, and untracked branches.
• Who owns each affected repository? Identify missing team assignments and unclear accountability for remediation.

An image name or tag can guide further research, but it does not prove that an image contains an exploitable vulnerability. Validate findings against trusted provider lifecycle information, security advisories, and your organization’s approved vulnerability-scanning process.

Define your base-image strategy

Use the evidence from your inventory to agree:

• which image providers and catalogs are approved;
• which public and private registries are approved;
• whether approved images must be mirrored into a private registry;
• when teams may use off-the-shelf images and when custom images are required;
• the routine cadence for normal remediation;
• the accountable owners and escalation path for each repository; and
• which image families or repositories should be addressed first.

These decisions give you a clearer basis for organizing Policy Groups, teams, repository scope, and mappings within BIMP.

Turn your inventory into policy

When the organization is ready to move from discovery to governance:

1. organize Policy Groups around the standards and legitimate variations the inventory revealed;
2. assign each Policy Group to its intended repository and branch scope;
3. convert the working inventory into approved image mappings;
4. review the impact before publishing; and
5. roll out policy and remediation in controlled stages.

See Policy Management to create and publish mappings. Use Migrations when consolidating providers or registries, and Automate Policy Updates when your image-ingestion pipeline is ready to maintain future mappings.

Real-world inventories often contain anomalies, competing standards, and repository-specific requirements. BIMP lets you keep that complete inventory visible while introducing policy in stages.