BIMP is a policy and remediation control plane for container base images. It connects the image a repository uses today to the image your organization has approved, then carries that decision into a reviewable pull or merge request.
Security teams keep control of policy and temporary risk decisions. Development teams keep their normal Git, review, CI, and deployment controls. BIMP handles the repetitive middle work, which is a respectable place for software to earn its keep.
The governance loop
Section titled “The governance loop”BIMP follows one operating loop:
- Observe base-image references in connected repositories.
- Decide which published policy applies and what it permits.
- Explain the current state and any approved replacement.
- Remediate through a pull or merge request.
- Handle Exceptions as explicit, time-bound decisions.
- Re-evaluate after code, policy, or Exception state changes.
- Prove which decision and action produced the outcome.
The policy engine sits at the centre of this loop. Scans, repository ownership, published mappings, routines, remediation state, and Exceptions all contribute context to the result you see.
What BIMP observes
Section titled “What BIMP observes”BIMP scans supported repository files for container base-image references:
- Dockerfiles;
- Compose files;
- devcontainer definitions; and
- conventional Helm values image declarations anchored to a chart.
The resulting inventory is rebuildable. BIMP evaluates each observed reference against the published policy assigned to that repository and branch context.
What a policy decision contains
Section titled “What a policy decision contains”A policy mapping connects a source image to an approved target image. The decision can also retain a reason and an OCI platform scope. Published policy is versioned so later remediation and audit records can point to the policy that was live when the decision was made.
Typical operational states include:
| State | Meaning |
|---|---|
| Unmanaged | No published mapping covers the observed image. |
| Compliant | The observed image is already at its approved destination. |
| Outdated | Published policy requires a different approved image. |
| Review | A related Exception decision is waiting for review. |
| Exception | An approved, time-bound Exception currently applies. |
| Remediation active | BIMP is tracking work to apply the approved change. |
State labels may be accompanied by repository, routine, or remediation detail. Do not use colour alone when interpreting them; the text is the record.
Who uses BIMP
Section titled “Who uses BIMP”Security and platform teams
Section titled “Security and platform teams”Use the web application to connect providers, select repositories, assign ownership, publish policy, review impact, handle Snooze Requests, and monitor remediation.
Development teams
Section titled “Development teams”Developers mainly stay in GitHub, GitLab, and their editor. They receive reviewable remediation pull or merge requests and can request more time from a remediation discussion. Compatible IDE assistants can query current policy through BIMP’s MCP endpoint.
Automation owners
Section titled “Automation owners”Use service accounts, API keys, the typed HTTP API, MCP, or signed event destinations to reuse BIMP decisions in surrounding workflows. Machine access is scoped to an organization and the authority you assign.
What BIMP does not replace
Section titled “What BIMP does not replace”BIMP is intentionally focused on base-image governance. It can sit alongside vulnerability, registry, CI/CD, runtime, and security systems, but it is not a general vulnerability scanner, SIEM, cloud security platform, or runtime protection product.
BIMP’s auditability and isolation controls can support assurance work. They do not, by themselves, claim certification against a regulatory standard.
Next step
Section titled “Next step”Follow the Quickstart to move from a new organization to reviewed scan results and an optional first remediation.