Security professionals operate in an environment where vulnerability information is abundant.

The National Vulnerability Database contains hundreds of thousands of CVEs. Vendors continuously publish advisories. Researchers release exploit details. Security products generate their own severity assessments and prioritization scores.

CISA’s Known Exploited Vulnerabilities Catalog adds an especially important signal by identifying vulnerabilities with evidence of exploitation in the wild.

But even a high-quality list creates another problem.

A vulnerability table still requires someone to move across rows and columns, interpret scores and dates, understand vendor and product context, and mentally compare one CVE with another.

The information is available.

The harder question is:

What deserves my attention right now?

That became the product problem behind Cyber Threat Wall.

I designed the project around several audiences that encounter essentially the same problem from different perspectives.

Vulnerability management and security operations teams need to quickly identify exploitable vulnerabilities that may warrant remediation.

Threat intelligence teams need to understand changes in the threat landscape rather than simply see another static list.

Security leaders need a condensed explanation of what changed and why it matters.

Cybersecurity product and marketing teams need a clearer way to contextualize vulnerability activity around particular vendors, technologies, and customer environments.

Security journalists and researchers need simple ways to identify patterns worth investigating.

The core insight was that these audiences rarely need another complete database.

They need signal extraction.

The application therefore begins with confirmed exploitation rather than vulnerability disclosure.

That decision dramatically narrows the problem.

Instead of asking:

Which of hundreds of thousands of vulnerabilities might matter?

Cyber Threat Wall starts with:

These vulnerabilities are being exploited. Which ones deserve the most attention now?

The design was inspired by financial market heat maps.

A traditional stock table can provide enormous amounts of useful information, but a market map communicates something different. Size, color, position, and movement allow a viewer to understand the state of a market before examining individual companies.

I applied the same concept to vulnerability intelligence.

Instead of treating each vulnerability as an identical row, Cyber Threat Wall presents the CISA KEV catalog as a dynamic threat market.

Larger and more prominent tiles indicate stronger prioritization signals. Colors communicate urgency. Movement indicators show changes over time. Market Movers surface noteworthy changes. Filters allow users to narrow the wall according to their own interests.

The objective was not to replace vulnerability-management platforms.

It was to build a better orientation layer.

A user should be able to open the application and understand the current exploitation landscape within seconds.

Product Decisions

Start with exploitation, not disclosure

The most important product decision was beginning with CISA KEV rather than the entire NVD.

CVSS tells users something about vulnerability severity.

KEV tells them something fundamentally different:

There is evidence that attackers are actually exploiting it.

That makes KEV an effective starting universe for prioritization.

NVD is then used as an enrichment source rather than the inclusion criterion.

Prioritize confirmed exploitation

Every vulnerability on the wall already carries the strongest baseline signal available in the application:

confirmed active exploitation.

That keeps the product focused.

Cyber Threat Wall does not attempt to visualize every theoretical vulnerability. It focuses specifically on vulnerabilities that have crossed from potential risk into observed exploitation.

Use proportional tiles

Not every threat deserves equal visual space.

The wall therefore changes tile prominence according to the vulnerability’s Threat Signal.

Higher-ranked vulnerabilities become more visible.

This gives the user an immediate visual hierarchy without requiring them to read every number.

Rank threats transparently

I wanted prioritization without creating an opaque proprietary score.

Cyber Threat Wall therefore calculates a Threat Signal from observable inputs, including:

• confirmed CISA exploitation
• NVD CVSS severity
• FIRST EPSS exploitation probability
• recency of KEV inclusion
• known ransomware use
• CISA remediation urgency

The score is intentionally explainable.

Opening a CVE shows the factors that contributed to its ranking.

Show movement, not just position

A rank is useful.

A changing rank can be more useful.

The application records daily snapshots so vulnerabilities can eventually be evaluated according to:

• 24-hour movement
• 7-day movement
• historical ranking
• Threat Signal change
• new entry status

This led to Market Movers, one of the project’s defining features.

Rather than simply asking which vulnerabilities rank highest, users can also ask:

What’s changing fastest?

Make filtering part of the product

Different users care about different slices of the threat landscape.

The application supports filters for:

