Skip to main content

SCA Scan

What would you do if an npm package or Docker base image used in your project had a security vulnerability? SCA (Software Composition Analysis) automatically analyzes container images and software dependencies for known vulnerabilities (CVEs).

Why is SCA important?

Modern software depends on countless external libraries. On average, more than 80% of application code consists of open source libraries. If even one of these libraries has a security vulnerability, the entire application can be at risk. SCA automatically finds these hidden risks.

SCA Scan Results

Overview​

  • Analysis target: Container images, dependency packages
  • Analysis engine: Trivy (presented to users as the single detecting tool, with no tool selection UI)
  • Vulnerability DB: NVD CVE database, Trivy DB, etc.
  • Separate scan: Image SBOM and license information (not auto-generated by SCA; run separately from the SBOM · License tab)
Backend Storage Unified as Trivy, UI Shows Per-Item Detecting Tool

The backend DB stores all SCA results unified as tool_name='trivy'. However, the UI presents each item with its actual detecting tool via the detected_by field. Because the AST backend runs Trivy and Dependency-Check together and merges the results as a union, items detected by a single tool show a '[Tool] only' badge, while items detected by both tools show a 'cross-validation (Trivy + Dependency-Check)' badge. The UI does not provide a toggle for users to select a tool.

Analysis Targets​

SCA analyzes various types of packages and images.

Image Vulnerabilities​

Analyzes all packages included in a Docker image.

  • OS packages: System packages from Alpine, Debian, Ubuntu, etc. (installed via apt, apk)
  • Language packages: Packages installed via language-specific package managers such as npm, pip, maven, go
  • Base images: Vulnerabilities in the base image itself specified in the FROM clause of the Dockerfile

Dependency Vulnerabilities​

Analyzes the project's dependency files.

  • package-lock.json (Node.js)
  • requirements.txt, Pipfile.lock (Python)
  • pom.xml, build.gradle (Java)
  • go.sum (Go)
  • Gemfile.lock (Ruby)
  • composer.lock (PHP)
Why Analyze Lock Files?

package.json alone cannot tell you the exact installed versions. Lock files such as package-lock.json record the exact installed versions, so vulnerable versions can be detected precisely.

Step 1: Starting an SCA Scan​

  1. Click the [Security Analysis] menu under the "Security" group in the sidebar.
  2. Select a service to analyze from the card carousel at the top of the page.
  3. Select the SCA tab.
  4. Specify the image to analyze on the trigger bar at the top and click the Start Scan button.
Entering Directly via URL

Entering /security?id={serviceId}&area=sca opens the SCA tab for that service directly.

Step 2: Configuring the Scan Target​

2.1 Image Selection (Two Methods)​

Specify the container image to analyze in one of two ways.

  • Built image select dropdown: Choose from the list of images built for that service (recommended)
  • Manual input: Enter the full image path directly (e.g., harbor.company.com/project/app:v1.2.3)

The image selected in the top image table is linked to the result area, so when there are multiple images you can switch the target image.

2.2 Automatic Registry Authentication​

  • If stored credentials exist for the registry the selected image belongs to, they are applied automatically.
  • The stored credentials are sent to the backend automatically without the user needing to enter them separately.
  • Even private registries that require authentication can be scanned immediately without separate input.
Scan Options Use Backend Defaults

VEX Hub filtering cannot be adjusted separately in the user UI; it always runs with the following backend default.

  • VEX Hub filtering default ON

SBOM generation and license analysis are not performed automatically during an SCA (vulnerability) scan. An image SBOM is produced by a separate SBOM generation request (Syft), and license analysis is produced by the independent scan in the SBOM · License tab (Syft + ScanCode). See the SBOM Generation document for details.

Step 3: Running the Scan​

When a scan starts, Trivy is executed, and the AST backend also runs Dependency-Check in parallel. The results are merged as a union where each CVE is tagged with which tool(s) detected it (detected_by field). Progress is shown in real time via WebSocket.

[1/4] Pulling image...                 ← Image download
[2/4] Scanning OS packages...          ← OS package analysis
[3/4] Scanning application packages... ← Application package analysis
[4/4] Applying VEX filters...          ← VEX application
Scan completed!                        ← Done
The box above is a generalized example to help understand the progress stages and does not exactly match the actual output format of the KIOPS console. The UI shows the stage labels defined in the code.
SBOM · License Is a Separate Scan

An SCA scan does not automatically generate an SBOM or license information. If you need an image SBOM (CycloneDX 1.6) and license information, you must run a separate scan yourself from the SBOM · License tab. See the SBOM Generation document for details.

The SBOM and license areas have been unified into one, and license analysis results are accumulated in the license_analysis table. License analysis is performed optionally as part of running an SBOM generation scan.

Expected Scan Time​

