Attack Surface Dashboard – Overview
Scan Status Banner
At the very top of the Attack Surface Dashboard, you’ll find a Scan Status Banner a visual indicator that reflects the current progress and health of your most recent scan. This banner ensures that users are always aware of whether the system’s data is fresh, in progress, or pending completion.
There are three primary scan statuses, each indicating a specific stage in the scanning lifecycle:
Isn’t Complete
Meaning: A scan was started but has not been completed either because it was manually stopped, interrupted, or timed out before finishing.
What happens ⟶ The dashboard may be showing partial results. A call-to-action prompt appears (e.g., “Rescan” button).
Why it matters ⟶ Partial scans can lead to incomplete asset visibility or missed vulnerabilities. It’s important to resume or restart to get full coverage.
In Progress
Meaning: A scan is actively running and gathering data from the attack surface.
What happens ⟶ The system is probing domains, subdomains, services, IPs, and technologies. You may see loading states or dynamic counters (e.g., “Collecting Ports”, “Scanning Vulnerabilities”).
Why it matters ⟶ This state means that new data is on the way. You should wait for completion before making critical exposure decisions. Some modules may update live, while others wait for the scan to finish.
Completed
Meaning: The scan has successfully finished and all discovered assets, vulnerabilities, and metadata are fully updated in the dashboard.
What happens ⟶ Results are now visible across all relevant widgets (e.g., Domains, Ports, IPs, Vulnerabilities). You can take action: prioritize, export, assign, or rescan specific findings.
Why it matters ⟶ This status confirms that your data is fresh and represents the current state of your external exposure.
Rescan Button
Located at the top-right corner of the Attack Surface Dashboard, the Rescan button allows you to manually initiate a new scan on demand. allows you to a comprehensive scan of all discovered assets domains and subdomains.
This is useful when:
⚙️ You've applied remediations (e.g., fixed misconfigurations or vulnerabilities).
➕ You’ve added new assets or DNS records.
🔄 You simply want to refresh the exposure status for accuracy.
How It Works
⟶ Clicking Rescan immediately starts a new scan session.
⟶ The dashboard updates the Scan Status Banner to "In Progress".
⟶ Once finished, the status changes to "Completed", and the results are refreshed.
⟶ Old issues are either confirmed, or closed depending on the latest findings.
Example Scenario
You previously had a warning for an Expired SSL Certificate on: mail.example.com
After your infrastructure team renews the certificate:
You click Rescan.
The system performs a fresh check on all relevant services.
The expired SSL issue is no longer detected.
The dashboard now reflects updated status: the issue is either Closed or still.
Example Use Case:
Suppose your team fixed an Expired SSL Certificate on mail.example.com. The dashboard still shows it as an active issue. To verify, you click the Rescan button. The system runs a new scan, and once it’s Completed, the issue disappears or moves into the proper status (e.g., Closed under Status).
Alternatively:
If you’re only focused on that one subdomain, you can scroll to the Subdomains tab, locate mail.example.com, and click the Rescan icon directly beside it without triggering a full scan.
Targeted Rescans for Faster Validation
While the global Rescan covers everything, you may not always need to re-scan the entire surface. In the Subdomains tab (we covered later at Subdomain Card), each subdomain is listed individually with a dedicated Rescan button beside it.
AttackMetricx empowers security teams with the ability to trigger on-demand rescans for one or multiple specific subdomains such as api.example.com, mail.example.com, and others without the need to initiate a full organizational scan. This level of granular control is especially valuable during remediation workflows, as it allows teams to validate fixes precisely where they were applied, and reduce costs. By focusing only on the assets that matter most at a given moment, teams can ensure faster verification, minimize unnecessary scan overhead, and maintain agility in responding to security events.
Manual Override with 'Mark as Resolved'
If you don’t want to wait for the rescan, or if the fix was applied outside the system’s normal detection range, you can manually click Mark as Resolved In the Attack Surface Dashboard tab at Threat Exposures Severity (we covered later at Resolved) .
Attack Surface Rating
The Attack Surface Rating is a dynamic gauge (0–100%) that reflects your organization’s overall external security posture.
It continuously updates as new assets are discovered, exposures are identified, and remediation efforts are validated through rescans.
What it shows:
A higher percentage means a healthier, more secure attack surface.
A drop in the rating highlights newly found exposures or unresolved issues.
Why it matters:
Gives executives and security teams a quick, high-level snapshot of the organization’s external risk posture.
Allows teams to track progress after remediation activities.
Provides context when comparing posture before and after major changes such as migrating to a new WAF, deploying additional protections, or moving infrastructure to a different cloud provider.
Example Use Case:
Cystack applies security patches across its subdomains. Before remediation, the Attack Surface Rating sits at 68%, showing multiple high-severity vulnerabilities.
After applying the fixes and running a Rescan, the rating climbs, giving both the IT team and management clear evidence that the security posture has significantly improved.
In the top-right corner of the Attack Surface Rating widget, you’ll notice a calendar icon. Clicking this icon opens the Attack Surface Calendar, a strategic visualization that continuously tracks the evolution of your organization’s external attack surface posture over time.
This feature enables cybersecurity and IT teams to analyze surface exposure trends, identify posture deviations, and measure resilience improvements across multiple timeframes daily, monthly, and yearly.
Daily View: Displays daily attack surface scores and domain-level posture, reflecting short-term exposure changes and real-time risk behavior.
Monthly View: Aggregates exposure and security posture data to show month-over-month progression, helping detect sustained risk trends or improvements.
Yearly View: Offers a macro-level assessment of attack surface resilience, allowing leadership to evaluate long-term performance and exposure reduction success.
At the top of the calendar, users can filter data by specific domains (e.g., example.com, network.org) to focus on targeted environments or subsidiaries.
Within each calendar entry, the system displays a letter-grade rating (A–F) and the corresponding percentage score (e.g., C – 76%) alongside the number of domains analyzed. This allows teams to quickly assess when and where posture declined, correlate it with detected exposures, and prioritize mitigation efforts based on historical trends.
The Attack Surface Rating component of AttackMetricx is more than just a visualization it’s an intelligence-driven indicator of external exposure resilience, enabling proactive defense and continuous posture optimization.
Threat Exposures Severity
The Threat Exposures Severity section categorizes all discovered issues based on how dangerous they are and how urgently they should be addressed. It ensures teams don’t waste time on noise but focus first on exposures that attackers are actively using.
Levels of Severity
1. Known Exploited
These are vulnerabilities or misconfigurations that are actively exploited in the wild (e.g., listed in the CISA KEV catalog).
They represent the highest priority because attackers are already using them for real-world breaches.
Example: A WebLogic CVE that allows remote code execution.
2. Critical
Severe exposures that could cause catastrophic impact if exploited, such as full system compromise, credential leaks, or unauthenticated RCE.
Even if not yet exploited in the wild, their technical impact makes them urgent.
Example: A critical SQL injection on a production database.
3. High
Exposures with significant risk but usually require more conditions to be exploited (e.g., partial authentication, chaining with another bug).
They can still cause downtime or sensitive data exposure.
Example: An open admin panel with weak authentication.
4. Medium
Issues that pose moderate risk and are less likely to be exploited immediately but can still expand the attack surface.
Often configuration weaknesses or outdated libraries.
Example: TLS misconfigurations, missing HTTP security headers.
5. Low
Minor findings that rarely result in direct compromise but help attackers in reconnaissance.
They are useful for understanding the environment and can be stepping stones for larger attacks.
Example: Banner disclosures, verbose error messages.
6. Informational
Not vulnerabilities by themselves, but contextual data that enriches the attack surface view.
Helps security teams understand what technologies, services, or assets are exposed.
Example: Technology stack detection (Cloudflare, Apache, WordPress).
Threat Exposures Found (Detailed View)
When you click View All from the Threat Exposures Severity widget, the system opens a dedicated page called Threat Exposures Found. This page provides a detailed breakdown of all identified exposures, with filters on the left sidebar and utilities on the top bar.
Let’s start by exploring the filters available in the left-hand sidebar, as they provide essential ways to narrow down and manage the data displayed on the dashboard.
Status
Filters exposures based on whether they are still present in the latest scan or have been resolved:
Open: Exposures still detected in the current scan and need remediation.
Closed: Exposures that were previously detected but are now gone usually because they were resolved.
Use Case: An SSL vulnerability on port 443 is patched. After the next scan, it no longer appears and moves from "Open" to "Closed".
Viewed
Tracks whether your team has reviewed a specific issue:
Viewed: Someone from your team has opened the issue.
Not Viewed: The issue has not yet been opened or reviewed.
Use Case: An analyst opens a "Mismatched SSL Certificate" finding. It’s automatically flagged as "Viewed".
Resolved
This filter lets teams track manual remediation steps:
Resolved: The issue was manually marked as resolved by an analyst.
Not Resolved: No manual action has been taken to mark this issue.
Clarification: Unlike "Closed", this is a manual status and doesn't depend on scan results.
Use Case: A weak TLS configuration is fixed, and the analyst clicks "Resolve". Even if the issue still exists, the platform keeps it under "Resolved".
Auditability: Every manual resolution action is attributed to the specific user who performed it, ensuring full accountability and traceability across the platform.
Categories
Groups exposures into logical types:
Vulnerabilities: Software/configuration flaws with CVEs.
Certificates: Issues related to SSL/TLS (e.g., expired, mismatched).
Risky Ports: Insecure or exposed ports.
DNS: Problems in DNS records like inactive subdomains.
Use Case: An expired certificate on mail.example.com falls under "Certificates".
Severity
Lets users filter exposures by risk level:
Known Exploited
Critical
High
Medium
Low
Informational
These severity levels will be covered in more detail later.
Use Cases:
Critical: Remote Code Execution with no patch.
Medium: Missing HSTS header.
Informational: Apache version disclosure.
Validation
Validation in AttackMetricx defines how each exposure is classified and verified. Unlike other platforms that rely solely on OSINT or passive feeds, AttackMetricx performs its own active validation using a custom-built scanning and exploitation engine. This engine is continuously updated with new techniques, templates, and exploit modules, meaning we don’t depend on external or generic tools.
Confirmed
A status of Confirmed means the AttackMetricx engine directly validated the exposure by actively simulating or interacting with the target system in real time.
This covers not only misconfigurations but also serious, exploitable vulnerabilities. Examples include:
SQL Injection (SQLi): The system runs crafted payloads against parameters to validate whether injection is possible and exploitable.
Cross-Site Scripting (XSS): AttackMetricx injects test scripts and analyzes responses to confirm script execution.
Remote Code Execution (RCE): Where possible, safe proof-of-concept exploitation is attempted to validate that arbitrary code execution is achievable.
SSL/TLS Validation: A live SSL handshake is performed to confirm expired, mismatched, or revoked certificates.
Open Ports: The system actively connects to verify services on ports like
2087or443are live and responsive.Security Headers: HTTP(S) requests are sent directly, and responses are analyzed to confirm missing headers such as HSTS, CSP, or X-Frame-Options.
In AttackMetricx is that confirmation is powered by custom-built templates, payloads, and exploit modules developed by our team. Our scanning engine is fully customized, continuously updated with new exploitation logic and tailored checks, rather than relying on generic, off-the-shelf scanners. This ensures findings in Confirmed are highly accurate, deeply validated, and immediately actionable.
Potential
A status of Potential means the system suspects an exposure but cannot fully validate it automatically. These cases are flagged for further analyst review.
Dormant Subdomains: If
dev.example.comdoesn’t respond, it may be abandoned, but AttackMetricx cannot confirm whether it’s intentionally inactive.Dangling CNAMEs: A CNAME may point to a cloud service with no resource bound. Unless a live takeover is detected, it stays Potential.
Technology & Version Mapping: AttackMetricx analyzes the technologies and versions in use (e.g., WordPress 6.x, Apache 2.4.x). If one of them is linked to a known CVE but no exploitation attempt has been validated yet, it is marked as Potential. This gives teams early warning before an issue becomes critical.
Potential findings are still valuable because they highlight areas where manual investigation or threat intelligence correlation is required. AttackMetricx enriches these with feeds like CISA KEV and EPSS probabilities, so analysts can prioritize even suspected risks.
Subdomains
Breaks down exposures per subdomain, helping assign responsibility:
Example:
mail.example.com→ 2 issuesenterpriseenrollment.example.com→ 6 issues
Use Case: You want to view exposures only on webdisk.example.com. Selecting it in the filter updates the list accordingly.
Top Bar Tools
The top section of the Threat Exposures Found page includes multiple controls to refine the display or export of exposure data.
First Seen & Last Seen
Dropdown filters to control timeframe:
First Seen: Filters by discovery date.
Last Seen: Filters by latest detection date.
Use Case: You want to view issues discovered in the last month but still active last week.
Show Entries
Controls how many exposures appear per page (e.g., 10, 20, 50, 100).
Use Case: Reviewing 200 exposures is easier by setting 100 per page.
Group By Issue
Combines identical exposures across assets:
✅ Checked: Groups by exposure type.
❌ Unchecked: Each instance shown individually.
Use Case: If 5 subdomains are affected by the same CVE, checking this shows just one record.
Mark All As
Bulk update exposure statuses:
Viewed / Unviewed
Resolved / Unresolved
Use Case: After reviewing all entries, mark them all as "Viewed" at once.
View Mode
Toggles between:
List View: Detailed rows (default).
Grid View: Card-style overview.
Use Case: Use Grid for quick scanning, List for deeper analysis.
Search
Live search by subdomain, CVE ID, or exposure type.
Use Case: Typing example.com filters all related entries.
Export
Download all exposure data as a CSV file.
Use Case: You want to share exposure data with management via Excel.
Main Section – Exposure Cards
Now, let’s explore the central content area of the Threat Exposures page the Exposure Cards.
The central area of the Threat Exposures page is composed of Exposure Cards, each representing a single, identifiable issue discovered during the attack surface analysis. These cards provide a concise summary of the threat, its attributes.
Exposure Title
The title at the top of the card summarizes the issue type and the affected asset. It tells the analyst what the problem is and where it was found.
Example: “Potential Subdomain (app.example.com) Inactive” → here the system reports that the subdomain exists but appears inactive, which could create risks if left unmanaged.
Exposure Categories
Exposure Categories classify the type of issue the system has detected. Instead of mixing all findings together, AttackMetricx organizes them into categories so analysts can immediately understand the nature of the risk and address it efficiently.
The main categories are:
Vulnerabilities
Weaknesses in applications, frameworks, or technologies that attackers could exploit.
Example: A detected WordPress plugin vulnerability affecting
blog.example.com.
Certificates
Issues with SSL/TLS certificates such as expiration, misconfiguration, or weak encryption.
Example: An expired SSL certificate on
secure.example.com.
Risky Ports
Open or exposed ports that should not normally be accessible from the internet, increasing the attack surface.
Example: Port 21 (FTP) or 23 (Telnet) exposed on
vpn.example.com.
DNS
Misconfigurations or inactive records that could lead to hijacking, takeover risks, or unintended exposures.
Example: An inactive subdomain like
old.example.comstill pointing to DNS records without active content.
Exposure Severity
Indicates the risk level of the exposure, helping prioritize response. The scale typically includes:
Critical or Known Exploited → requires immediate action.
High → significant risk that could be exploited soon.
Medium → moderate exposure, should be addressed in normal remediation cycles.
Low → low likelihood of exploitation, but still relevant.
Informational → non-critical, for awareness or hygiene tracking.
Example: A subdomain flagged as “Inactive” might appear with a Low severity tag. On the other hand, a known exploited vulnerability (like a CVE being weaponized in the wild) would be marked as Critical or Known Exploited.
Validation Status
Indicates how the system validated the exposure. This is where AttackMetricx shows if an issue has been technically confirmed from our system or still requires manual verification.
Our system uses active checks, validations, HTTP responses, and service fingerprints to automatically confirm many exposures.
Confirmed: Verified directly by the system (high confidence).
Potential: The system suspects an issue but cannot fully confirm without manual analysis.
Example:
A remote code execution vulnerability (RCE) CVE-2020-14883 detected on
weblogic.example.comand actively validated by AttackMetricx → Confirmed.An inactive subdomain
test.example.comthat doesn’t respond to scans → Potential.
Resolution Status
Shows whether the exposure is still active or has been fixed. This helps teams track remediation progress and ensure vulnerabilities are not forgotten.
Resolved: The issue is no longer detected after a rescan.
Not Resolved: The issue is still present and requires action.
Example:
vpn.example.comhad port 21 (FTP) open. After closing the port and rescanning → status becomes Resolved.api.example.comwith a missing CSP header still appears after rescans → Not Resolved.
Exposure Description
A detailed explanation of the detected issue. It clarifies why the exposure is important, what risk it carries, and how attackers might exploit it.
For dev.example.com, the description may read:
“The subdomain appears inactive. Forgotten subdomains may lead to hijacking or unintended exposure if an attacker takes control of the underlying service.” Example:
Suppose dev.example.com was once used for testing but is now abandoned. If the underlying hosting service (like AWS S3, Azure App Service, or GitHub Pages) is released, an attacker could re-register the service and hijack the subdomain. This allows them to host malicious content (like a phishing site) under dev.example.com, which appears legitimate to users and could bypass security filters.
Metadata
Additional contextual details that help analysts investigate faster. Metadata typically includes:
Last Seen – When the issue was last detected.
First Seen – When the system first discovered it.
Subdomain/Domain – Exact location of the issue.
Example:
old.example.comwas first seen 1 year ago, last seen 2 months ago.
Action Buttons
These are quick-action buttons that allow analysts to manage and interact with exposures directly from the dashboard, without needing to navigate away.
Buttons:
Open in New Tab
Opens the exposure in a new browser tab.
Provides the same detailed view you would see if you clicked Tap to Show Details (explained later).
Useful if you want to keep the main list open while analyzing a specific exposure in parallel.
Mark as Resolved
Sets the exposure state to Resolved.
This is a manual action that signals your team has fixed or acknowledged the issue.
Example: After your IT team patches a vulnerable library, the analyst clicks Mark as Resolved to reflect this in the system.
Add Notes
Lets you attach comments or investigation details to the exposure.
Helps maintain context for future reviews or for other team members.
Example: “Patch applied on 2025-03-20, pending validation in next scan.”
Tap to Show Details
When you click Tap to Show Details, the platform expands the exposure card into a full detailed view. This mode provides a deep technical breakdown of the exposure, consolidating all relevant metadata, validation context.
It includes everything already explained (Title, Category, Severity, Validation, Resolution, Description, Metadata), plus extra insights such as: Tags – labels and metadata that classify the exposure (e.g., cve, kev, rce, weblogic). Tags link the finding to official vulnerability IDs, vendor references, or known exploit sources.
More Details: Deep Technical Intelligence Behind Every Exposure
Advanced tabs like Collection Indicators, HTTP Request/Response, CURL Command, and PoC, providing technical evidence and validation. This feature highlights how AttackMetricx enriches each exposure with deeper intelligence, making it faster to analyze and act.
More Details Tab
Collection Indicators
Displays forensic indicators collected during the scan.
These can include suspicious payload traces, error patterns, or behavioral markers tied to the exposure.
If empty, it means no additional IoCs (Indicators of Compromise) were extracted.
Useful for SOC analysts to validate findings against threat intel feeds.
HTTP Request
Shows the exact HTTP request our system used to validate the exposure.
Provides transparency into how the scanner interacted with the target.
Helps reproduce the finding or validate it independently.
Example: POST/GET payloads with headers and parameters.
HTTP Response
Displays the raw server response to our validation request.
Allows analysts to confirm the vulnerability behavior.
Example: Response headers, cookies, session IDs, or error messages confirming exploitability.
CURL Command
Provides a ready-to-use CURL command that replicates the same request.
Useful for analysts who want to manually re-test the vulnerability in their own environment.
Ensures reproducibility outside the platform.
PoC (Proof of Concept)
Highlights the exact match location or pattern that triggered the detection.
Example: Specific URLs, endpoints, or parameters.
Strengthens confidence in the finding by showing where and how it was validated.
CVSS Scores & Metrics
AttackMetricx doesn’t only show a static CVSS number it delivers a multi-dimensional scoring framework. This includes both official CVSS standards (v3.1 and v2.0) and our own enhanced exploitability and impact gauges, ensuring every vulnerability is understood not just in theory but in real-world context.
Custom Exploitability & Impact Gauges
Beyond the base CVSS scoring, AttackMetricx provides:
Exploitability Score – how realistic and technically feasible it is for attackers to exploit this vulnerability in current conditions.
Impact Score – the expected damage or disruption if the vulnerability is successfully exploited, measured in terms of confidentiality, integrity, and availability.
These gauges allow analysts to move past abstract numbers and see the practical threat level.
CVSS v3.1
AttackMetricx integrates CVSS v3.1, the most widely used and up-to-date scoring framework. It provides a refined model with:
Detailed base metrics that define exploitability and impact.
Temporal metrics that can adjust severity as new information (like exploits in the wild) emerges.
Environmental metrics that adapt scores to reflect the importance of the affected system in your specific environment.
This ensures vulnerabilities are assessed in a way that aligns with modern security operations.
Below are the details of CVSS v3.1:
Attack Vector: Defines how an attacker can reach the vulnerable component (e.g., locally, adjacent network, or remotely).
Attack Complexity: Measures the difficulty of exploitation whether it requires special conditions or can be done easily.
Privileges Required: Indicates the level of access rights the attacker needs before launching the exploit.
User Interaction: Whether the vulnerability requires a user to perform an action, such as opening a file or clicking a link.
Scope: Assesses if exploiting the vulnerability can affect other components beyond the vulnerable one.
Confidentiality Impact: The degree to which data confidentiality is compromised.
Integrity Impact: The degree to which data or system integrity could be altered.
Availability Impact: The degree to which system uptime or availability is affected.
Obtain All Privilege: Whether full administrative control could be obtained.
Obtain User Privilege: Whether normal user-level privileges could be obtained.
CVSS v2.0
For compatibility with legacy systems and older advisories, AttackMetricx also supports CVSS v2.0 scoring. While less granular than v3.1, it remains relevant in many industry advisories and vendor reports. AttackMetricx automatically provides both views so teams can bridge between modern and legacy risk assessments.
Below are the details of CVSS v2.0
Access Vector: Defines how an attacker can access the system (local, adjacent, or network).
Access Complexity: The complexity of the attack scenario needed to exploit the issue.
Authentication: The number of authentication steps required to exploit.
Confidentiality Impact: The potential impact on sensitive information disclosure.
Integrity Impact: The potential for unauthorized modification of data.
Availability Impact: The level of service disruption caused by exploitation.
Obtain All Privilege: Whether full administrative control could be gained.
Obtain User Privilege: Whether normal user rights could be obtained.
Custom Exploitability & Impact Gauges
Beyond the base CVSS scoring, AttackMetricx provides:
Exploitability Score – how realistic and technically feasible it is for attackers to exploit this vulnerability in current conditions.
Impact Score – the expected damage or disruption if the vulnerability is successfully exploited, measured in terms of confidentiality, integrity, and availability.
These gauges allow analysts to move past abstract numbers and see the practical threat level.
EPSS (Exploit Prediction Scoring System)
We integrate the EPSS probability score, which predicts the likelihood of exploitation in the next 30 days based on real-world telemetry.
Example: EPSS = 94.43%, meaning highly likely to be targeted.
Updated continuously from global threat intelligence feeds.
This is a major differentiator, as it combines traditional CVSS severity with real-world exploitation probability.
Why AttackMetricx Is Different
Unlike tools that only report CVSS scores, AttackMetricx:
Enriches vulnerabilities with EPSS (Exploit Prediction Scoring System) probabilities to forecast likelihood of exploitation in the near term.
Flags whether a vulnerability exists in the CISA Known Exploited Vulnerabilities (KEV) catalog.
Correlates CVSS with real exploitation evidence (HTTP requests, responses, PoC data) directly collected by our scanning engine.
Provides business-context scoring, helping prioritize vulnerabilities that matter most to your organization, not just those with high theoretical scores.
This combination transforms CVSS from a static rating into an actionable prioritization system.
CPE (Common Platform Enumeration)
Lists the exact affected software versions tied to the vulnerability.
Helps asset owners quickly verify if their deployments match the vulnerable versions.
Example:
cpe:2.3:a:oracle:weblogic_server:12.2.1.3.0:*:*:*:*:*:*:*
References
Direct links to:
Vendor advisories (e.g., Oracle patch notes).
Threat intel sources (e.g., PacketStorm, CVE entries).
3rd-party advisories for broader context.
This enables analysts to cross-check remediation steps and severity ratings.
Recommendations
Practical, remediation-focused guidance.
Example: Apply the official Oracle patch for WebLogic versions ≤ 12.2.1.4.0.
We prioritize vendor instructions to reduce guesswork for IT teams.
Why This Matters
Unlike many ASM tools that only provide high-level findings, AttackMetricx goes beyond asset discovery with actionable, technical validation artifacts.
This custom-built validation framework is proprietary to Cystack not open-source scanners giving customers a powerful, enterprise-grade edge in exposure management.
Threat Exposures Categories
At main view “Attack Surface Dashboard”, this section displays a visual breakdown of identified exposures, grouped by category. It helps security teams quickly assess the nature of the threats affecting their external assets and prioritize remediation efforts accordingly.
What It Shows:
Each color in the chart represents a different category of exposure:
Vulnerabilities (Red):
Includes software weaknesses, configuration flaws, and known CVEs. A dominant red segment typically signals that many issues are due to unpatched systems or insecure configurations.
Certificates (Orange):
Represents SSL/TLS-related problems such as expired or mismatched certificates. A notable presence of this category may indicate a need for better certificate lifecycle management.
Risky Ports (Yellow):
Refers to open or misconfigured ports that may expose services to unauthorized access. This highlights areas where firewall or service-level controls need review.
DNS (Green):
Encompasses DNS-related issues like inactive subdomains or dangling DNS records. These may open the door to subdomain takeover or information leakage.
Why It Matters:
Understanding the proportion of each category helps teams:
Focus first on the most critical types of exposures.
Assign remediation to the right stakeholders (e.g., network, web, or infrastructure teams).
Track trends and improvements over time based on category reduction.
📌 Scenario: If the pie chart shows 24 Vulnerabilities and 5 Certificates, the red portion dominates, meaning most issues are actual software/configuration vulnerabilities.
ASN Ownership
This bar chart highlights the distribution of your external assets across different Autonomous System Numbers (ASNs) essentially showing which providers own the IP ranges where your assets reside.
What it shows:
Each bar represents a distinct ASN and reflects the number of associated assets. Larger bars indicate greater reliance on that particular internet service provider or hosting entity.
Why it matters:
A high concentration of assets under a single ASN suggests a dependency risk. If that provider experiences downtime or becomes a target of attack, your exposure increases.
This insight helps teams understand how distributed or centralized their network footprint is and guides decisions around diversification, redundancy, or targeted monitoring.
Clarifying example:
If most of your infrastructure is hosted under a global provider like Cloudflare or Microsoft, it may be a strategic advantage or a single point of failure. In contrast, seeing assets under multiple ASNs suggests a more resilient perimeter.
Global Footprint
This world map visualizes the geographic distribution of your exposed assets across different countries and regions.
What it shows:
Each dot on the map represents a country where your assets or findings have been detected. The visual intensity or quantity of dots can hint at how broadly your infrastructure is spread.
Why it matters:
Helps teams quickly identify unexpected exposure locations.
Aids in validating whether infrastructure aligns with organizational policies (e.g., data residency, geo-fencing).
Highlights third-party deployments or shadow assets that may have gone unnoticed.
Clarifying example:
If your organization is only meant to operate locally but assets appear in foreign locations such as Europe or North America, this may indicate misconfigurations, third-party services being used without review, or even unauthorized deployments.
Certificates
This widget summarizes the current status of SSL/TLS certificates associated with your discovered subdomains.
What it shows:
The certificate statuses are grouped into clear categories. Each category is always present even if no items fall under it to provide a complete picture of your certificate hygiene:
Valid – Certificates are correctly issued and match the subdomain.
Expired – The certificate's validity period has ended.
Revoked – Certificates that have been officially revoked by the certificate authority.
Untrusted – Certificates that originate from sources the system doesn’t recognize as secure or verified.
Mismatched – The certificate doesn't match the hostname it's served on.
Self-Signed – Certificates not issued by a recognized authority; instead, they are signed by the entity itself.
Why it matters:
Proper SSL certificate management is essential for ensuring secure communication and user trust. Issues like mismatches or expired certificates can lead to browser warnings, blocked connections, or even man-in-the-middle vulnerabilities.
Certificates List View
Clicking View All opens a detailed Certificates List, displaying:
Subdomain – The domain where the certificate is detected.
Port – Typically port 443 (HTTPS).
Status – One of the predefined certificate statuses.
Last Scan – The most recent time this certificate was analyzed.
The list helps security teams prioritize remediation actions, especially in cases where production subdomains are flagged with invalid or mismatched certificates.
Clarifying example:
If a subdomain like enterpriseenrollment.example.com shows a Mismatched status on port 443, it indicates the certificate doesn't align with the subdomain's hostname. This can break HTTPS connections, reduce customer confidence, or expose traffic to interception risks.
Top Technologies
This widget provides a visual summary of the key technologies identified across your external-facing environment. It helps security teams quickly understand the technological landscape of their digital assets.
What it shows:
The chart highlights categories such as protocols, web servers, frameworks, operating systems, and security controls. Each colored segment represents a different technology, making it easy to grasp the diversity and dominance of technologies in use.
Examples of technologies that may appear:
HTTP/3 – A performance-oriented protocol designed for faster and more secure web communication.
HSTS (HTTP Strict Transport Security) – Enforces browsers to connect only via HTTPS, preventing protocol downgrade attacks.
Cloudflare – A reverse proxy and content delivery network that also offers DDoS protection and caching.
IIS – A web server platform by Microsoft commonly used for hosting internal or enterprise web applications.
Windows Server – The underlying server operating system that often accompanies Microsoft web technologies.
ASP.NET – A widely adopted framework for building dynamic web applications in .NET environments.
WordPress, PHP, MySQL – Popular components of a typical content management stack.
Why it matters:
Knowing what technologies exist across your assets is critical for identifying risk. Some technologies are more prone to exploitation, have slower update cycles, or may no longer be maintained. Awareness of these factors supports better prioritization in your vulnerability management strategy.
View All Functionality:
Clicking View All opens a full list of all discovered technologies, organized by name. This detailed view helps analysts identify unexpected, outdated, or uncommon platforms and decide whether further investigation is needed.
Exposed Ports
This widget highlights which network ports are currently exposed across your organization’s public assets. Open ports can represent potential entry points for attackers especially if associated with vulnerable services.
What it shows:
Each bar in the chart corresponds to a specific port (e.g., 443, 80), with its length reflecting how many assets expose that port. Common ports such as 443 (HTTPS) and 80 (HTTP) typically appear at the top.
Why it matters:
Analyzing exposed ports helps security teams detect unintended exposures, assess which services are publicly accessible, and prioritize actions such as disabling unused ports or strengthening protections.
Clicking View All:
Opens a detailed table listing all subdomains and their respective port information. This interface offers robust filtering and grouping options to aid in investigation.
Filter Options:
HTTP Filter:
Not HTTP – Ports that are not associated with HTTPS
HTTP Only – without HTTPS.
HTTPS – Assets secured via SSL/TLS.
Status Filter:
Live – The port is actively responding and accessible over the internet.
Inactive – Previously detected but currently unreachable.
Risky Port – Known ports often targeted by attackers (e.g., 21, 23, 3389).
CDN – Ports exposed via content delivery networks like Cloudflare.
ASN Ownership Filter:
This filter lets you group and analyze exposed ports based on the Autonomous System Number (ASN) responsible for the IP address.
These filters allow analysts to group assets by the Autonomous System (network provider) managing the IP address.
Use Case Example:
Security teams can group exposed ports by ownership or HTTP type to identify misconfigurations for instance, a financial subdomain exposing port 80 (unencrypted HTTP), or detecting that a third party provider is hosting services unexpectedly.
AI Summary & Compliance Mapping (New Tab in Issue Details)
Our platform is not just a compliance and exposure management system it is AI-powered, designed to elevate traditional vulnerability management into intelligent, automated, and actionable security insights. By integrating AI modules directly into the system, we enable organizations to move beyond manual analysis and leverage smart automation for both decision-making and remediation support.
When AI is activated, an additional tab appears alongside the standard Vulnerability Details:
With an AI license enabled, organizations gain access to exclusive features that supercharge their security operations:
→ AI Summary & Compliance Mapping Details
Here, the system automatically generates deep insights for each issue, including:
Exploitation Complexity → Level (Easy, Medium, Hard) with AI justification.
Technical Description → Clear, AI-generated explanation of the vulnerability’s nature.
Remediation Difficulty → How hard it is to fix, with reasoning.
Compliance Mapping → Shows exactly how the issue aligns (or conflicts) with specific compliance frameworks and controls.
Asset Classification → Labels the impacted asset (Low, Medium, High) based on its organizational importance.
AI Recommendations → Practical, step-by-step remediation guidance.
Risk & SLA Guidance → AI suggests the best practice timeframe for remediation (e.g., Fix within 30 Days).
MITRE & OWASP Mapping → Automatically places the issue in known frameworks, showing tactics, techniques, or categories it falls under.
HTTP Traffic Capture → If possible, AI generates HTTP request/response evidence for validation.
This transforms raw issue data into actionable intelligence helping analysts instantly understand not just what the problem is, but why it matters and how to fix it.
Generate AI Summary
At the top-right corner of this tab, you will find the “Generate AI Summary” button.
Location: Positioned just above the details panel.
Function: When clicked, it triggers the AI engine to produce an updated summary, including technical details, exploitation context, compliance mapping, recommendations, and SLA guidance.
Benefit: Ensures your team always has the latest AI-driven analysis, even as environments evolve.
Core Sections Within This Tab
Technical Summary
Exploitation Complexity
Defines how difficult it is for attackers to exploit the issue.
Example: Level: Easy → indicates attackers can exploit it with minimal effort.
The Justification explains why the AI reached this conclusion (e.g., certificate misconfiguration makes data readily visible).
Technical Description
A clear explanation of the issue, generated by AI, describing its root cause and impact.
Example: The SSL certificate on port 8443 includes SAN entries that may reveal internal or unintended domains.
Remediation Difficulty
Indicates how hard it is for your organization to fix the issue.
Example: Level: Easy → replacing or updating SSL certificates can be performed with minimal changes.
Includes AI justification, showing why remediation is straightforward or complex.
HTTP Traffic
Displays AI-parsed summaries of HTTP requests and responses if traffic was captured.
This gives analysts a clear evidence trail of whether and how the issue could be exploited over the web.
MITRE & OWASP Mapping
MITRE ATT&CK Mapping: Shows which adversary tactics and techniques the issue aligns with.
OWASP Mapping: Links the issue to OWASP Top 10 categories.
Example: A06:2021 – Security Misconfiguration for an improper SAN setup.
Recommendation
AI-generated best practices for remediation.
Example:
Review SAN entries in SSL certificates and remove any unintended or sensitive domains.
Ensure all listed domains are secured and intentionally exposed.
Impact: Converts raw detection into actionable guidance for IT and security teams.
Risk & SLA
Risk Summary: Explains the potential business/security impact if the issue remains unresolved.
Example: Exposed SAN entries can give attackers reconnaissance data about internal systems.
SLA Recommendation: AI-driven timeline for remediation.
Example: Review within 60 days (SLA Number: 60).
Mandatory Fix Flags: Highlights whether compliance requires an immediate fix.
Benefit: Gives leadership and SOC teams clear deadlines and compliance context, ensuring accountability.
By combining technical accuracy with AI-driven intelligence, this module:
Simplifies complex vulnerabilities into business-ready insights.
Aligns findings with MITRE, OWASP, and compliance standards automatically.
Provides custom remediation roadmaps, reducing analyst workload.
Ensures teams always operate with prioritized, actionable data instead of raw noise.
For organizations with AI enabled, the system runs periodic AI Scans across all detected issues:
Reviews every issue for classification and severity.
Generates compliance mappings and AI summaries at scale.
Flags urgent findings that require remediation based on best practices.
Our AI module turns the system into a next-generation cybersecurity assistant. It doesn’t just show vulnerabilities it analyzes, explains, prioritizes, maps to compliance, and even auto-resolves when safe. This level of automation empowers organizations to focus their resources where it truly matters, while ensuring compliance and strengthening defenses.
Last updated
Was this helpful?