Skip to main content

🔐 Vulnerability Manager – User Guide

Welcome to the PortX Vulnerability Manager! This feature surfaces and prioritizes security findings across your deployments. It automatically correlates your current GitOps-deployed image versions with findings from AWS Inspector2, so you always see vulnerabilities for exactly what is running — not stale or undeployed images.

🛍 How to Access the Vulnerability Manager​

  1. Go to Operations → Deployments in the Integration Manager sidebar.
  2. Select the Vulnerabilities tab (next to Applications).
  3. The vulnerability list loads automatically for the currently selected environment.

📋 The Vulnerability List​

Each row in the list represents a single finding for a specific deployed image. The table shows:

ColumnDescription
SeverityColor-coded badge: CRITICAL (red), HIGH / MEDIUM (amber), LOW / INFORMATIONAL / UNTRIAGED (neutral)
CVEThe vulnerability identifier (e.g., CVE-2024-1234)
TitleShort description of the vulnerability (hover for full text)
Imagerepository:tag of the affected deployed image (hover for full value)
FixYES (green) · PARTIAL (amber) · NO (red ✕) — whether a patched version exists
ExploitShield icon (amber) when a known exploit exists; hover shows the EPSS score
Last seenWhen AWS Inspector last observed this finding

Sorting​

Click any column header to sort. Click again to reverse direction. Default sort is Severity descending (most critical first).

Filtering​

Use the faceted filter controls above the table to narrow results:

  • Severity – filter by one or more severity levels
  • Fix – filter by fix availability (YES, PARTIAL, NO)
  • Image – filter to a specific repository:tag

Filters combine with AND across facets and OR within a facet. Click ✕ Reset to clear all active filters.

Pagination​

Use the page size selector (10 / 20 / 50 rows) and the pagination controls below the table to navigate large result sets. Your preferred page size is remembered across sessions.

🔎 Vulnerability Detail Page​

Click any row to open the full detail view. The breadcrumb reads Operations → Deployments → Vulnerabilities → [CVE ID] and shows the following sections:

Overview​

FieldDescription
Imagerepository:tag of the affected image
DigestExact sha256 digest of the scanned image (when available)
First seenWhen Inspector first observed this finding
Last seenWhen Inspector last observed this finding
Inspector scoreAWS Inspector severity score (0–10); higher means more severe
EPSSExploit Prediction Scoring System — probability (0–1) the vulnerability will be exploited in the wild within the next 30 days

Description​

Full text of the vulnerability description from AWS Inspector (shown only when available).

Fix​

FieldDescription
AvailableYES, PARTIAL, or NO
RecommendationSuggested remediation text (when provided)
DocsExternal link to fix documentation (when provided)

This section is hidden when Fix: NO and no recommendation or documentation link is present.

Affected Packages​

A table listing each vulnerable package with its Name, Version, Fixed in version (when known), and Package manager.

References​

Links to CVE advisories and related documentation. Duplicate URLs are automatically deduplicated.

⚙️ How It Works​

The Vulnerability Manager resolves your current vulnerability exposure in three steps on every request:

  1. GitOps version lookup – The platform reads your tenant's GitOps repository to determine which image tag is currently deployed for each app in the selected environment.
  2. ECR digest resolution – Each deployed (repository, tag) pair is resolved to its exact image digest via ecr:BatchGetImage. Multi-arch (manifest-list) images are automatically expanded to their individual platform digests.
  3. Inspector2 scan – AWS Inspector2 is queried for findings matching those exact digests. Results are severity-sorted and returned.

Results are cached for 30 seconds per environment per pod. To force a fresh fetch immediately after a deployment, click Retry in the error banner or navigate away and back to the tab.

Note: Because caching is local to each backend pod, some requests may hit a pod with a cold cache and take longer. This is expected behavior.

🔍 Identifying Vulnerabilities​

There are two ways to identify vulnerabilities in your deployed services:

Option 1 – Vulnerability Manager (Recommended)​

Use the Vulnerabilities tab within Deployments to view Inspector findings scoped to exactly what is deployed in the selected environment.

Option 2 – AWS Inspector (Out-of-band)​

For a deeper or unfiltered view:

  1. Navigate to Manage → AWS Console → AWS Inspector service.
  2. Find your API in the Inspector findings list.
  3. Review the full vulnerability report for your deployed image.

🚀 Remediating Vulnerabilities – System Patching Process​

When vulnerabilities are identified, use the following process to patch and rebuild your service.

Step 1 – Identify the Vulnerabilities​

Use either the Vulnerability Manager or AWS Inspector (described above) to get a full list of findings before beginning remediation.

Step 2 – Update Your Build Template​

Once vulnerabilities are identified, update your build pipeline:

  • Use the appropriate Golden Images as your base image. These are rebuilt nightly: Install from the command line $ docker pull ghcr.io/portx-labs/golden-temurin:latest Use as base image in Dockerfile: FROM ghcr.io/portx-labs/golden-temurin:latest
  • Add an apt-get update step (or equivalent) to your image build to ensure the latest OS-level packages are applied on top of the Golden Image.

Step 3 – Rebuild in Dev First​

Always rebuild and validate in the DEV environment before promoting to STG or PROD.

  • Most OS-level patches will be pulled in automatically via the updated Golden Images:
  • Running apt-get update (or your distro's equivalent) during the build ensures any remaining system packages are current.

Note: Rebuild your image with provenance: false set in your build configuration to ensure the resulting image is discoverable by the Vulnerability Manager.

Step 4 – Patch Application-Level Dependencies​

For dependencies that are not covered by OS-level updates:

  • For any package that cannot be updated, coordinate with your security contact to document the justification for the exception.

Step 5 – Improve Test Coverage​

To work toward more automated patching in the future:

  • Use AI-assisted tooling to expand your application test suite.
  • Higher test coverage increases confidence in automated or low-touch patching when all tests pass.

✅ Summary​

StepActionDetails
1Identify vulnerabilitiesUse Vulnerability Manager or AWS Inspector
2Update build templateSwitch to Golden Images base
3Rebuild in DevValidate before promoting; set provenance: false in build config
4Patch app dependenciesUse the Patching Dependency Matrix; register exceptions in Vanta
5Improve test coverageIncrease automated test coverage to enable safer future patching

⚠️ Important Notes​

  • provenance: false must be set in your build configuration for the image to be discoverable in the Vulnerability Manager.
  • Always start remediation in DEV, then promote through STG to PROD after validation.
  • Packages that cannot be patched must be tracked as exceptions in Vanta with documented justification.

Need assistance? Reach out to PortX support or your internal security team.