Oracle Cloud Vulnerability Scanning Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Security, Identity, and Compliance

1. Introduction

What this service is
Oracle Cloud Vulnerability Scanning is a managed service in Oracle Cloud Infrastructure (OCI) that helps you discover security weaknesses in your cloud workloads—most commonly compute instances (hosts) and container images—so you can remediate issues before they are exploited.

Simple explanation (one paragraph)
You configure what to scan (for example, a set of compute instances in a compartment, or images in Oracle Cloud Infrastructure Registry), choose a schedule, and OCI automatically runs scans and produces findings such as known vulnerable packages (CVEs) and risky network exposures (open ports). Your team then uses the results to patch, harden, or change network rules.

Technical explanation (one paragraph)
Vulnerability Scanning uses scan recipes (what checks to run and how) and scan targets (which resources to scan) to orchestrate periodic or on-demand scans. Depending on scan type, it can use an agent-based approach for host vulnerability data (installed via the Oracle Cloud Agent plugin on instances) and a network-based approach for port scanning. For container images, it scans image layers for known vulnerabilities and reports results through the OCI console and APIs.

What problem it solves
Most cloud incidents still begin with basic hygiene failures: unpatched packages, vulnerable libraries, and overly permissive network exposure. Vulnerability Scanning helps you: – Continuously identify known vulnerabilities (CVEs) in your compute fleet. – Detect unexpectedly open ports/services. – Shift security left for containers by scanning images before deployment. – Provide auditable evidence for security and compliance programs.

Naming/status note: The service is commonly referred to as OCI Vulnerability Scanning or Vulnerability Scanning Service (VSS) in Oracle documentation. In this article, the primary service name remains Vulnerability Scanning. Verify the latest naming and capabilities in official docs: https://docs.oracle.com/en-us/iaas/scanning/home.htm

2. What is Vulnerability Scanning?

Official purpose

Oracle Cloud Vulnerability Scanning is intended to help OCI customers identify known security vulnerabilities and insecure configurations in supported OCI resources (most notably compute instances and container images), and to operationalize remediation through repeatable, scheduled scanning.

Core capabilities (high-level)

Common, current capabilities include: – Host vulnerability scanning (agent-based): identify vulnerable OS packages and related CVEs on compute instances (requires Oracle Cloud Agent plugin on supported OSes). – Host port scanning (network-based): identify open ports and services visible on the network (useful for exposure management). – Container image scanning: scan container images (typically those stored in OCI Registry) for known vulnerabilities.

Scope note: The exact list of supported operating systems, container registry types, and scan behaviors can change. Always confirm against the “Supported” and “Limitations” sections in official docs: https://docs.oracle.com/en-us/iaas/scanning/using/overview.htm (Verify in official docs if the URL path differs.)

Major components

While terminology can evolve, Vulnerability Scanning commonly uses the following building blocks:

Scan recipes
Define what to scan and how (for example, agent-based vulnerability checks, port scan settings, or container scanning configuration).
Scan targets
Define where to run scans (for example, a compartment, a set of instances, or registries/repositories), often with filters such as tags.
Scan reports / findings
Results that include vulnerabilities (CVE identifiers, severity), affected packages, and exposure information (for port scans).
Policies (IAM)
Permissions to create/manage recipes and targets, and to view scan results.

Service type

Managed security service (SaaS-like experience inside OCI).
Exposed through OCI Console, OCI APIs, and typically OCI CLI/SDK (verify the exact CLI command group in current CLI docs).

Regional vs global, and scope

In OCI, most services are regional and operate on resources in that region. Vulnerability Scanning is generally treated as a regional service where you configure recipes/targets per region, and scan resources in that region.

Scope: Tenancy-wide service with compartment-scoped resources (recipes/targets are created in compartments).
Results visibility: Controlled by IAM policies and compartment access.

Verify the regional behavior and cross-region constraints in official documentation for Vulnerability Scanning in your target regions.

How it fits into the Oracle Cloud ecosystem

Vulnerability Scanning fits into the Security, Identity, and Compliance portfolio alongside services such as: – IAM (users, groups, policies, dynamic groups) – Audit (records API activity) – Logging (central log management) – Cloud Guard (posture management; may consume vulnerability signals—verify the exact integration points) – OCI DevOps and CI/CD patterns (use scan results to influence deployment decisions—often implemented by your pipeline logic)

3. Why use Vulnerability Scanning?

Business reasons

Reduce breach likelihood by systematically identifying known vulnerabilities.
Lower audit and compliance burden with repeatable scanning and documented findings.
Improve security ROI by focusing remediation on the highest severity and most exposed issues.

Technical reasons

Visibility into vulnerabilities at OS package level and container image level.
Exposure detection via port scans to catch unintended open services.
Standardization via centrally managed recipes/targets and consistent reporting.

Operational reasons

Scheduled automation reduces reliance on ad hoc manual scans.
Compartment and tag-based targeting aligns with how OCI environments are organized.
Repeatable remediation loops: scan → fix → rescan → verify closure.

Security/compliance reasons

Supports common security control expectations such as:
“Vulnerability scanning is performed regularly”
“Findings are tracked and remediated”
“Internet exposure is minimized”
Helps support evidence for programs aligned to SOC 2 / ISO 27001 / internal security baselines (implementation specifics are on you).

Scalability/performance reasons

Designed to scan fleets by using OCI-managed orchestration rather than individual engineers running scanners from laptops.
Results aggregation makes it easier to prioritize at scale.

When teams should choose it

Choose Vulnerability Scanning when you: – Run compute instances and want continuous vulnerability visibility. – Publish container images and want image vulnerability scanning as part of platform hygiene. – Need a managed service integrated into OCI IAM and compartments. – Want exposure management signals (open ports) without deploying a third-party scanner.

When teams should not choose it

Vulnerability Scanning may not be the right fit when: – You require deep web application scanning (DAST). Use a DAST tool instead. – You need agentless authenticated scanning across heterogeneous on-prem networks (typical enterprise VM scanners may fit better). – You need advanced ticketing workflows and vulnerability lifecycle management built-in (you can integrate externally, but it’s not the same as a full VM program platform). – Your workloads are primarily outside OCI or you require cross-cloud centralized scanning under one tool (consider a multi-cloud vulnerability management platform).

4. Where is Vulnerability Scanning used?

Industries

Financial services: auditability and strong patch hygiene expectations.
Healthcare: protection of regulated systems and secure configuration management.
SaaS and technology: container and host hygiene in fast-moving environments.
Public sector: baseline hardening and vulnerability reporting requirements.
Retail/e-commerce: reduce attack surface and keep customer-facing systems patched.

