Instead of waiting for the next routine, you can declare a security incident to show that remediation should be handled as soon as possible.
Prepare the policy mappings
Section titled “Prepare the policy mappings”An incident uses effective, published policy mappings to identify affected images and their approved replacements. Prepare those mappings before you declare the incident. The preparation differs for internally and externally managed mappings.
Internal mappings
Section titled “Internal mappings”- Open Policy and select the relevant Policy Group.
- Add or update each mapping required for the incident.
- Select Review and Publish and review the affected image references.
- Select Publish. Do not select Publish and remediate or create a pull or merge request yet.
External mappings
Section titled “External mappings”- Add or update each required mapping in the connected external mapping file.
- Complete your normal source-control review and merge process.
- Allow BIMP to synchronize the file.
External mapping changes are automatically published when BIMP synchronizes them. There is no separate Review and Publish step in BIMP. Do not create remediation pull or merge requests for the affected application repositories yet.
You can use BIMP search to find Policy Groups that contain a particular image name or tag. This is useful when the affected image appears in more than one Policy Group.
Only effective, published mappings appear when you declare an incident. If a mapping is missing, confirm that its phase is enabled, it has been published, and its Policy Group applies to the intended repositories and branches.
Declare the incident
Section titled “Declare the incident”Open Incidents and select Declare incident.
The Choose policy mappings step defines the incident scope. Select every mapping that belongs to the incident. Each row shows the source image, approved target, Policy Group, and current repository and occurrence counts. Use Search images or policy groups to filter the list by image, tag, or Policy Group name.
A mapping with zero current impact can still be selected. BIMP watches that mapping while the incident is open and adds an occurrence if a later scan finds a matching image.
Select Review impact. Review the number of affected repositories and image occurrences, then:
- enter a clear Incident title;
- add an optional Summary with the context responders need; and
- select Declare incident.
Declaring the incident records its scope and starts tracking matching occurrences. It does not create pull or merge requests.
Open Security-Incident Pull Requests
Section titled “Open Security-Incident Pull Requests”From the incident, select Automatically create relevant PRs to cascade the approved changes across affected repositories.
BIMP previews the work by repository and branch. The preview shows the affected artifacts, source and target images, and whether BIMP will create new work or adopt a compatible existing BIMP pull or merge request. Review any blocked items, then select Create or adopt PRs.
This action will open pull or merge requests on all repos currently in scope.
Each pull or merge request is tagged with bimp-security-incident as well as
bimp-remediation.
If you update the scope of an incident later to add more Policy Groups or repositories, they remain Waiting until you run Automatically create relevant PRs again.
Creating a pull or merge request starts remediation work. The team that owns the repository will still need to review, test, merge, and deploy the change.
Edit an open incident
Section titled “Edit an open incident”Select Edit incident to add mappings to the incident scope or remove a mapping that has no remediation history. Review the resulting repository and occurrence counts before you save the change.
Track remediation status
Section titled “Track remediation status”The Remediation progress bar and repositories table can be used to track every current image occurrence in the incident:
- Waiting means BIMP has found the image, but no active remediation work is linked to it. Run Automatically create relevant PRs to include it. A pull or merge request that is closed without merging also returns to Waiting.
- Provider queued means BIMP has queued, is creating, or is updating the pull or merge request with the code provider.
- Remediation active means the linked pull or merge request is a draft, open, or ready for review.
- Needs attention means creating or updating the pull or merge request failed, or BIMP could not apply the incident label. Review the error shown for the affected repository before retrying or resolving it manually.
- Merged means the linked pull or merge request has been merged.
- No longer observed means a later scan no longer finds that image occurrence in the repository. This may follow a BIMP remediation or a change made outside BIMP.
The number beside each label is the number of occurrences currently in that state.
Select a status filter below the incident summary to focus the repository list on that state.
Track the incident through closure
Section titled “Track the incident through closure”Keep the incident open while you review provider failures, merge the required pull or merge requests, deploy through your normal process, and confirm later repository scans no longer observe the affected images.
When the response is complete:
- select Close incident;
- enter a Resolution note that records the outcome; and
- confirm the closure.
If work is still waiting, queued, active, or needs attention, BIMP asks you to acknowledge the outstanding work before closing. Closure is a human decision; it does not require every pull or merge request to be merged.
Closing stops BIMP from discovering new occurrences for the incident. However, provider operations that are already queued may finish safely, and existing pull or merge requests remain open until a team merges or closes them. A closed incident preserves the incident scope, repository history, progress, resolution note, and time to remediate.
Closed incidents appear under Closed. You can archive a closed incident to move it to Archived, and restore an archived incident to the Closed list later. Archiving does not delete the incident history.
Closed incidents are useful for analyzing recent incidents, performing retrospectives, and agreeing on actions. Once this work is complete, the incident can be archived.