• vendor
• technology category
• CVSS
• EPSS percentile
• ransomware association
• KEV recency
• exploit characteristics
• remediation deadline
• search terms

Filtered states can also be shared through URLs.

A user can therefore create and send a view representing a particular security concern instead of telling someone how to reproduce a search.

Separate analyst and executive needs

A security analyst may want CVE identifiers, CVSS vectors, CWE information, EPSS, dates, and movement.

An executive probably does not.

Cyber Threat Wall therefore includes separate Analyst and Executive experiences.

Executive View emphasizes:

• new threats
• vendor concentration
• technology pressure
• ransomware activity
• high-priority threats
• plain-language intelligence observations

The goal is the same data with different information architecture.

Automate updates

A live intelligence product cannot depend on someone manually downloading a CSV.

GitHub Actions refreshes the underlying data on a recurring schedule.

The application can therefore continuously ingest updated CISA KEV data, enrich records, recalculate scores, update history, regenerate API outputs, and redeploy the application.

Keep the architecture lightweight

I deliberately avoided introducing a traditional application server for the first versions of the project.

Cyber Threat Wall runs as a static application on GitHub Pages.

This keeps:

• hosting simple
• operational costs near zero
• deployment transparent
• source code inspectable
• maintenance manageable

The intelligence pipeline runs before deployment rather than requiring expensive real-time processing for every visitor.

Attribute the sources

Cyber Threat Wall does not attempt to obscure where its intelligence originates.

CISA, NVD, and FIRST remain clearly identified throughout the application.

This is especially important in security intelligence.

The application adds presentation, normalization, prioritization, historical context, and workflow functionality.

The authoritative security information remains with the original sources.

The system follows a straightforward pipeline:

CISA KEV → GitHub Action → enrichment → normalized JSON → scoring → interactive wall → GitHub Pages

The application is built primarily with:

HTML for the interface structure.

CSS for the market-wall visualization, responsive layouts, threat states, and executive presentation.

JavaScript for filtering, sorting, ranking views, vendor intelligence, URL state, CSV exports, sparklines, and interactive CVE details.

Python for data ingestion, normalization, enrichment, scoring, historical snapshots, and feed generation.

GitHub Actions for automated refreshes and deployment.

CISA KEV as the primary actively exploited vulnerability dataset.

NVD API for severity, CWE, attack-vector, and vulnerability enrichment.

FIRST EPSS for exploitation-probability data.

The resulting normalized dataset also produces reusable machine-readable outputs.

Those include:

• current threat data
• latest movers
• new vulnerabilities
• vendor summaries
• historical observations
• weekly summaries
• RSS feeds

This transformed the project from a standalone visualization into a small open vulnerability-intelligence platform.

The most important lesson was not technical.

It was that vulnerability intelligence becomes considerably more useful when the interface is built around a specific user question.

What deserves my attention right now?

Once that question became the organizing principle, many subsequent product decisions became clearer.

Confirmed exploitation mattered more than raw CVE volume.

Movement mattered in addition to severity.

Vendor and technology context mattered more than isolated identifiers.

Executives needed interpretation rather than additional fields.

Historical snapshots turned a current-state dashboard into a source of original trend data.

The project also reinforced something central to product marketing: presentation changes the value of information.

CISA, NVD, and FIRST already provide exceptional public data.

Cyber Threat Wall does not create that intelligence.

It changes how someone can perceive and interact with it.

That distinction is important.

The opportunity was not finding more data.

It was designing a better way to turn existing data into decisions.

What’s Next?

The next stage is to make Cyber Threat Wall increasingly useful as a lightweight security-intelligence workspace.

Planned areas include:

• richer historical analytics
• stronger vendor trend reporting
• technology-specific threat pages
• EPSS movement tracking
• vulnerability watchlists
• customizable monitoring views
• automated daily and weekly briefings
• embeddable threat widgets
• additional exploitation intelligence sources
• sector-specific views
• API documentation
• better visualization of relationships between vendors, technologies, and exploitation trends

The growing historical dataset may ultimately be the project’s most interesting asset.

A current vulnerability dashboard tells users what the market looks like today.

A year of snapshots can begin answering much deeper questions about how the exploitation landscape changes over time.