Team types

Security engineering and AppSec
Cloud platform engineering
DevOps / SRE
Infrastructure and operations
Compliance / GRC (as consumers of evidence)

Workloads

Compute fleets running Linux (and other supported OSes)
Containerized workloads using OCI Registry images
Bastion hosts, API servers, background workers, jump boxes (careful with exposure)
Internet-facing workloads where port exposure must be continuously monitored

Architectures

Multi-tier VCN architectures (public subnet for LB, private subnets for apps/db)
Hub-and-spoke network topologies
Multi-compartment landing zones where governance relies on compartments and tags

Real-world deployment contexts

Production: scheduled scans, change management, patch windows, reporting.
Dev/test: fast feedback loops; scanning before promotion to prod; more frequent scanning.

5. Top Use Cases and Scenarios

Below are realistic scenarios where Oracle Cloud Vulnerability Scanning fits well.

1) Baseline vulnerability scanning for a compute fleet

Problem: You have dozens/hundreds of instances and no consistent view of missing security patches.
Why this service fits: Centralized recipes/targets + recurring scans produce consistent findings.
Example: A platform team scans all instances in the prod-app compartment weekly and generates a remediation report for owners.

2) Detecting unintended internet exposure via port scanning

Problem: Developers open ports temporarily and forget to close them.
Why this service fits: Port scanning highlights open ports/services, helping reduce attack surface.
Example: A port scan flags TCP/2375 open on a host; the team fixes NSG rules and re-scans.

3) Container image hygiene for OCI Registry

Problem: Images are pushed with vulnerable libraries; vulnerabilities reach runtime clusters.
Why this service fits: Image scanning identifies vulnerable layers and CVEs.
Example: A base image update reduces critical CVEs; the team blocks promotion until scans are clean (implemented in pipeline logic).

4) Compartment-based scanning aligned to ownership boundaries

Problem: Different teams own different environments; centralized scanning must respect boundaries.
Why this service fits: OCI IAM + compartment-scoped targets provide separation of duties.
Example: Security manages recipes; each app team manages targets in their compartments.

5) Tag-based targeting for dynamic infrastructure

Problem: Autoscaled or frequently replaced instances make static targeting brittle.
Why this service fits: Tag-based selection keeps scan scope current.
Example: Instances tagged scan=true are automatically included without target changes.

6) Pre-audit evidence collection

Problem: Auditors ask for vulnerability scanning frequency and remediation proof.
Why this service fits: Scheduled scans and stored reports provide evidence.
Example: Export scan reports per quarter and map remediation actions to tickets.

7) Hardening initiative for legacy workloads

Problem: Older systems accumulate vulnerabilities and unknown exposures.
Why this service fits: Scans provide a prioritized list of vulnerabilities and exposed ports.
Example: A legacy app is moved to OCI; scans identify outdated OpenSSL packages and open admin ports.

8) Golden image validation

Problem: VM images drift from security baselines.
Why this service fits: Scan newly provisioned hosts built from “golden images” to validate patch level.
Example: After a new image release, a canary instance is scanned to ensure patch compliance.

9) Post-incident assurance

Problem: After a security incident, leadership wants proof systems are patched and exposure is reduced.
Why this service fits: Repeated scans measure progress and confirm closure.
Example: After a disclosed vulnerability, scans verify that all affected packages were patched across environments.

10) Continuous exposure management for DMZ-like segments

Problem: You run internet-facing services and must minimize open ports.
Why this service fits: Port scans provide recurring validation of intended exposure.
Example: Only 80/443 should be reachable; scan results confirm no drift.

11) M&A onboarding of acquired workloads into OCI

Problem: Acquired systems have unknown vulnerability posture.
Why this service fits: Standard recipes and scans provide rapid baseline assessment.
Example: In the first week after migration, run scans and plan patch waves.

12) Developer self-service scanning visibility

Problem: Developers need visibility into vulnerabilities without full security tool sprawl.
Why this service fits: OCI-native service with IAM controls and console access.
Example: Developers can view findings for instances in their dev compartment and fix issues early.

6. Core Features

Feature availability can vary by region and may evolve. Confirm current feature set in official documentation: https://docs.oracle.com/en-us/iaas/scanning/home.htm

6.1 Host vulnerability scanning (agent-based)

What it does: Identifies vulnerable OS packages and related CVEs on compute instances via an installed agent (Oracle Cloud Agent plugin).
Why it matters: OS/package vulnerabilities are a leading cause of compromise.
Practical benefit: You can prioritize patching by severity and affected hosts.
Limitations/caveats:
Requires supported OS and agent/plugin enablement.
Instances must be able to communicate with OCI endpoints required by the agent (network path required).

6.2 Host port scanning (network-based)

What it does: Scans network ports to identify services exposed on instances.
Why it matters: Attack surface management is as important as patching.
Practical benefit: Catches misconfigurations like open admin ports, debugging endpoints, or unintended listeners.
Limitations/caveats:
Results depend on network reachability from the scanning infrastructure.
Firewalls/security rules can block scan visibility (which may be desired, but affects detection).

6.3 Container image vulnerability scanning

What it does: Scans container images for known vulnerabilities in packages/libraries present in the image layers.
Why it matters: Vulnerable images lead to vulnerable runtimes (Kubernetes/containers).
Practical benefit: Helps enforce image hygiene before deploy.
Limitations/caveats:
Often focuses on images in OCI Registry; confirm support for external registries in official docs.
Findings reflect what’s in the image; runtime configuration issues may require other tools.

6.4 Scan recipes and scan targets

What it does: Separates scan configuration (recipe) from scope (target).
Why it matters: Enables reuse and standardization across teams and compartments.
Practical benefit: Security teams can curate recipes; app teams can apply them.
Limitations/caveats:
Requires good governance to avoid gaps or overlapping targets.

6.5 Scheduling and recurring scans

What it does: Runs scans on a schedule (and sometimes on-demand depending on scan type—verify in official docs).
Why it matters: Vulnerabilities appear continuously; one-time scans quickly become stale.
Practical benefit: Predictable cadence aligned to patch windows.
Limitations/caveats:
Excessively frequent scanning can increase operational noise; tune to your remediation capacity.

6.6 Compartment and tag-based organization

