Internet scanning campaign explorer for security teams

I want an app that shows my security team which mass-scanning campaigns are running on the internet right now and whether any of them matter to the software we actually run. The audience is our security lead doing a morning review, not an on-call responder, so this is a browsing and pivoting surface rather than an alerting one. It should never try to page anyone or lean on urgency styling. It opens to a calm, dense, scannable overview that answers the question is anyone scanning for something we own before it asks anyone to read individual campaigns.

The main screen is a campaign explorer. Use GreyNoise List Tags to get the catalog of current activity tags and malware labels, and for each one use GreyNoise GNQL Stats to pull the aggregated counts of how many IPs are behind it, broken down by country, organization, ASN and actor. GNQL Stats is the right call for these aggregate counts rather than paging full result sets through GNQL Query. Render the campaigns as a browsable, filterable, sortable list showing the tag name, its label or category, the total number of scanning IPs, and the top few countries, organizations and actors inline, so the lead can pivot across the list without opening anything.

A second view reads our technology inventory from a Google Sheet using Google Sheets Get Values. The sheet is one row per vendor, product and version we run at the edge. Give it a simple documented column layout and state that layout plainly somewhere in the app so whoever maintains the sheet does not have to guess, and read it with a straightforward documented range. Match those inventory rows against the campaign list on vendor and product name, and surface the result at the very top of the app as the headline answer to is anyone scanning for something we own. Campaigns that match our inventory must always sort to the top of the explorer and render in a visually distinct state, with the matching inventory row named on the campaign so the reason for the match is immediately obvious. Inventory rows that match nothing are fine and should just be shown as unmatched rather than hidden.

Each campaign opens a detail view. Pull a sample of the IPs currently running that campaign with GreyNoise GNQL Query, and show the CVEs the tag is associated with. Keep the sample small and label it clearly as a sample rather than attempting to render every scanning IP. Show the country, organization, ASN and actor breakdowns in more depth here than the list does, and use GreyNoise GNQL Recall Stats to show how the campaign's scanning volume has moved over recent days.

Analysts can star a campaign to a watchlist that persists in the app. A starred campaign stores a free-text note and a reviewed date, both editable in place. On the watchlist view, show for each starred campaign how its scanning volume has moved since the last time someone reviewed it, comparing current volume against the volume as of that stored reviewed date using GreyNoise GNQL Recall Stats, and state the change in plain terms such as roughly three times as many scanning IPs as at your last review, or quieter than when you last looked. This movement-since-review number is a core part of the morning pass and should be prominent, not buried.

Every campaign has an Assess our exposure button that starts a background agent. The agent pulls GreyNoise Retrieve CVE Information for each CVE the campaign is associated with, checks the campaign's scanning volume trend, compares all of that against the inventory rows read from the Google Sheet, and writes a plain-language exposure assessment back into the app so it appears on the campaign and persists for whoever looks next. The assessment should say clearly whether we are exposed, which of our products and versions are implicated, what the CVE detail actually says about observed exploitation, and what the scanning trend suggests. When, and only when, the agent concludes we are genuinely exposed, it files a ticket using Jira Create Issue containing the campaign, the associated CVEs, the affected inventory rows and its reasoning, and links that ticket back onto the campaign in the app. If it concludes we are not exposed, it still writes and stores the assessment and files nothing.

Bake in the review rhythm throughout. Favour density and calm over alert styling, make the inventory-matching campaigns unmistakable at a glance, and make it obvious which campaigns have already been assessed or reviewed and which are new since the last visit. Watchlist entries, notes, reviewed dates and exposure assessments all persist in the app rather than being regenerated on every load, and the exposure agent runs in the background so the lead can keep browsing the explorer while it works.