BIMP stands for Base Image Management Platform. We’re talking about container base images, the foundation of your application security.
Your base image supplies most of the software that runs inside your container. It includes the software packages and dependencies that your application needs to run.
And yet, we see this software supply chain neglected. Old base images riddled with known vulnerabilities are pushed to production every day because the vulnerable software was part of a base image.
- The dev team are too busy to update the base image
- The security team can see the vulnerabilities, but can’t fix them
- The platform team own the tools, not the outcome
Every base image in every repo needs to be updated continuously, so security fixes flow effortlessly into production.
BIMP does this for you.
How does BIMP Work?
Section titled “How does BIMP Work?”BIMP is a centralized policy engine that connects approved, compliant base images to the teams that consume them. Policy Groups ensure you have full control of which repo, branch and artifact is subscribed to which image catalog.
BIMP creates a regular heartbeat of business-as-usual (BAU) updates, in the form of pull requests / merge requests. We call these Routines.
BIMP cascades emergency changes to every impacted repo as part of zero-day incident response. In BIMP you can track every Security Incident through to closure.
BIMP provides a frictionless exceptional handling process, so that when updates stall security have the full context as to why. Developers can submit Snooze Requests in seconds as a comment on a pull request.
BIMP proves what changed, when it changed and why it changed. Measure the Mean Time To Remediate (MTTR) across the organization or at a team level, identifying opportunities to improve.
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.
Who is BIMP for?
Section titled “Who is BIMP for?”Security Teams
Section titled “Security Teams”Security teams who need to reduce the Mean Time To Remediate (MTTR) known vulnerabilities in their container images.
Platform Teams
Section titled “Platform Teams”Platform teams who want to reduce developer toil and improve security governance. Providing a centralized policy engine that gets teams up to date and keeps them up to date.
Development Teams
Section titled “Development Teams”Developers who know that each security fix is simple in isolation but easily get overwhelmed by noise, not to mention prioritization conflicts with other delivery work.
What BIMP is not
Section titled “What BIMP is not”BIMP is not a Base Image Provider. We work with the providers you have today, whether that be Docker, RedHat, Minimus or Chainguard. BIMP can help your team manage the migration of one image provider to another.
BIMP is not a vulnerability scanner. Despite delivering continuous remediation we decided the world was already full of conflicting vulnerability dashboards, we didn’t want to add another. We recommend you use Syft / Grype or Trivy if you have not already implemented a container scanner.
Continue with a Quickstart: