Definition and Overview

Vulnerability assessment is a systematic, evidence-based process of identifying, quantifying, classifying, and prioritizing security weaknesses across information systems, applications, and network infrastructure. Unlike penetration testing, which actively exploits discovered weaknesses to demonstrate real-world impact, vulnerability assessment focuses on comprehensive discovery and risk-ranked classification. The process leverages automated scanning tools, configuration audits, known vulnerability databases (CVE, NVD, EPSS), and manual review to produce a prioritized inventory of security gaps requiring remediation.

The discipline has evolved significantly since the early days of network scanning. Modern vulnerability assessment encompasses not just traditional infrastructure scanning but also application security testing (SAST, DAST, IAST), cloud configuration audits, container image scanning, API security analysis, and supply chain dependency analysis. The shift toward continuous assessment -- rather than periodic point-in-time scans -- reflects the reality that attack surfaces are dynamic, with new assets, services, and vulnerabilities appearing constantly.

Vulnerability assessment forms the foundation of any mature security program. Without accurate, current knowledge of existing weaknesses, organizations cannot prioritize remediation efforts, allocate security budgets effectively, or demonstrate compliance with regulatory frameworks such as NIS2 and ZKB. The assessment process produces structured outputs -- typically vulnerability reports with severity scores, affected assets, remediation guidance, and verification procedures -- that feed into broader risk management workflows.

The Common Vulnerability Scoring System (CVSS) provides the industry-standard framework for rating vulnerability severity, while the Exploit Prediction Scoring System (EPSS) adds probabilistic estimates of exploitation likelihood. Together, these scoring systems enable risk-based prioritization that accounts for both technical severity and real-world threat context.

Assessment Types

Modern vulnerability assessment spans multiple domains, each requiring specialized tools, techniques, and expertise. A comprehensive assessment program covers all domains relevant to the organization's technology stack.

Assessment Type	Scope	Method	Output
Network	Infrastructure, services, protocols	Automated scanning + manual review	Open ports, misconfigurations, known CVEs
Application	Web apps, APIs, mobile apps	SAST, DAST, IAST, manual testing	Code vulnerabilities, logic flaws, injection points
Cloud	IaaS, PaaS, SaaS configurations	Configuration audit, CIS benchmarks	Misconfigurations, excessive permissions, exposed storage
Container	Docker images, Kubernetes clusters	Image scanning, runtime analysis	Vulnerable base images, insecure manifests
Supply Chain	Dependencies, libraries, packages	SCA tools, SBOM analysis	Known vulnerable dependencies, license risks
IoT/OT	Industrial control, embedded devices	Protocol analysis, firmware review	Default credentials, unpatched firmware, insecure protocols

Each assessment type produces findings in different formats and severity scales, requiring normalization before integration into a unified risk view. The Prismatic Platform normalizes findings from all assessment types into a common schema with standardized severity levels, CVSS scores, and remediation guidance.

Assessment Lifecycle

A complete vulnerability assessment follows a structured lifecycle with defined phases, each producing artifacts that feed into subsequent phases.

Phase 1 - Scope Definition establishes the boundaries of the assessment. This includes identifying target assets, defining assessment depth (authenticated vs. unauthenticated), establishing testing windows, and confirming authorization. Scope creep is the primary risk in this phase; without clear boundaries, assessments become unfocused and produce overwhelming volumes of low-value findings.

Phase 2 - Discovery maps the target environment. This phase identifies live hosts, open ports, running services, application endpoints, and technology stacks. Discovery tools include network scanners (Nmap, Masscan), web crawlers, DNS enumeration, and WHOIS lookups. The output is an asset inventory that serves as the input for vulnerability scanning.

Phase 3 - Vulnerability Identification applies automated scanners and manual techniques to discover weaknesses. Scanners compare discovered services and software versions against vulnerability databases, test for common misconfigurations, and perform active checks where authorized. Manual review supplements automated scanning by identifying logic flaws, business logic vulnerabilities, and context-dependent issues that scanners miss.

Phase 4 - Analysis and Prioritization evaluates each finding against multiple risk dimensions: CVSS score (technical severity), EPSS score (exploitation probability), asset criticality (business impact), exposure level (internal vs. external), and compensating controls (existing mitigations). The output is a prioritized remediation roadmap.

Phase 5 - Reporting and Remediation produces actionable reports for different audiences: executive summaries for leadership, detailed technical findings for engineering teams, and compliance-mapped results for auditors. Remediation guidance includes specific steps, expected effort, and verification procedures.

Phase 6 - Verification and Reassessment confirms that remediation efforts successfully addressed the identified vulnerabilities. This phase involves rescanning remediated assets and verifying that fixes do not introduce new vulnerabilities. Verification closes the assessment loop and provides measurable evidence of security posture improvement.

