Skip to main content

Dashboards

Cloudaware analytics dashboards provide always‑on visibility into vulnerability exposure, coverage, and remediation progress.

Use this guide to review key dashboard use cases, recommended widgets, and example dashboards for Vulnerability Management in Cloudaware.

Use Cases

Executive Overview

  • Audience: CISOs, security leadership, senior IT leaders.
  • Key widgets:
    • Total open vulnerabilities by risk band (Critical/High/Medium/Low).
    • Trend of open vs remediated vulnerabilities over time.
    • Top OUs or applications by outstanding risk.
    • SLA compliance by risk band and environment.
  • Purpose:
    • Show whether overall risk is trending up or down.
    • Highlight which parts of the organization need help.

Coverage & Hygiene

  • Audience: SecOps, platform teams.
  • Key widgets:
    • Assets with no scan in the last N days.
    • Assets with stale findings (e.g., old scan dates).
    • Scan frequency by asset type or source (VSaaS vs cloud‑native vs third‑party).
  • Purpose:
    • Identify gaps in scanner deployment or configuration.
    • Ensure that critical systems are regularly assessed.

Remediation Performance

  • Audience: Application and platform owners, SecOps.
  • Key widgets:
    • Mean/median time to remediate (MTTR) by risk band.
    • Number of vulnerabilities past SLA by OU or application.
    • Remediation Tasks by status (New, In Progress, Waiting on Change, Resolved, Verified).
    • Top recurring CVEs or misconfigurations.
  • Purpose:
    • Track how quickly teams are closing issues.
    • Identify systemic problems (e.g., recurring patch failures).

Exceptions & Governance

  • Audience: Risk, compliance, security leadership.
  • Key widgets:
    • Active exceptions by OU, application, and risk band.
    • Expiring exceptions in the next 30/60/90 days.
    • Total risk “under exception” compared with unsuppressed backlog.
  • Purpose:
    • Ensure that exceptions are temporary and justified.
    • Plan review cycles with OUs and app owners.

Build Dashboards in Cloudaware

Implementation tips:

  • Base components on the normalized data model (Vulnerability Scan records, Remediation Tasks, Exceptions).
  • Use filters for environment, OU, application, and source.
  • Provide drill‑down paths from high‑level tiles into detailed list views.

Here are examples of dashboards that Cloudaware provides on request:

Vulnerability Scans with SLAs Dashboard

The dashboard shows the overall security exposure, scan coverage, remediation posture, and historical vulnerability trends across cloud services. It gives users both an executive summary of current risk and a drill-down view into where vulnerabilities exist, how long they have been open, and whether remediation is keeping pace with policy expectations.

Vulnerability Scans with SLAs Dashboard

The top section is a filter bar that lets users slice the data by vulnerability type, account or subscription, service state, vulnerability name, first found date, tags, scanned service type, service ID, platform, risk, last scan date, and AWS Inspector status reason. That makes the dashboard usable across multiple teams and infrastructure segments rather than as a single global view.

The main visual panels show:

  • Cross-Cloud Scan Coverage: A bar chart shows scanned versus not scanned resources by service type. This helps identify scan coverage gaps across different cloud services and platforms.
  • Vulnerability Scans by Risk: A donut chart shows the overall distribution of vulnerability findings across critical, high, medium, low, and unclassified risk levels.
  • Scans Results by Application: A ranked bar chart shows which applications have the largest concentrations of vulnerability findings, broken down by risk. This helps identify applications contributing most to overall exposure.
  • Vulnerabilities by Image ID: A ranked bar chart shows which images carry the most vulnerabilities and how those findings are distributed by risk. This helps identify whether vulnerability exposure is concentrated in a small number of images.
  • Average Vulnerability Age: A summary metric shows the average age of vulnerability findings in days.
  • Vulnerabilities First Found: A historical chart shows when vulnerabilities were first detected, broken down by risk. This helps users distinguish newer findings from vulnerabilities that have remained open for longer periods.
  • Most Vulnerable Services: A ranked bar chart shows the services with the highest concentrations of critical and high findings. This makes it easier to prioritize individual services with the greatest exposure.
  • Top 10 Critical Vulnerabilities: A donut chart shows the critical vulnerabilities contributing the largest number of findings. This highlights which vulnerabilities are driving critical exposure.

The bottom section is the SLA framing for remediation:

  • Critical — SLA: 30 days
  • High — SLA: 60 days
  • Medium — SLA: 90 days
  • Low — SLA: 180 days

For each risk level, vulnerabilities are grouped by age to show how many findings remain within the remediation SLA and how many have exceeded it.

For users, the value is in the following areas:

  1. Visibility into vulnerability exposure. Users can see the volume of vulnerability findings, where they are concentrated, which applications and services carry the most exposure, and which critical vulnerabilities contribute most to overall risk.
  2. Scan coverage awareness. The dashboard shows which cloud services are actively scanned versus not scanned, which helps users identify security blind spots and coverage gaps across different resource types.
  3. Risk-based prioritization. By highlighting the most vulnerable applications, images, and services, as well as the top critical vulnerabilities, the dashboard helps teams focus remediation where it will reduce risk fastest.
  4. SLA tracking and accountability. The severity-based SLA sections show how vulnerability age compares with remediation targets, making it clear which findings are within SLA and which require attention.
  5. Historical exposure tracking. The first-found trend and average vulnerability age help users understand whether the vulnerability backlog consists mainly of recent findings or long-standing unresolved issues.
  6. Targeted investigation and action. Filters by account or subscription, service, platform, application, environment, risk, and scan dates let users isolate problem areas, investigate specific resource groups, and drive focused remediation efforts.