What it does: Uses OCI compartments (and often tags) to select resources.
Why it matters: Aligns with OCI governance and enterprise organization models.
Practical benefit: Delegated administration with strong separation of duties.
Limitations/caveats:
Tag hygiene becomes important; inconsistent tagging can lead to missed assets.

6.7 Reporting and severity information

What it does: Provides findings with severity levels and vulnerability identifiers (for example CVE).
Why it matters: Enables prioritization and measurable risk reduction.
Practical benefit: Faster triage based on severity and asset criticality.
Limitations/caveats:
Severity is only one input; exploitability and exposure matter too.

6.8 API access and automation potential

What it does: Enables programmatic management and retrieval of results using OCI APIs (and typically SDKs/CLI).
Why it matters: Enables integration into ticketing, dashboards, and CI/CD.
Practical benefit: Automated reporting, auto-ticket creation, and compliance evidence generation.
Limitations/caveats:
Requires careful IAM design and secure handling of credentials.

7. Architecture and How It Works

High-level service architecture

At a high level, Vulnerability Scanning works like this:

You define scan recipes (what to scan).
You define scan targets (what resources to scan).
OCI orchestrates scan execution: – For agent-based host vulnerability scanning, the instance’s Oracle Cloud Agent plugin collects inventory/vulnerability data and reports it back to the service. – For port scanning, OCI scanning infrastructure probes ports reachable per network path. – For container scanning, OCI scans image contents and records findings.
Results are stored and shown in the OCI Console and accessible through APIs.
You remediate (patch packages, rebuild images, tighten NSGs/security lists) and re-scan.

Request/data/control flow (conceptual)

Control plane: Create/update recipes and targets; start scans; view results.
Data plane:
Host agent sends metadata/vulnerability info to OCI service endpoints.
Port scans send probes to instance endpoints and record responses.
Container scanning analyzes image layers and stores results.

Integrations with related OCI services (common patterns)

IAM: Policies controlling who can manage recipes/targets and view results.
Audit: Tracks creation/modification of scanning resources and API calls.
Logging (optional pattern): Centralize operational logs; Vulnerability Scanning findings themselves may not be “logs,” but you can integrate via automation that writes summaries to Logging.
Notifications / Events (possible pattern): Trigger workflows when scans complete or when critical findings appear (verify available event types in official docs).
OCI Registry (OCIR): Typical source for container images to scan.
VCN / NSG / Security Lists: Network configuration heavily influences port-scan visibility and real exposure.

Dependency services

Compute instances for host scanning
Oracle Cloud Agent on instances for agent-based scanning
OCI Registry for image scanning
VCN/subnets/routing for reachability (especially for port scans)

Security/authentication model

Human/admin actions use OCI IAM (users, groups, policies).
Compute instances typically rely on Oracle Cloud Agent with OCI-managed identity mechanisms.
Automation uses OCI SDK/CLI credentials (API keys, instance principals, resource principals—choose per best practice).

Networking model considerations

Agent-based scanning requires outbound connectivity to relevant OCI endpoints.
Port scanning depends on routing/security rules and whether the instance is reachable from the scanning infrastructure path.

Monitoring/logging/governance considerations

Use Audit to track who changed scan recipes/targets.
Use tags and compartment structure to align scanning ownership.
Track remediation SLAs outside the service (ticketing system), but link evidence to scan results.

Simple architecture diagram (Mermaid)

flowchart LR
  U[Security Engineer / DevOps] -->|Create recipe/target| VSS[OCI Vulnerability Scanning]
  VSS -->|Agent-based scan| AGENT[Oracle Cloud Agent on Compute]
  VSS -->|Port scan probes| NET[(Network)]
  VSS -->|Image scan| OCIR[OCI Registry]
  VSS --> R[Scan Results / Reports]
  R -->|Remediate| OPS[Ops: Patch, Rebuild, Tighten NSGs]

Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph Tenancy[OCI Tenancy]
    subgraph Compartments[Compartment Structure]
      SEC[Security Compartment\n(Recipes, Policies)]
      PROD[Prod App Compartment\n(Targets, Instances)]
      DEV[Dev Compartment\n(Targets, Instances)]
    end

    IAM[IAM Policies & Groups]
    AUD[Audit]
    VSS[OCI Vulnerability Scanning]

    subgraph Network[VCN]
      PUB[Public Subnet\n(LB/Bastion)]
      PRIV[Private Subnets\n(App/Workers)]
      NSG[NSGs/Security Lists]
      SGW[Service Gateway or NAT/Internet GW]
    end

    subgraph Workloads[Workloads]
      INST1[Compute Instances\n(Oracle Cloud Agent plugin enabled)]
      OCIR[OCI Registry\n(Container Images)]
    end

    subgraph Ops[Operations Tooling]
      TICKETS[Ticketing / ITSM]
      DASH[Dashboards / Reports]
      CICD[CI/CD Pipeline\n(uses APIs to check results)]
    end
  end

  IAM --> VSS
  VSS --> INST1
  VSS --> OCIR
  VSS --> NSG
  VSS --> DASH
  VSS --> TICKETS
  VSS --> AUD
  INST1 --> SGW
  CICD --> VSS

8. Prerequisites

Tenancy/account requirements

An active Oracle Cloud (OCI) tenancy.
Access to a region where Vulnerability Scanning is available (verify region availability in official docs).

Permissions / IAM roles

At minimum, the person configuring Vulnerability Scanning needs permissions to manage scanning resources.

Common OCI policy patterns (validate exact resource family names in official docs):

Allow group <group-name> to manage vulnerability-scanning-family in compartment <compartment-name>

You may also need permissions to view or manage compute and networking resources depending on what you create during the lab (instance, VCN, etc.). For example (broad examples—tighten for production):

Allow group <group-name> to manage instance-family in compartment <compartment-name>
Allow group <group-name> to manage virtual-network-family in compartment <compartment-name>
Allow group <group-name> to read repos in compartment <compartment-name>   # for OCI Registry usage (verify)

Always follow least privilege. Confirm the exact policy statements for Vulnerability Scanning in official IAM documentation for this service.

Billing requirements

Vulnerability Scanning service pricing can be no additional cost in some OCI offerings, but you must verify the current pricing model for your tenancy/region.
You will still pay for underlying resources used in the lab:
Compute instance
Block volumes
Registry storage (if using container images)
Network egress (if applicable)

Tools needed

OCI Console access (web browser).
Optional: SSH client to access the compute instance.
Optional: OCI CLI (only if you plan to automate); verify latest CLI docs: https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm

Region availability

Confirm Vulnerability Scanning is available in your chosen region:
Start at the official documentation home and check “Availability”/“Regions” notes: https://docs.oracle.com/en-us/iaas/scanning/home.htm

Quotas/limits

OCI enforces service limits (number of targets, recipes, scans, etc.). Check your tenancy’s service limits:
OCI Console → Governance & Administration → Limits, Quotas and Usage (exact menu names can vary).

Prerequisite services for the lab

OCI Compute (to create a test instance)
VCN networking (VCN, subnet, security rules)
Oracle Cloud Agent on the instance (for agent-based host vulnerability scanning)

9. Pricing / Cost

Do not rely on blog posts for pricing. Always confirm current pricing on official Oracle pages and in your tenancy.

Official pricing sources

Oracle Cloud price list: https://www.oracle.com/cloud/price-list/
OCI cost estimator: https://www.oracle.com/cloud/costestimator.html

Pricing dimensions (what typically drives cost)

Vulnerability Scanning cost can be structured in one of these ways (you must verify which applies now): – No additional service charge for the scanning feature itself (common for some OCI security services), with charges only for underlying resources. – Usage-based charge per scanned asset, per scan, or per image (possible in some clouds/services; verify for OCI Vulnerability Scanning specifically).

Because pricing can change, treat the following as the safe cost model to plan around:

Direct cost drivers (most reliable)

Compute instances you run (shape, OCPU count, memory) for host scanning targets.
Block volumes attached to instances.
OCI Registry storage (GB stored) and possibly requests (depending on registry pricing model).
Network egress to the internet (for patching, package downloads, and general workload operations).

Indirect/hidden cost drivers

Patch operations: downloading updates may cause outbound traffic and operational overhead.
Long retention of artifacts: storing old container images increases registry storage costs.
Extra environments: scanning dev/test/prod multiplies the number of scanned resources and remediation workload.

Free tier considerations

Oracle Cloud has a Free Tier program, but eligibility varies and changes over time. If you plan a low-cost lab: – Use an Always Free eligible compute shape (if available in your region and tenancy). – Keep the instance running only as long as needed. – Avoid unnecessary public egress.

Verify Always Free details: https://www.oracle.com/cloud/free/

How to optimize cost (practical)

Scan what matters: prioritize internet-facing and sensitive systems.
Use tag-based targeting so ephemeral instances are included only when appropriate.
Tune scan frequency to your patch cadence (weekly/biweekly is common; daily may be noisy unless you have mature automation).
Reduce registry bloat: enforce image retention policies (keep last N releases).
Use private networking and service gateway/NAT patterns to control egress (architecture-dependent).

Example low-cost starter estimate (no fabricated numbers)

A minimal lab typically includes: – 1 small compute instance for a short time – 1 boot volume – Minimal outbound traffic for SSH and patch metadata – (Optional) a small amount of OCI Registry storage if testing container scans

Use the OCI cost estimator to model the compute shape and storage for your region.

Example production cost considerations

In production, plan for: – Total number of instances in scan scope (by compartment and tags) – Scan schedules and operational overhead of remediation – Container image volume and retention – Integration costs: SIEM/ITSM tooling, dashboards, automation runtime (Functions/DevOps runners)

10. Step-by-Step Hands-On Tutorial

This lab walks you through enabling host vulnerability scanning (agent-based) and port scanning for a single compute instance in Oracle Cloud, using recipes and targets.

Objective

Configure Oracle Cloud Vulnerability Scanning to scan a compute instance for: 1) vulnerable OS packages (agent-based host vulnerability scan), and
2) open ports (port scan),
then review findings, remediate one issue, and re-scan to verify improvement.

Lab Overview

You will: 1. Create a compartment and a small compute instance. 2. Ensure Oracle Cloud Agent is running and the relevant plugin is enabled. 3. Create a host scan recipe. 4. Create a host scan target that includes your instance (using a tag filter). 5. Run/trigger a scan (depending on console options and schedule). 6. Review findings and perform basic remediation (patch + network hardening). 7. Validate by re-scanning. 8. Clean up all resources.

Cost/safety: This lab can be low-cost if you use a small instance and delete everything afterward. Avoid opening broad inbound rules; restrict SSH to your IP.

Step 1: Create a dedicated compartment for the lab

Open the OCI Console.
Go to Identity & Security → Compartments.
Click Create Compartment.
Name it: vss-lab
(Optional) Add tags like: – project=vss-lab – owner=<your-name>

Expected outcome: A new compartment vss-lab appears and can be selected in the compartment picker.

Verification – Confirm the compartment exists and you can navigate into it.

Step 2: Create a compute instance (Oracle Linux) with safe networking

You need a VM to scan.

2A) Create or reuse a VCN

For a quick lab, you can use the “VCN wizard” to create a basic network. In production, you would use a more controlled network design.

Go to Networking → Virtual Cloud Networks.
Select compartment vss-lab.
Click Start VCN Wizard → choose an option like VCN with Internet Connectivity (wording may vary).
Create the VCN.

Expected outcome: A VCN with at least one public subnet exists.

2B) Create the instance

Go to Compute → Instances → Create instance.
Compartment: vss-lab
Name: vss-lab-vm1
Image: choose Oracle Linux (a commonly supported OS for OCI agent-based operations).
Shape: pick a small/low-cost shape suitable for your tenancy.
Networking: – Place it in the VCN and subnet you created. – Assign a public IPv4 address for easy SSH access (lab only).
SSH keys: – Paste your public key or generate a key pair.
Create the instance.

Expected outcome: Instance is in RUNNING state.

Verification – Open the instance details and confirm: – Public IP exists – Subnet and VCN are correct

2C) Restrict SSH exposure (important)

In the subnet’s security list or an attached NSG: – Allow inbound TCP 22 only from your public IP (CIDR /32). – Avoid 0.0.0.0/0 for SSH.

Expected outcome: SSH is reachable only from your IP.

Step 3: Verify Oracle Cloud Agent and enable the Vulnerability Scanning plugin (host agent scan)

Agent-based scanning depends on the Oracle Cloud Agent. Most Oracle-provided images include it, but confirm.

3A) SSH to the instance

From your terminal:

ssh -i /path/to/private_key opc@<PUBLIC_IP>

Expected outcome: You can log in as opc.

3B) Check Oracle Cloud Agent service

On Oracle Linux, run:

sudo systemctl status oracle-cloud-agent

Expected outcome: Service is active (running).

If it’s not running:

sudo systemctl enable --now oracle-cloud-agent
sudo systemctl status oracle-cloud-agent