Scoring and Prioritization

Effective vulnerability prioritization requires combining multiple scoring inputs to produce a composite risk score that reflects both technical severity and real-world context.

Composite Risk = CVSS_Base x EPSS_Probability x Asset_Criticality x Exposure_Factor
                                                                       |
                                                       [1.0 = internet-facing]
                                                       [0.5 = internal network]
                                                       [0.2 = air-gapped]

This multi-factor approach prevents the common mistake of treating all "Critical" CVSS findings equally. A CVSS 9.8 vulnerability on an air-gapped development server with no exploitation activity (low EPSS) receives a lower composite risk score than a CVSS 7.5 vulnerability on an internet-facing production server with active exploitation (high EPSS).

Scoring System	Purpose	Range	Strengths	Limitations
CVSS v3.1	Technical severity	0.0-10.0	Industry standard, well-understood	Does not account for exploitation likelihood
CVSS v4.0	Technical severity + context	0.0-10.0	Better environmental scoring	Newer, less tooling support
EPSS	Exploitation probability	0.0-1.0	Data-driven, updated daily	Focused on known exploits only
SSVC	Decision-driven prioritization	Act/Track/Track*/Defer	Outcome-focused	Requires organizational context

Architecture and Implementation

Prismatic Assessment Pipeline

The Prismatic Platform implements vulnerability assessment as part of the Prismatic Perimeter EASM module. The assessment pipeline operates continuously, evaluating discovered assets against multiple vulnerability dimensions.

defmodule PrismaticPerimeter.VulnerabilityAssessment do
  @moduledoc """
  Continuous vulnerability assessment for discovered attack surface assets.
  Evaluates TLS, services, DNS, certificates, and known CVEs with
  composite risk scoring combining CVSS, EPSS, and business context.
  """

  @type severity :: :critical | :high | :medium | :low | :info

  @type finding :: %{
    asset_id: String.t(),
    vulnerability: String.t(),
    severity: severity(),
    cvss_score: float(),
    epss_score: float(),
    evidence: map(),
    remediation: String.t(),
    first_seen: DateTime.t(),
    last_seen: DateTime.t()
  }

  @spec assess_asset(Asset.t()) :: {:ok, list(finding())} | {:error, term()}
  def assess_asset(%Asset{type: :domain} = asset) do
    findings =
      []
      |> assess_tls_configuration(asset)
      |> assess_dns_security(asset)
      |> assess_certificate_health(asset)
      |> assess_exposed_services(asset)
      |> assess_known_cves(asset)
      |> assess_http_headers(asset)
      |> assess_email_security(asset)
      |> deduplicate_findings()
      |> score_and_prioritize()

    {:ok, findings}
  end

  @spec assess_tls_configuration(list(finding()), Asset.t()) :: list(finding())
  defp assess_tls_configuration(findings, asset) do
    case TLSAnalyzer.evaluate(asset.hostname) do
      {:ok, %{protocol: protocol, cipher_suites: suites}} ->
        tls_findings =
          []
          |> check_protocol_version(protocol)
          |> check_cipher_strength(suites)
          |> check_certificate_chain(asset.hostname)
          |> check_hsts_policy(asset.hostname)

        findings ++ tls_findings

      {:error, :connection_refused} ->
        findings ++ [%{
          vulnerability: "TLS not available",
          severity: :high,
          cvss_score: 7.5,
          epss_score: 0.3,
          remediation: "Enable TLS on all public-facing services"
        }]
    end
  end

  @spec score_and_prioritize(list(finding())) :: list(finding())
  defp score_and_prioritize(findings) do
    findings
    |> Enum.map(fn finding ->
      composite_score =
        finding.cvss_score * finding.epss_score *
        asset_criticality(finding.asset_id) *
        exposure_factor(finding.asset_id)

      Map.put(finding, :composite_risk_score, composite_score)
    end)
    |> Enum.sort_by(& &1.composite_risk_score, :desc)
  end

  defp assess_dns_security(findings, _asset), do: findings
  defp assess_certificate_health(findings, _asset), do: findings
  defp assess_exposed_services(findings, _asset), do: findings
  defp assess_known_cves(findings, _asset), do: findings
  defp assess_http_headers(findings, _asset), do: findings
  defp assess_email_security(findings, _asset), do: findings
  defp deduplicate_findings(findings), do: Enum.uniq_by(findings, & &1.vulnerability)
  defp check_protocol_version(findings, _protocol), do: findings
  defp check_cipher_strength(findings, _suites), do: findings
  defp check_certificate_chain(findings, _hostname), do: findings
  defp check_hsts_policy(findings, _hostname), do: findings
  defp asset_criticality(_id), do: 1.0
  defp exposure_factor(_id), do: 1.0
end

Assessment Categories

