diff --git a/scripts/trivy/trivyignore.yaml b/scripts/trivy/trivyignore.yaml
index 10a4f1a8418617..a90bd911f552fb 100644
--- a/scripts/trivy/trivyignore.yaml
+++ b/scripts/trivy/trivyignore.yaml
@@ -10,76 +10,3 @@ vulnerabilities:
       In Gitpod’s usage, TypeORM is not exposed to arbitrary user input. For example, DB migrations run preset queries;
       the server/bridge code does not hand raw JSON from external sources to findOne. Therefore, there is no path for
       injecting malicious JSON into a query, rendering the vulnerability non-exploitable.
-
-  # image-builder-bob
-  - id: CVE-2024-32002
-    statement: |
-      A vulnerability allowing remote code execution when cloning a malicious repository (often leveraging submodules
-      and symlinks on case-insensitive filesystems) that can place malicious scripts in .git/hooks/.	On Windows/macOS
-      (case-insensitive FS), a malicious repo can use symlinks or tricky paths to cause Git to write hook scripts in
-      the main .git directory during clone, which Git then executes automatically. This results in code execution on
-      the system performing the clone.
-
-      The standard exploit path involving .Git vs. .git doesn’t work on Linux. Also, Gitpod’s builder typically
-      fetches known repositories or user-provided repos in a controlled environment. Even if a user cloned a hostile
-      repo in their own workspace, they’d compromise only themselves (in a sandboxed container). No broader exploit
-      of the underlying host is possible.
-
-  - id: CVE-2024-23652
-    paths:
-      - "usr/bin/buildctl"
-      - "usr/bin/buildkitd"
-    statement: |
-      A vulnerability where the RUN --mount cleanup logic could remove directories outside of the build context,
-      leading to potential arbitrary file deletion on the host if BuildKit is used with untrusted Dockerfiles.
-
-      Gitpod runs BuildKit inside containers in a Kubernetes environment. Even if a malicious Dockerfile tries to
-      exploit this, it can only affect the container’s filesystem (which the user already controls). There’s no path to
-      escalate beyond the container to the node’s host filesystem, so this has no material security impact in Gitpod’s
-      isolated build setup.
-
-  - id: CVE-2024-23653
-    paths:
-      - "usr/bin/buildctl"
-      - "usr/bin/buildkitd"
-    statement: |
-      A flaw allowing a build container to run with elevated privileges without the required security.insecure
-      entitlement. This can grant a malicious Dockerfile or BuildKit client more privileges than intended during the
-      build.
-
-      In Gitpod, BuildKit operates under tight Kubernetes constraints. Even if a user tries to request privileged mode,
-      it won’t escalate to the actual host or break out of the container. The user is effectively “attacking” their
-      own build container. They already have control there, so there’s no additional privilege escalation beyond their
-      existing user container in Gitpod’s architecture.
-
-
-  - id: CVE-2024-45337
-    paths:
-      - "usr/bin/buildctl"
-      - "usr/bin/buildkitd"
-      - "usr/bin/kube-rbac-proxy"
-    statement: |
-      An SSH authentication bypass issue if PublicKeyCallback is used incorrectly in Go’s SSH server library. Misuse
-      can lead to validating the wrong public key and granting access under the wrong identity.
-
-      Neither BuildKit nor kube-rbac-proxy runs an SSH server that uses PublicKeyCallback for authentication.
-      Kube-rbac-proxy does HTTP-based RBAC checks. BuildKit may include x/crypto/ssh but does not expose an SSH server
-      requiring PublicKeyCallback. Hence, there’s no exploit path for this bug in these components.
-
-  - id: CVE-2024-24790
-    statement: |
-      A logic flaw in Go’s net/netip packages causing misclassification of certain IPv4-mapped IPv6 addresses (e.g., failing to mark them as loopback/private). Could lead to security checks that rely on IP classification (like IsPrivate, IsLoopback) being bypassed.
-
-      In these images (Cloud SQL Proxy, bob-runc, BuildKit, kube-rbac-proxy), there’s no code path that enforces security decisions using IsLoopback/IsPrivate from Go’s netip. They either accept connections in a controlled environment (Cloud SQL Proxy -> GCP) or use different authentication mechanisms (kube-rbac-proxy). Hence, no external attack can exploit this misclassification.
-
-  - id: CVE-2024-45491
-    statement: |
-      Integer overflow in dtdCopy when dealing with a large number of default attributes in a DTD, causing potential out-of-bounds write or memory corruption in Expat on 32-bit systems.
-
-      The container runs on a 64-bit Alpine Linux environment, not a 32-bit build, so the overflow is not triggered the same way. Moreover, there is no component automatically parsing untrusted XML with Expat. Hence, no practical exploitation path in Gitpod’s usage.
-
-  - id: CVE-2024-45492
-    statement: |
-      Similar integer overflow in the nextScaffoldPart function of Expat, triggered by enormous or deeply nested content models in the DTD. Can lead to denial of service or potential corruption.
-
-      As with CVE-2024-45491, the environment is 64-bit Alpine, and no untrusted XML parsing occurs by default. Thus, the bug cannot be reached in a way that leads to exploitation.