If the service is missing, confirm you used an OCI image that includes the agent or follow the official Oracle Cloud Agent documentation (verify current docs for your OS/image).

3C) Enable the Vulnerability Scanning plugin (console path)

Plugin management is usually done from the instance details page:

OCI Console → Compute → Instances → vss-lab-vm1
Look for Oracle Cloud Agent tab/section.
Ensure the Vulnerability Scanning plugin is Enabled. – If you see “Management” or “Plugins,” enable the relevant Vulnerability Scanning capability.

Expected outcome: The Vulnerability Scanning plugin is enabled for the instance.

Verification – In the console, plugin shows enabled. – Wait a few minutes for status to update if needed.

If you cannot find the plugin: the UI and plugin names can vary by image and OCI updates. Verify the latest steps in the official Vulnerability Scanning documentation and the Oracle Cloud Agent documentation.

Step 4: Tag the instance for scan targeting

Using tags makes the target dynamic and prevents accidental scanning of unrelated instances.

On the instance details page, add a tag (defined tag or freeform tag).
Example freeform tag: – Key: vss-scan – Value: true

Expected outcome: Instance has the tag vss-scan=true.

Verification – Refresh instance details and confirm tags are present.

Step 5: Create a Host Scan Recipe (what to scan)

OCI Console → Security / Security, Identity, and Compliance (menu grouping varies) → Vulnerability Scanning
Navigate to Scan Recipes → Host Scan Recipes
Click Create Host Scan Recipe
Name: vss-lab-host-recipe
Configure scans (typical options): – Agent-based vulnerability scan: Enabled – Port scan: Enabled (if available as an option in the recipe)
Set severity or scan parameters if available (keep defaults for the lab).
Create.

Expected outcome: A host scan recipe exists.

Verification – Recipe appears in the Host Scan Recipes list.

If the console separates “Port scan recipe” vs “Host vulnerability recipe,” follow the UI and create the appropriate recipe types. The concept remains: a recipe defines scan behavior.

Step 6: Create a Host Scan Target (what to scan)

Vulnerability Scanning → Targets → Host Scan Targets
Click Create Host Scan Target
Name: vss-lab-host-target
Compartment: vss-lab
Recipe: select vss-lab-host-recipe
Target selection: – Choose Instances in compartment and filter by tag (preferred), if the UI supports it:
- Tag key vss-scan
- Tag value true
Schedule: – Set a schedule such as Weekly (or the smallest allowed interval for lab testing). – If “Run on demand” is available, you can use it for immediate results.

Create the target.

Expected outcome: A host scan target exists and is associated with your recipe.

Verification – Target appears in the Host Scan Targets list. – Target shows the correct compartment and recipe association.

Step 7: Run a scan and wait for results

Depending on OCI’s current UI capabilities, you may: – Trigger a scan manually (for example “Run scan now”), or – Wait until the scheduled scan runs.

Open vss-lab-host-target.
Look for an action like Start scan / Run scan (if present).
Otherwise, note the next scheduled run time.

Expected outcome: A scan execution starts and later produces results.

Verification – In Vulnerability Scanning, locate Scan Results, Reports, or the target’s “Scans” tab. – Confirm a scan transitions through states like Accepted/In progress → Succeeded/Completed (exact wording varies).

Timing note: First-time scans can take time. Wait 15–60 minutes depending on region/service load and whether the agent has fully checked in.

Step 8: Review findings (vulnerabilities and open ports)

8A) Review host vulnerability findings

In the scan results: – Look for: – Vulnerability identifiers (for example CVE-…) – Affected packages – Severity

Expected outcome: You can see a list of detected vulnerabilities (or a message indicating none found).

8B) Review port scan results

For port scan findings: – Review any detected open ports (e.g., 22 for SSH). – Confirm they match your expectations.

Expected outcome: Only intended ports are open (ideally just 22 restricted to your IP for this lab).

Verification checklist – If port scan shows unexpected ports, verify: – Running services on the instance: sudo ss -tulpn – NSG/security list rules

Step 9: Remediate one issue and re-scan

Remediation depends on what you see. Two common remediation types:

9A) Patch vulnerable packages (host vulnerabilities)

On the instance:

For Oracle Linux 8/9 (commonly uses dnf):

sudo dnf update -y
sudo reboot

After reboot:

sudo dnf updateinfo list security || true

For Oracle Linux 7 (commonly uses yum):

sudo yum update -y
sudo reboot

Expected outcome: Packages are updated and the instance reboots cleanly.

Verification – SSH back in and confirm: – System is reachable – oracle-cloud-agent is running: bash sudo systemctl status oracle-cloud-agent

9B) Reduce exposure (ports)

If you found unexpected open ports: – Stop/disable the service, or – Remove inbound rules in NSG/security list.

For example, to identify listeners:

sudo ss -tulpn

Then stop a service you don’t need (example only; choose the actual service you found):

sudo systemctl stop <service-name>
sudo systemctl disable <service-name>

Expected outcome: Unnecessary services are stopped and ports are closed.

9C) Re-scan

Trigger a new scan (or wait for the next scheduled run).

Expected outcome: Findings decrease (patched CVEs disappear; closed ports no longer show).

Validation

Use this checklist to confirm the lab succeeded:

Target and recipe exist in Vulnerability Scanning.
The instance has Oracle Cloud Agent running and Vulnerability Scanning plugin enabled.
At least one scan completed successfully.
You can view: – vulnerability findings (or a clean report) – port scan results
After remediation and re-scan: – fewer vulnerabilities, and/or – fewer exposed ports

Troubleshooting

Problem: No scan results or scan never starts

Confirm your target includes the instance:
Same region
Same compartment
Tag filter matches the instance tag
Confirm the scan schedule is active.

Problem: Agent-based scan shows errors / no host data

Verify Oracle Cloud Agent is installed and running: bash sudo systemctl status oracle-cloud-agent
Verify the Vulnerability Scanning plugin is enabled in the console.
Verify network egress from the instance to required OCI endpoints (NAT/Internet gateway or service gateway as appropriate).
Check OS support and prerequisites in official docs (supported OS list is critical).

Problem: Port scan results don’t match what you expect

Confirm what is actually listening: bash sudo ss -tulpn
Remember: port scanning visibility depends on security rules and routing. If traffic can’t reach the instance, the port may appear closed even if a service is listening internally.

Problem: Too many vulnerabilities after patching

