Remediation and routines

BIMP turns a published base-image decision into work that fits the repository’s normal Git workflow. It prepares a bounded source change, opens or updates a pull or merge request, and keeps the provider result linked to the policy and affected artifacts.

Your team still owns review, testing, approval, and deployment. BIMP is the helpful colleague carrying the context, not the colleague merging on a Friday afternoon without asking.

Assign repository ownership

Assign a team and routine to a repository from the repository configuration. The assignment belongs to the repository target, so its default and tracked branches share one clear operational owner.

Tracked branches retain their own scan and remediation context. Removing a branch from tracking hides it from active views without changing the ownership model for the repository.

Configure a team routine

Manage teams and their routines under Settings → Operations → Teams. A routine has:

• a repeat interval in positive whole days;
• a UTC start date and time;
• a next due date; and
• an active or paused state.

BIMP displays routine dates in a compact UTC form where the exact schedule matters. The interface may also show a browser-timezone preview during setup.

A routine provides cadence and expected timing for repository work. The impact review uses the next active routine as a scheduling snapshot. Treat that preview as context, not as proof that a pull request has already been created.

Choose a grouping strategy

The organization default is Per artifact. A repository can inherit that default or override it.

Strategy	Result
Per artifact	One request for matching references in an artifact file.
Per image	One request for artifacts with the same target on a branch.

Changing the effective strategy closes active work created under the previous strategy asynchronously and queues replacements for current recommendations. This keeps the pull-request identity aligned with the grouping rule rather than quietly changing what an existing request means.

Start remediation

Remediation can be queued from a policy publish or from an eligible repository action. Before publishing, Review change impact shows the artifacts affected by changed mappings and whether they are due at a routine date or immediately.

For urgent work, Publish and remediate queues the affected changes now. A security-incident publish additionally labels provider work with bimp-security-incident.

BIMP uses bimp-remediation as the default provider label for remediation pull or merge requests.

What BIMP changes

BIMP supports bounded edits to:

• Dockerfile image instructions;
• Compose image references;
• devcontainer image references; and
• conventional Helm values image declarations anchored to a chart.

For Dockerfile images assembled from ARG defaults, BIMP evaluates the resolved image but preserves the source indirection when it can represent the target by updating the owning defaults. If the file is stale or the target cannot be represented safely, remediation fails instead of rebuilding the instruction on guesswork.

Pull or merge request descriptions explain the resolved source-to-target image transition and include instructions for requesting a Snooze Request when that workflow applies.

Follow remediation state

Repository artifact rows show linked active remediation requests. A request may cover more than one image reference, so each relationship is retained even when one row provides the display anchor.

Before the provider request exists, BIMP shows its operation state:

• queued, while work is waiting;
• creating, while the provider request is being opened;
• updating, while existing work is being refreshed; or
• failed, when the provider operation did not complete.

Failed or stale operations expose a retry action where recovery is safe. The worker also requeues stale creating or updating records within its bounded retry budget, then marks exhausted work as failed for investigation.

When policy changes again

Publishing a changed mapping inspects matching remediation before creating more work. Active provider requests are refreshed with the current published recommendation. Closed or merged requests are synchronised locally and skipped.

Under Per image, a recommendation that changes target replaces the obsolete target-group request rather than silently changing its group identity.

When a team needs more time

A developer can post a /snooze command on an eligible remediation pull or merge request. That creates a Snooze Requests task for an authorised security reviewer. An approval produces a time-bound Exception; it does not erase the policy decision.

Continue to Exception workflows for request syntax, review checks, and lifecycle actions.

Troubleshooting

No remediation is shown

Confirm that the repository and branch are tracked, the relevant policy is published, the artifact is affected by that policy, and the repository has the required provider connection and permissions.

The request is marked failed

Open the failure detail, confirm the provider connection and current source file, then use the retry action. Do not hand-edit BIMP’s internal remediation record to make it look open; provider state is part of the evidence.

The proposed change cannot preserve the file

Update the source structure or apply the change manually, then rescan. BIMP fails safely when a target cannot be represented by the existing image token or Dockerfile argument structure.