Scan time varies by environment (image size, network speed, package count, vulnerability DB cache state, etc.). The values below assume a typical environment and are for reference only.

  • Under 100MB: About 30 seconds
  • 100-500MB: 1-2 minutes
  • Over 500MB: 2-5 minutes

Step 4: Reviewing Results​

4.1 Result Summary​

When the scan completes, you can review the following at a glance.

  • Total vulnerabilities: The total number of detected vulnerabilities
  • Severity distribution: The number of vulnerabilities by Critical/High/Medium/Low
  • Fixable: The number of vulnerabilities fixable by package updates
  • Detecting tool: Shows the actual tool that detected each item. Items detected by a single tool show a '[Tool] only' badge (e.g., Trivy only, Dependency-Check only), while items detected by both tools show a 'cross-validation (Trivy + Dependency-Check)' badge (backend storage is unified as tool_name='trivy', but the per-item detected_by field distinguishes the source). Every item now states its detecting tool, so the source of each result is traceable.

4.2 Categorized View​

Each vulnerability can be classified and handled with the following statuses.

  • open: Newly detected, unhandled item
  • resolved: Fix completed
  • false_positive: Confirmed false positive
  • accepted_risk: Risk accepted (acknowledged but will not be fixed)

4.3 Vulnerability Details​

Clicking each vulnerability shows the following information.

  • CVE ID: The unique identifier of the vulnerability (e.g., CVE-2021-44228)
  • Package name: The name of the vulnerable package
  • Current version: The currently installed version
  • Fixed version: The version where the vulnerability is fixed (if available)
  • Severity: CVSS-score-based severity
  • Description: A detailed explanation of the vulnerability
  • Reference links: Additional information such as NVD and vendor security advisories
Prioritize Vulnerabilities with a Fixed Version

Vulnerabilities that show a "fixed version" are resolved by updating the package. Addressing these before vulnerabilities without a fixed version quickly reduces the vulnerability count.

Step 5: Viewing SCA Scan History​

SCA accumulates and retains the result of every scan. In the "Scan History" section of the SCA tab on the [Security Analysis] page, you can see the following.

  • Parent row per image repo: Rows are grouped by image repository, showing the severity counts of the latest scan.
  • Expand per-tag history: Expanding a parent row lists the scan history per tag in newest-first order, along with the change in vulnerabilities compared to the previous scan.
  • Scan/rescan triggers: The [Scan] / [Rescan] button on each row runs a scan for that image directly.
  • Priority badges: The currently deployed image and the most recently built image are marked with badges, making it easy to tell which image to inspect first.
  • "Viewing" label: The selected image row displays a blue "Viewing" label with an eye icon, visually indicating which image's results are shown in the results area.
Risk Assessment for the Deployed Version

The risk shown on the dashboard and security gate is calculated against the currently deployed image only. Vulnerabilities in previous builds or undeployed images are not reflected in the current risk, so deploying a new build can change the gate verdict. The introduction of deployed-version tracking enables accurate risk assessment.

VEX Hub Filtering (Backend Default ON)​

What Is VEX?​

VEX (Vulnerability Exploitability eXchange) is data that assesses whether a particular vulnerability actually affects the product. Even if a vulnerable function exists in the code, there is no impact if that function is never called.

How It Works​

  • KIOPS enables VEX Hub filtering by default in the backend during SCA scans.
  • The UI does not provide a toggle for users to enable or disable VEX filtering.
  • VEX verdict results are recorded together in the SBOM.

Filtering States​

  • Affected: Actually affected - action is required.
  • Not Affected: Not affected - excluded by the VEX verdict.
  • Fixed: Already fixed - resolved in the latest version.
  • Suppressed: An item excluded from display by VEX or user handling

Fixing Vulnerabilities​

Package Updates​

The most common fix is to update the package to a version where the vulnerability is resolved.

  1. Check the "fixed version" in the scan results.
  2. Update the dependency file to that version. 
    # Node.js example
    npm update lodash

    # Python example
    pip install --upgrade requests
  3. Rebuild the image.
  4. Rescan to confirm the vulnerability is resolved.
Changing the Base Image

If the base image itself has many vulnerabilities, switching to a newer version or a different image is effective. Alpine Linux includes a minimal set of packages, so it often has fewer vulnerabilities.

# Vulnerable version
FROM node:16-alpine3.14

# Fixed version
FROM node:20-alpine3.19

Troubleshooting​

Scan Failure​

  • Image pull failure: Stored registry credentials may be expired or have insufficient permissions. Refresh the credentials in the credential settings.

  • Timeout: A scan may time out if the image is too large. Consider optimizing the image.

  • DB update failure: This occurs when the vulnerability database update fails. Check the network connection and try again.

Over-Detection (Too Many Vulnerabilities)​

If too many vulnerabilities are detected and management becomes difficult, classify confirmed items as false_positive or accepted_risk to reduce noise. Replacing the base image with a safer one is also effective.