Some vulnerabilities require specific package versions or kernel updates and may not clear until reboot.
If you use pinned repositories or custom repos, updates may not apply.
Confirm the scanner’s update cycle; results may take time to reflect changes.

Cleanup

To avoid ongoing costs:

Vulnerability Scanning: – Delete vss-lab-host-target – Delete vss-lab-host-recipe
Compute: – Terminate instance vss-lab-vm1 (choose “Delete boot volume” if you don’t need it)
Networking (if created just for the lab): – Delete the VCN (or use the VCN cleanup feature if available)
Compartment: – Delete compartment vss-lab (must be empty first)

Expected outcome: No lab resources remain; costs stop accruing.

11. Best Practices

Architecture best practices

Segment networks: keep most workloads in private subnets; minimize public IP usage.
Use NSGs for application-centric security rules; keep rules tight and intentional.
Adopt a standard compartment model (landing zone approach) so scanning scope matches ownership.

IAM/security best practices

Separate duties:
Security team manages recipes
App/platform teams manage targets for their compartments (optional model)
Use least privilege policies:
Grant manage vulnerability-scanning-family only to the teams that administer it.
Grant read-only access to results for broader audiences where appropriate.
Use instance principals for automation running on OCI compute (preferred over user API keys where possible).

Cost best practices

Don’t scan everything at maximum frequency by default.
Start with:
Internet-facing systems
Sensitive data systems
Base images used broadly
Tune schedules to match remediation capacity and patch cadence.
Clean up unused images in OCI Registry; enforce retention.

Performance best practices

Keep scanning scope manageable and consistent:
Use tag-based scoping to avoid scanning “everything” by accident.
Avoid scan storms:
Don’t schedule all compartments to scan at the exact same time if you can stagger schedules.

Reliability best practices

Treat scanning as a control with monitoring:
Track that scans happen successfully (via periodic checks or automation).
Build a remediation loop:
Define SLAs for critical/high findings.
Measure time-to-remediate.

Operations best practices

Integrate results into operational workflows:
ITSM ticket creation for critical/high findings (via API automation)
Weekly triage meetings
Maintain patch runbooks per OS and workload class.

Governance/tagging/naming best practices

Naming:
Recipes: org-<baseline>-host-recipe-v1
Targets: <team>-<env>-host-target
Tagging:
env=dev|test|prod
owner=<team>
scan=true (explicit opt-in is often safer)

12. Security Considerations

Identity and access model

Vulnerability Scanning administration is controlled via OCI IAM policies.
Use compartment boundaries to restrict who can:
create/modify recipes and targets
view findings and reports

Encryption

OCI services generally encrypt data at rest and in transit, but confirm:
How scan results are stored and protected
Whether you can control retention or export behavior
Verify details in official documentation and OCI security documentation.

Network exposure

Port scanning is about exposure; treat any unexpected open port as a potential incident.
Don’t rely on scans alone—use defense-in-depth:
NSGs/security lists
Host firewall where applicable
Bastion access for administration rather than public SSH

Secrets handling

Vulnerability Scanning does not remove the need for secrets management.
If you automate results retrieval:
Prefer instance principals or resource principals
Avoid embedding API keys in scripts
Use OCI Vault for secrets when needed

Audit/logging

Use OCI Audit to track configuration changes:
Who created/updated/deleted targets/recipes
Consider exporting relevant evidence for compliance (process-driven).

Compliance considerations

Vulnerability Scanning supports parts of vulnerability management controls, but compliance requires: – Defined scanning cadence – Documented triage and remediation process – Exceptions/risk acceptance workflow – Evidence retention and reporting

Common security mistakes

Scanning without remediation ownership (findings pile up)
Overly broad target scopes (noise and operational burden)
Leaving SSH open to the world (0.0.0.0/0) and treating “scan detects it” as sufficient
Not enabling agent/plugin correctly, resulting in false confidence (no findings because no data)

Secure deployment recommendations

Build a baseline recipe and enforce its adoption.
Use tag-based opt-in for sensitive environments at first, then expand.
Integrate vulnerability SLAs into service ownership.

13. Limitations and Gotchas

These are common real-world constraints. Confirm exact limits and supported configurations in official docs for your region and OCI release.

Known limitations (typical)

OS support limitations: agent-based scanning works only on supported OS images/versions.
Agent dependency: if the Oracle Cloud Agent plugin isn’t enabled/healthy, host vulnerability data may be missing.
Network visibility: port scan results depend on reachability; closed-by-network doesn’t always mean closed-on-host.
Container scanning scope: often centered on OCI Registry; external registry support must be verified.

Quotas and scaling constraints

Service limits on number of targets/recipes/scans per region or tenancy can apply.
Large fleets may require:
multiple targets per compartment strategy
schedule staggering
disciplined tagging

Regional constraints

Not all OCI regions necessarily support every scanning capability at the same time.

Pricing surprises

Even if the scanning service itself is low/no cost, you still pay for:
compute uptime
egress for patching and downloads
registry storage growth

Compatibility issues

Custom kernels, unusual package managers, or minimal images may reduce scan fidelity.
Instances without outbound connectivity may not report agent-based scan data.

Operational gotchas

First scan can take longer due to agent initialization.
Re-scans may not immediately reflect remediation; allow time for agent reporting and scan cycles.
“Too many findings” is an operational failure mode—start with priorities.

Migration challenges

If migrating from a third-party vulnerability management platform:
Expect differences in severity scoring, plugin coverage, and reporting formats.
You may need parallel runs for a period to calibrate.

Vendor-specific nuances (OCI)

OCI compartment/IAM model is central: mis-scoped compartments or policies are a common reason for “no data” or “no access.”
Tag governance affects target correctness.

14. Comparison with Alternatives

Vulnerability Scanning is one part of a broader security program. Here’s how it compares to adjacent tools.

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
Oracle Cloud Vulnerability Scanning	OCI-native host and container vulnerability visibility	Integrated with OCI IAM/compartments; managed; good fit for OCI fleets	Not a full vulnerability management platform; scope depends on supported OS/resources	You run workloads primarily on OCI and want managed scanning
Oracle Cloud Guard	Posture management and centralized security signals	Detects misconfigurations and risky activity (depending on configuration); integrates with OCI governance	Not a replacement for vulnerability scanning; focuses on posture/signals	You want broader cloud security posture + integrate vulnerability signals (verify integration)
OCI OS Management / patching tools	Patch deployment and lifecycle management	Helps apply updates and manage packages	Patching is not the same as scanning; doesn’t always provide vulnerability reporting like scanners	You need patch orchestration in addition to scanning
AWS Inspector	Vulnerability management for AWS workloads	Tight AWS integration; broad AWS-native coverage	AWS-specific; not OCI	Multi-account AWS environments needing managed scanning
Microsoft Defender for Cloud	Cloud security posture + vulnerability signals	Strong posture management; integrates with Azure ecosystem	Azure-centric; licensing complexity	Primarily Azure workloads and governance
Google Security Command Center / VM scanning tools	GCP posture and vulnerability insights	GCP-native signals	GCP-specific	Primarily GCP workloads
Tenable / Qualys / Rapid7	Enterprise vulnerability management across hybrid estates	Broad coverage, mature lifecycle workflows, strong reporting	Cost and operational overhead; agent deployment; integration effort	Large enterprises needing single pane across cloud + on-prem
Trivy / Grype (open source)	CI/CD container scanning and SBOM-focused workflows	Great for pipelines; fast; developer-friendly	You operate the tooling; results storage/workflows are on you	You want shift-left scanning in CI with open tooling
OpenVAS/Greenbone (self-managed)	Network scanning in self-managed environments	Flexible; can be run anywhere	Operational overhead; tuning; scaling complexity	You need self-hosted scanner control and have ops maturity

15. Real-World Example

Enterprise example (regulated industry)

Problem
A financial services company runs hundreds of OCI compute instances across multiple compartments. Auditors require evidence of periodic vulnerability scanning and timely remediation of critical findings.

Proposed architecture – Compartment model: – security compartment: standardized scan recipes, IAM policies – prod-* compartments: scan targets scoped by tags (owner/team/environment) – Recipes: – Baseline host vulnerability + port scan recipe for production – More frequent scanning recipe for internet-facing workloads – Operations: – Weekly triage of critical/high findings – Patching via OS management process (maintenance windows) – Evidence exported quarterly (reports + change records)

Why Vulnerability Scanning was chosen – OCI-native service aligned to IAM and compartment governance – Reduces tool sprawl for OCI-first workloads – Standardization via recipes/targets

Expected outcomes – Consistent vulnerability visibility across all production assets – Reduced time-to-detect and time-to-remediate – Clear audit evidence trail (scan cadence + remediation actions)

Startup/small-team example

Problem
A startup deploys a few microservices to OCI and builds container images frequently. They want a lightweight way to catch critical CVEs and avoid accidental exposure without buying a full enterprise platform.

Proposed architecture – Tag-based scan target for compute instances: scan=true – Container image scanning for images in OCI Registry – A simple “security gate” in CI: – After pushing an image, the pipeline checks scan results via API (implementation-specific; verify API endpoints) – If critical vulnerabilities are present, the pipeline fails or prevents promotion

Why Vulnerability Scanning was chosen – Managed, simple to enable, integrated with OCI – Minimal operational overhead compared to self-hosting scanners

Expected outcomes – Early detection of critical container CVEs – Reduced public exposure risk via periodic port scans – Practical security posture improvement without heavy tooling

16. FAQ

1) Is Oracle Cloud Vulnerability Scanning the same as a penetration test?
No. It identifies known vulnerabilities and exposures (like open ports). Pen testing is a broader, adversarial assessment.

2) Does Vulnerability Scanning patch my instances automatically?
No. It reports findings. You must patch/rebuild/reconfigure using your operational processes.

3) Do I need an agent for host scanning?
For agent-based host vulnerability scanning, yes—typically via the Oracle Cloud Agent plugin. Port scanning is network-based and does not require an agent.

4) Can I scan private instances in private subnets?
Often yes for agent-based scanning if the instance can reach required OCI endpoints. Port scanning depends on network reachability and rules. Verify your network design requirements in official docs.

5) How do recipes and targets differ?
A recipe defines what checks run. A target defines which resources are scanned and on what schedule.

6) Can I scan only instances with a specific tag?
Tag-based targeting is a common pattern. Confirm the exact filtering options in your region’s console/API.

7) Does it scan application vulnerabilities (OWASP Top 10) in my web app?
No. That’s typically a DAST/SAST function. Vulnerability Scanning focuses on host packages, ports, and container image contents.

8) How often should I run scans?
Align to your patch cadence and risk. Weekly is common for many orgs; more frequent for internet-facing or high-risk systems.

9) Will port scanning show ports blocked by my security rules?
If traffic can’t reach the host due to routing or security rules, a port scan may not detect the port as open, even if a service listens internally.

10) Can I export results to a SIEM?
You can typically integrate using APIs and automation. Check official docs for any native export/integration patterns.

11) How do I reduce false positives?
Keep OS packages current, use supported images, and validate findings against your actual installed package versions. Also ensure scans complete successfully.

12) Does container scanning replace scanning my running Kubernetes cluster?
No. Image scanning is important, but runtime posture (RBAC, network policies, container escape protections) requires additional controls.

13) What IAM permissions do I need?
Typically permissions to manage the vulnerability-scanning-family in the relevant compartments. Confirm exact policy statements in official docs.

14) Is Vulnerability Scanning available in all OCI regions?
Availability can vary. Check the service documentation and region support pages.

15) How do I operationalize remediation?
Common approaches: ticket creation for critical/high findings, ownership via tags, patch windows, and re-scan verification.

17. Top Online Resources to Learn Vulnerability Scanning

Resource Type	Name	Why It Is Useful
Official documentation	OCI Vulnerability Scanning documentation	Primary source for concepts, supported targets, and configuration steps: https://docs.oracle.com/en-us/iaas/scanning/home.htm
Official documentation (overview)	Overview / “Using Vulnerability Scanning”	Explains recipes, targets, scan types, and workflows (navigate from the docs home): https://docs.oracle.com/en-us/iaas/scanning/home.htm
Official API reference	OCI APIs (Vulnerability Scanning)	Automate recipes/targets and retrieve results (find the service in OCI API docs): https://docs.oracle.com/en-us/iaas/api/
Official CLI documentation	OCI CLI installation and usage	Needed for automation; confirm if Vulnerability Scanning commands are available in your CLI version: https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm
Official pricing	Oracle Cloud Price List	Authoritative pricing reference: https://www.oracle.com/cloud/price-list/
Official calculator	OCI Cost Estimator	Model compute, storage, and network costs for your scan scope: https://www.oracle.com/cloud/costestimator.html
Free tier info	Oracle Cloud Free Tier	Helps build low-cost labs: https://www.oracle.com/cloud/free/
Architecture guidance	OCI Architecture Center	Reference architectures and governance patterns that influence scanning scope: https://docs.oracle.com/en/solutions/
Security guidance	OCI Security documentation	Broader OCI security best practices (IAM, networking, logging): https://docs.oracle.com/en-us/iaas/Content/Security/home.htm
Community learning (reputable)	OCI blogs and solution articles (verify)	Can provide practical patterns; validate against official docs to avoid drift: https://blogs.oracle.com/cloud-infrastructure/

18. Training and Certification Providers

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	DevOps engineers, SREs, platform teams	DevOps, cloud operations, CI/CD, security fundamentals (verify course catalog)	Check website	https://www.devopsschool.com/
ScmGalaxy.com	Beginners to intermediate engineers	DevOps, SCM, automation, cloud basics (verify)	Check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud operations teams	Cloud ops practices, monitoring, reliability, security basics (verify)	Check website	https://www.cloudopsnow.in/
SreSchool.com	SREs, reliability engineers	SRE practices, incident response, observability, reliability engineering (verify)	Check website	https://www.sreschool.com/
AiOpsSchool.com	Ops and SRE teams	AIOps concepts, automation, monitoring analytics (verify)	Check website	https://www.aiopsschool.com/

19. Top Trainers

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	DevOps / cloud training content (verify)	Students, engineers seeking practical guidance	https://www.rajeshkumar.xyz/
devopstrainer.in	DevOps training (verify)	Beginners to working professionals	https://www.devopstrainer.in/
devopsfreelancer.com	DevOps consulting/training resources (verify)	Teams needing hands-on assistance	https://www.devopsfreelancer.com/
devopssupport.in	DevOps support and training resources (verify)	Ops teams needing troubleshooting help	https://www.devopssupport.in/

20. Top Consulting Companies

Company	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	DevOps / cloud consulting (verify)	Cloud migrations, CI/CD, platform engineering	Designing OCI landing zones; integrating scanning results into ops workflows	https://cotocus.com/
DevOpsSchool.com	DevOps consulting and enablement (verify)	DevOps transformation, toolchain implementation	Building vulnerability scanning operational process; CI/CD integration patterns	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting (verify)	DevOps automation, cloud operations	Standardizing patch and vulnerability remediation runbooks	https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before this service

To use Oracle Cloud Vulnerability Scanning effectively, learn: – OCI fundamentals: tenancies, compartments, regions, availability domains – Networking: VCNs, subnets, route tables, NSGs, security lists – IAM: groups, policies, least privilege – Linux administration: – package managers (dnf, yum) – services (systemctl) – firewall basics (iptables/firewalld depending on OS) – Container basics (if scanning images): Dockerfile, base images, image tags, registries

What to learn after this service

Patch orchestration:
OCI OS management capabilities (verify current product naming and features)
Posture management:
OCI Cloud Guard concepts and how to operationalize alerts (verify integrations)
DevSecOps practices:
CI/CD security gates using image scanning results
SBOM generation and dependency management
Observability:
Logging, monitoring, alerting
Incident response playbooks and threat modeling

Job roles that use it

Cloud Security Engineer
DevSecOps Engineer
Site Reliability Engineer (SRE)
Platform Engineer
Cloud Operations Engineer
Security Analyst (triage and reporting)
Solutions Architect (design governance patterns)

Certification path (if available)

Oracle’s certification offerings change. For OCI-aligned learning: – Start with OCI foundations certifications (verify current names on Oracle University). – Then pursue security-focused OCI training paths.

Verify current Oracle certification tracks: https://education.oracle.com/

Project ideas for practice

Tag-governed scanning: enforce scan=true for all production compute via policy/process.
Automated reporting: nightly script that queries scan results and posts summaries to chat/email (use OCI APIs securely).
Container promotion gate: promote images only if scan results meet a policy (e.g., no critical CVEs).
Exposure drift detection: weekly port scan + compare against approved port list.
Compliance evidence pack: quarterly export of scan cadence, findings, remediation SLAs.

22. Glossary

OCI (Oracle Cloud Infrastructure): Oracle Cloud’s infrastructure platform (compute, networking, storage, and cloud services).
Security, Identity, and Compliance: OCI category that includes security and governance services such as IAM and Vulnerability Scanning.
Vulnerability Scanning: OCI service that detects vulnerabilities in hosts and container images and identifies open ports (capabilities depend on configuration).
Compartment: OCI logical container used to organize and isolate resources with IAM policies.
Recipe (Scan Recipe): Configuration that defines scan behavior (what checks to run, parameters, schedule options).
Target (Scan Target): Defines which resources are scanned (instances/images), usually in a compartment and optionally filtered by tags.
CVE: Common Vulnerabilities and Exposures identifier (e.g., CVE-2024-xxxx).
CVSS: Common Vulnerability Scoring System; a standardized severity scoring framework.
Agent-based scan: Scan mode that relies on an installed agent (Oracle Cloud Agent plugin) to collect vulnerability data from the host.
Port scan: Network-based scan to identify open ports/services.
OCIR (OCI Registry): Oracle Cloud Infrastructure Registry for storing container images (name/branding may appear as “OCI Registry” in console).
VCN: Virtual Cloud Network in OCI.
NSG: Network Security Group; a virtual firewall applied to VNICs for fine-grained traffic control.
Security List: Subnet-level virtual firewall rules.
Service Gateway / NAT Gateway: OCI networking constructs used to route outbound traffic privately to OCI services or to the internet.
Audit: OCI service that records API calls for governance and forensics.

23. Summary

Oracle Cloud Vulnerability Scanning is an OCI-native service in the Security, Identity, and Compliance category that helps you continuously identify vulnerabilities in compute instances and container images, and detect risky network exposure through port scanning. It fits best in OCI environments that want managed scanning aligned with OCI compartments, IAM policies, and operational governance.

Key takeaways: – Use recipes to standardize scan behavior and targets to control scope using compartments and tags. – Treat scanning as part of a remediation lifecycle: scan → triage → fix → re-scan. – Costs depend primarily on underlying OCI resources (compute, storage, network); verify whether the scanning service itself is separately billed using the official price list and estimator. – Secure and successful scanning depends on correct IAM, correct agent/plugin enablement for host scanning, and intentional network design for meaningful port-scan results.

Next step: read the official docs end-to-end, then operationalize scanning with a production baseline recipe, tag-based targeting, and a remediation SLA process: https://docs.oracle.com/en-us/iaas/scanning/home.htm

rajeshkumar

Category