The Prismatic assessment engine evaluates assets across multiple security dimensions, each contributing to the overall security rating.

defmodule PrismaticPerimeter.AssessmentCategories do
  @moduledoc """
  Defines weighted assessment categories contributing to security ratings.
  Each category contains multiple individual checks, and scores are
  aggregated into the composite A-F rating.
  """

  @type category :: :tls_security | :dns_security | :application_security |
                    :infrastructure_security | :compliance_posture

  @categories %{
    tls_security: %{
      weight: 0.20,
      checks: [:protocol_version, :cipher_suite_strength, :certificate_validity,
               :certificate_chain, :hsts_enforcement, :ocsp_stapling]
    },
    dns_security: %{
      weight: 0.15,
      checks: [:dnssec_validation, :spf_record, :dkim_record,
               :dmarc_policy, :caa_record]
    },
    application_security: %{
      weight: 0.25,
      checks: [:security_headers, :content_security_policy, :cors_configuration,
               :cookie_security, :information_disclosure]
    },
    infrastructure_security: %{
      weight: 0.20,
      checks: [:exposed_services, :default_credentials, :known_cves,
               :patch_currency, :network_segmentation]
    },
    compliance_posture: %{
      weight: 0.20,
      checks: [:nis2_requirements, :zkb_requirements, :gdpr_indicators,
               :incident_response_readiness]
    }
  }

  @spec weighted_score(map()) :: float()
  def weighted_score(category_scores) do
    Enum.reduce(@categories, 0.0, fn {category, %{weight: weight}}, acc ->
      category_score = Map.get(category_scores, category, 0.0)
      acc + category_score * weight
    end)
  end

  @spec categories() :: map()
  def categories, do: @categories
end

Continuous Assessment Workflow

The platform performs assessment as an ongoing process rather than periodic scans, reflecting the reality that attack surfaces change continuously.

Asset Discovery: New domains, IPs, certificates, and services are discovered and added to the asset inventory
Initial Assessment: Each new asset undergoes comprehensive vulnerability assessment across all categories
Continuous Monitoring: Existing assets are re-assessed on a configurable schedule (default: daily for critical assets, weekly for standard)
Change Detection: Significant changes (new services, expired certificates, configuration drift) trigger immediate reassessment
Rating Integration: Assessment findings feed directly into the A-F security rating calculation
Trend Analysis: Historical assessment data reveals whether security posture is improving or degrading over time

Security Rating Integration

Assessment findings are aggregated into the security rating system visible at /perimeter. The rating provides a single-number summary of an organization's externally observable security posture.

Rating	Score Range	Assessment Implication
A	850-900	No critical/high findings, strong security posture
B	750-849	Minor findings, good security practices
C	650-749	Moderate findings requiring attention
D	500-649	Significant findings, remediation required
F	300-499	Critical findings, immediate action needed

White Team Verification

The White Team provides constructive verification of assessment findings through the Color Team framework. When automated scanners identify potential vulnerabilities, White Team agents validate findings through independent verification methods, reducing false positive rates and ensuring that remediation efforts target genuine vulnerabilities.

The verification process uses three methods: independent rescanning with different tools, manual confirmation of the vulnerability's exploitability, and formal reasoning about whether the finding represents a genuine security risk given the asset's context and compensating controls.

Custom Assessment Rules

The Prismatic Platform supports organization-specific assessment rules for regulatory requirements that are not covered by standard vulnerability databases.

defmodule PrismaticPerimeter.CustomChecks do
  @moduledoc """
  Custom vulnerability checks for Czech-specific regulatory requirements.
  Extends standard assessment categories with ZKB 264/2025 Sb. compliance
  checks and data residency verification.
  """

  @spec check_czech_specific_requirements(Asset.t()) ::
          {:ok, list(map())} | {:error, term()}
  def check_czech_specific_requirements(asset) do
    findings =
      []
      |> check_zkb_compliance(asset)
      |> check_data_residency(asset)
      |> check_incident_reporting_capability(asset)
      |> check_czech_language_support(asset)

    {:ok, findings}
  end

  @spec check_zkb_compliance(list(map()), Asset.t()) :: list(map())
  defp check_zkb_compliance(findings, asset) do
    case ZKBComplianceChecker.evaluate(asset) do
      {:ok, %{compliant: true}} ->
        findings

      {:ok, %{compliant: false, gaps: gaps}} ->
        finding = %{
          asset_id: asset.id,
          vulnerability: "ZKB compliance gaps: #{Enum.join(gaps, ", ")}",
          severity: :high,
          cvss_score: 0.0,
          epss_score: 0.0,
          remediation: "Address ZKB 264/2025 Sb. requirements"
        }
        [finding | findings]

      {:error, _reason} ->
        findings
    end
  end

  defp check_data_residency(findings, _asset), do: findings
  defp check_incident_reporting_capability(findings, _asset), do: findings
  defp check_czech_language_support(findings, _asset), do: findings