Vulnerability Management (Remediation Initiatives & Tasks) Dashboard

This vulnerability management dashboard focuses on vulnerabilities that are already mapped to remediation tasks or broader remediation initiatives, so users can see how much of the open exposure is actually being managed through an action plan.

Vulnerability Management (Remediation Initiatives & Tasks) Dashboard

The filters let users slice data by cloud provider, host, AWS account, risk, product, server type, environment, OS/package, remediation initiative, remediation task, and task validity, so both central teams and service owners can inspect their own scope.

At the top, the dashboard shows coverage and effectiveness metrics:

  • Vulnerabilities covered by Tasks and Initiatives
  • Vulnerabilities with invalid Tasks or no Initiative
  • MTTR or average remediation time in days

It also shows how vulnerabilities are distributed between valid and invalid remediation tasks, and highlights vulnerabilities sitting under invalid remediation tasks, which points to process breakdowns or stale assignments.

The lower section gives more operational detail:

  • Vulnerabilities covered by initiatives with a donut showing how much exposure is tied to major initiatives versus uncategorized work
  • A coverage gauge showing the share of open vulnerabilities that are under tasks or initiatives
  • Top vulnerability groups currently under initiatives or valid tasks
  • Valid remediation tasks (Jira tickets) ranked by volume
  • Vulnerability distribution by AWS account
  • Runtime vulnerability images by account, split by whether the linked remediation task is valid
  • A historical trend of vulnerabilities closed by Jira issues over time

For users, the value is the following:

  1. Visibility into remediation coverage. Users can see how much of the vulnerability backlog is actually attached to a remediation task or initiative versus left unmanaged.
  2. Validation of remediation quality. By separating valid and invalid remediation tasks, the dashboard helps users spot weak task hygiene, broken Jira linkage, or vulnerabilities that appear assigned but are not truly under active remediation.
  3. Initiative-level program tracking. Users can measure whether large remediation campaigns, such as platform upgrades or package refreshes, are absorbing meaningful portions of the exposure.
  4. Prioritization by impact. The dashboard shows which vulnerability groups, accounts, images, and tasks represent the largest concentrations of risk, helping teams focus on the work that reduces exposure fastest.
  5. Operational performance monitoring. With MTTR and historical closure trends, users can evaluate whether remediation is improving over time and whether Jira-driven work is actually closing vulnerabilities.
  6. Gap identification and governance. The view of unassigned vulnerabilities, invalid tasks, and missing product or environment tags helps users find process gaps that prevent effective ownership and remediation tracking.

Remediation Tasks and Vulnerabilities Exceptions Dashboard

This vulnerability management dashboard combines two related workflows: remediation task management and vulnerability exception tracking.

Remediation Tasks and Vulnerabilities Exceptions Dashboard

The filters at the top let users narrow the view by organizational unit, CVE, risk, Jira issue, and task created date, which makes the dashboard useful for both central security teams and local owners.

On the Remediation Tasks side, it gives users a view of the remediation backlog and execution status:

  • Total remediation-related records
  • Past due tasks
  • Opened vs. closed tasks
  • Tasks grouped by risk
  • Tasks grouped by Jira status such as backlog, to do, blocked, or done
  • Tasks by organizational unit
  • Detailed task records with Jira key, status, due date, and number of related CVEs

It also includes ranked charts showing which remediation tasks are associated with the largest numbers of vulnerabilities, so users can see where the biggest remediation work items sit.

On the Vulnerability Exceptions side, it shows the exception inventory:

  • Total exceptions
  • Active vs. expired exceptions
  • Count of vulnerabilities covered by each exception
  • Exceptions by organizational unit
  • A detailed table with exception ID, expiration date, CVE, and vulnerability counts

For users, the value is the following:

  1. Visibility into remediation execution. Users can see whether vulnerabilities are actually being turned into tracked remediation tasks, how large the open backlog is, and how much work is overdue.
  2. Workflow and ticketing oversight. By showing Jira issue status alongside remediation tasks, the dashboard helps users understand whether work is still in backlog, actively in progress, blocked, or completed.
  3. Prioritization of the biggest remediation items. Users can identify which tasks are tied to the highest numbers of vulnerabilities and which organizational units carry the heaviest load, so effort can be focused where it has the most impact.
  4. Exception governance. The dashboard provides a clear view of vulnerability exceptions, including whether they are active or expired, which is important for preventing temporary risk acceptances from becoming unmanaged long-term exposure.
  5. Accountability and audit readiness. Because tasks, owners, dates, statuses, and exception records are all visible in one place, the dashboard supports follow-up, management reporting, and evidence for governance or audit reviews.
  6. Decision support for risk treatment. By combining remediation tasks and vulnerability exceptions, the dashboard helps users distinguish between findings being fixed versus findings being formally accepted, deferred, or exempted.

See also: