Scan Image
By Raj Marni. March 27, 2025. Revised. Version: 0.0.06
Layer 2: Scan Functionality Overview
1. Purpose
The Scan functionality integrates a Docker image vulnerability scanner into the k8or Orbit Portal. By clicking “Scan”, the user triggers a behind‑the‑scenes process that checks the image’s layers against known CVEs and logs the outcome. This approach strengthens security early in the pipeline and keeps the user experience consistent and straightforward—just one more button next to Deploy or Transfer, but backed by robust scanning logic, centralized logging, and easy follow‑up if vulnerabilities are found.
2. Key Functions
User‑Initiated Image Scan
OpsBoard: A “Scan” button is displayed next to each uploaded Docker image record.
Scan Request: When clicked, the portal sends a scan command to the back‑end, referencing the image’s identifier (tag, version, environment).
Vulnerability Analysis
Scanner: A dedicated microservice checks the image’s layers and packages.
Threat Store: The scanner compares image contents to a vulnerabilities file storage.
Scan Results: Lists found CVEs, severities, recommended fixes.
Storage & Display of Results
ChartStore or Logging: The system records scan outcomes (e.g., “No vulnerabilities found” or “3 high severity CVEs”) in user logs or image metadata tables.
OpsBoard: The user sees a “Scan Results” panel or a status (e.g., “Scanned: Yes").
Follow‑Up Actions
Alerts or Warnings: If high or critical vulnerabilities are detected, the system may alert users or block certain actions (like Deploy to prod) unless overridden.
Image Updates: The developer can fix issues by rebuilding the image, then re‑scan to confirm the vulnerabilities are addressed.
3. Architecture & Interactions
3.1 Front‑End & Back‑End
Portal FE (c8fmsXX):
Renders the “Scan” button, collects user confirmation, and sends a request (image ID, environment).
Portal BE (c8bmsXX):
Receives the scan request, calls the scanning microservice or library, and logs or updates the results in the database.
3.2 Scanning Logic (Scanner Microservice)
Initiation: The BE microservice provides the Docker image reference (tag, registry path) to the scanner.
Scan Execution: The scanner pulls the image layers or references an internal cache to check for known CVEs.
Results: The scanner returns structured data: found CVEs, severities, recommended versions, etc.
3.3 Data Storage & Display
ChartStore / ViewPort
Possibly a table (like “image_scan_results_1615” or stored in user‑event logs) where each CVE is recorded with severity, date, or a “ScanID”.
UI Feedback
The portal shows “Scanned: No” if never scanned, or “Scanned: Yes – High severity found” if the user hovered or expanded results.
4. Error Handling & Limitations
Image Not Found: If the scanner can’t pull the image from DockerHub or local S3, the system logs an error.
Scanner Failure: Time‑outs, network errors, or an internal crash in the scanning library result in partial or no results. The portal indicates a “Scan failed” state.
Database Logging: If the system can’t insert results into the ChartStore or logs, it retains minimal output, but user is alerted to check logs or retry.
5. Benefits & Impact
Security Visibility
Encourages users to run scans before deploying or promoting images, reducing the chance of shipping known vulnerabilities.
Single Workflow
Embedded in the same Portal interface as Deploy/Transfer, making security scanning part of the developer’s normal container workflow.
Tracking & Auditing
Scan results remain in logs or image metadata, so teams can track improvements or repeated vulnerabilities over time.
Layer 3: Scan Functionality
1. Overview
Scan checks Docker images for vulnerabilities (CVEs) by integrating a security scanning service. The OpsBoard interface exposes a “Scan” button on each image record, which triggers a flow to:
Retrieve the Docker image reference (tag, environment).
Instruct the scanning logic (microservice) to analyze layers/packages.
Store or update vulnerability results in the chart store or an event log.
Display the outcome (e.g., “No vulnerabilities”, or “2 high severity CVEs”) in the Portal UI.
2. Internal Modules & Responsibilities
2.1 Portal Front-End (c8fmsXX)
Trigger: Renders the “Scan” button on the image’s detail card or list.
User Confirmation & Request: Sends a structured request (image ID, environment ID, user info) to the back-end on “Scan” click.
Status Display: Updates the UI with the scanning status (in progress, completed, or errors) and final vulnerability summary.
2.2 Portal Scan Logic (Back-End: c8bmsXX)
Coordinator: Receives the scan request from the FE, possibly stores a “scan initiated” event in user logs.
Scanner Invocation: Calls the scanning microservice/library—passing the image reference or registry path.
Data Consolidation: Once results return, the logic merges them into an easily storable format (CVE list, severities).
Logging & Metadata: Writes final results to the chart store or environment metadata tables (e.g., “image_scan_results” or user-event logs).
2.3 Scanning Service / Microservice
Docker Image Fetch: Retrieves the image layers from DockerHub or local S3, or uses references if already local.
Vulnerability Analysis: Compares each layer/package version to a CVE database.
Results: Returns a structured object (e.g., JSON) with found vulnerabilities, severity levels (low/medium/high/critical), possible remediations.
2.4 ChartStore / ViewPort / Logging
ChartStore (C20): Store eferences in event logs (user-event-log-1621, user-error-log-1624) or a dedicated table (e.g., app-image-scan-1632).
ViewPort (C32): Logs environment or user-lifecycle data if scanning is environment-specific.
Portal Display: The system references these logs or tables to reflect scan statuses and details.
3. Data Flow & Process IDs
User Initiates Scan
Portal FE (c8fmsXX) → Portal Scan Logic (c8bmsXX) with a request ID, e.g.
c8fmsXX-c8bmsXX-e10.
Portal BE → Scanning Service
The back-end calls the scanning microservice, e.g.
c8bmsXX-c12bmsScan-e20, providing the Docker image reference.
Scan Execution
The microservice pulls image layers, checks for CVEs.
Returns results to Portal BE.
Results Storage
The Portal back-end merges these results into the chart store or logs, e.g.
c8bmsXX-c20breXX-e30.
UI Update
FE queries or receives a callback indicating success or error, displaying the final vulnerability list or “No vulnerabilities found”.
4. Error Handling & Edge Cases
Invalid Image Reference
If the scanning microservice can’t locate the image (typo in tag or registry), an error is returned and logged (user-error-log-1624).
Scanner Failure
Network issues pulling the image or internal scanner crashes produce a partial or null result. The system logs the failure and prompts the user to retry.
Performance Constraints
Very large images or slow CVE databases can cause timeouts. The portal might show a “Scan in progress” message or let the user proceed with other tasks while awaiting results.
5. Security & Policy Implications
Access Permissions: The scanning logic typically needs read access to the Docker registry or S3 storing the image.
CI/CD Integration: The environment might require, if configured, a passing scan result (no critical CVEs) before allowing a Deploy or Transfer to production.
Data Sensitivity: Detailed vulnerability info is stored—some organizations might restrict who can see the full CVE list. Portal roles or RBAC can apply.
6. Outcomes & Benefits
Security Shift‑Left
Encourages devs to identify vulnerabilities early in the pipeline, well before deployment.
Tracking & Trends
Historical scans can reveal whether an image’s security posture is improving or if older images are still in use with known flaws.
User Empowerment
The “Scan” button fits with other image actions (Deploy, Transfer), offering a single UI for multiple container lifecycle tasks.
Last updated