end

Remediation SLA Framework

Effective vulnerability management requires defined Service Level Agreements (SLAs) for remediation based on finding severity and business context. The Prismatic Platform tracks remediation against configurable SLA targets.

Severity	Default SLA	Internet-Facing SLA	Compliance Deadline
Critical	24 hours	4 hours	NIS2: 24 hours
High	7 days	48 hours	NIS2: 72 hours
Medium	30 days	14 days	Quarterly review
Low	90 days	30 days	Annual review
Informational	Best effort	90 days	Documentation only

SLA compliance is tracked as a metric in the security rating calculation. Organizations with consistent SLA compliance receive higher scores than those with overdue remediation items, even if the total finding count is similar.

Best Practices

Assess continuously, not periodically: Point-in-time assessments miss vulnerabilities introduced between scans. Continuous assessment catches issues as they appear, reducing the window of exposure.

Prioritize by composite risk, not CVSS alone: A CVSS 9.8 on an internal development server may be less urgent than a CVSS 7.0 on a public-facing production API. Combine CVSS, EPSS, asset criticality, and exposure level for accurate prioritization.

Validate findings before remediation: False positives waste engineering time and erode trust in the assessment process. Use the White Team verification approach to confirm findings before allocating remediation resources.

Track remediation SLAs: Define and enforce maximum time-to-remediate by severity. Track compliance against these SLAs and include SLA performance in security metrics.

Correlate across data sources: Single-source findings are less reliable. Correlate scanner results with OSINT data, Certificate Transparency logs, and manual review for higher confidence.

Maintain historical records: Vulnerability trends over time reveal whether security posture is improving or degrading. Track metrics like mean time to remediate, finding recurrence rates, and assessment coverage.

Automate where possible: Automated scanning catches known vulnerabilities efficiently. Reserve manual assessment for logic flaws, business process vulnerabilities, and context-dependent issues that scanners cannot detect.

Common Pitfalls

Scanner dependency: Relying solely on automated scanners misses logic flaws, business process vulnerabilities, and context-dependent issues. Automated scanning should be supplemented with manual review and security architecture analysis.

Alert fatigue from unprioritized findings: Presenting hundreds of findings without prioritization overwhelms engineering teams. Always score, rank, and group findings by composite risk before reporting.

Neglecting authenticated scanning: Unauthenticated scans only see the external attack surface. Authenticated scans (with valid credentials) reveal significantly more vulnerabilities, including those in authenticated areas of applications.

Ignoring informational findings: Informational findings (exposed version strings, directory listings, verbose error messages) may not be vulnerabilities themselves but provide valuable reconnaissance data to attackers. Track and remediate them.

Treating assessment as compliance checkbox: Assessment that exists only to satisfy audit requirements misses its purpose. The goal is accurate risk visibility for informed decision-making, not checkbox compliance.

One-size-fits-all severity: Treating all findings of the same CVSS score identically ignores business context. A SQL injection on a public-facing application handling financial data is far more urgent than the same vulnerability on an internal documentation server.

Penetration Testing - Active exploitation validating assessment findings
EASM - External attack surface management where assessments are performed
Security Rating - Aggregate score incorporating assessment findings
Compliance Framework - Regulatory requirements for vulnerability management
NIS2 - EU directive requiring regular vulnerability assessment
ZKB - Czech regulation mandating vulnerability management
OSINT - Open source intelligence supplementing assessment data
White Team - Constructive verification of assessment findings
Attack Surface - The scope that vulnerability assessment covers
Certificate Transparency - Supplementary data source for certificate-related findings
Broadway - Pipeline framework processing assessment results at scale

Connect & Contribute

Created by Tomáš Korcak (korczis) | Open Source under GHL

GitHub | GitLab | LinkedIn | Contact
Developer Portal | Architecture | Meet the Creator

Vulnerability Assessment

Definition and Overview

Assessment Types

Assessment Lifecycle

Scoring and Prioritization

Architecture and Implementation

Prismatic Assessment Pipeline

Assessment Categories

Continuous Assessment Workflow

Security Rating Integration

White Team Verification

Custom Assessment Rules

Remediation SLA Framework

Best Practices

Common Pitfalls

See Also

Connect & Contribute

Glossary

Related Terms

Vulnerability Assessment

Definition and Overview

Assessment Types

Assessment Lifecycle

Scoring and Prioritization

Architecture and Implementation

Prismatic Assessment Pipeline

Assessment Categories

Continuous Assessment Workflow

Security Rating Integration

White Team Verification

Custom Assessment Rules

Remediation SLA Framework

Best Practices

Common Pitfalls

Related Concepts

See Also

Connect & Contribute

Glossary

Related Terms