Weekly external attack surface drift report in Slack
Check your public IPs against an approved baseline every Monday and get one grouped Slack alert covering only what actually changed.
Every Monday at 7am, review my company's external attack surface for drift and report it to my security channel in Slack.
Start by reading my watched asset list from Google Sheets with Get Values. Each row holds one public IP address or hostname, plus a column listing the ports that are approved to be open on that asset. Treat that column as the approved baseline. When a row holds a hostname rather than an IP, use the Shodan Resolve Hostnames operation to turn it into an IP address first, and carry the hostname through so I can still tell which asset a finding belongs to.
For each IP, call Shodan Get Host Information to pull the services, open ports, banners, and product versions Shodan currently observes, along with anything in the host's vulns list. Pace these lookups at roughly one request per second, because the Shodan API allows about one request per second and will return a rate limit error above that. If a single host lookup fails or Shodan has no record for that address, note it and keep going rather than aborting the whole run.
Also read back the history rows this workflow has appended on previous runs, using Get Values on the history tab, so you know what was last seen on each asset. Compare what Shodan sees now against both the approved baseline and the most recent history entry, and surface only the drift: ports that are open now but are not in the approved column, services whose product or version changed since the previous run, and any CVEs Shodan flags in vulns. Ports that are open and approved with no version change are not findings and should not be reported.
Post one grouped Slack message with Send a Message to my security channel. Group the findings by IP address rather than sending one alert per port, and lead with the highest risk items: exposed remote access on port 3389 or 22, databases reachable from the internet or without authentication, and admin panels or management interfaces. Everything else follows underneath. For each finding give me the asset (IP and hostname), the port, what Shodan sees running there including product and version, and one short line on why it matters.
Append every finding back into the Google Sheet with Append Values, one dated row per finding, capturing the run date, IP, hostname, port, the service and version observed, the finding type (newly open port, changed service or version, or flagged vulnerability), and a severity, so there is a running history I can look back through.
If nothing has drifted, stay quiet: post a single short all-clear message naming how many assets were checked and that everything matches the approved baseline, and do not append any finding rows that week.
What does this prompt do?
- Every Monday morning, reads your watched asset list from a Google Sheet: the public IP addresses or hostnames you care about, plus the ports each one is approved to have open.
- Looks up what the internet can currently see on each address, including open ports, the software running on them, product versions, and any known vulnerabilities.
- Compares today's picture against your approved baseline and reports only the drift: ports that are newly open, software or versions that changed, and anything flagged as vulnerable.
- Posts one grouped Slack message organised by address with the riskiest findings first, and appends every finding as a dated row back into the sheet so you build a running history.
What do I need to use this?
- A Shodan account, so the workflow can look up what is publicly visible on your addresses
- A Google Sheet listing the public IP addresses or hostnames you want watched, with a column for the ports that are approved to be open on each one
- A Slack workspace and the channel where your security team wants the weekly report
How can I customize it?
- Change the timing: it runs Monday at 7am by default, but daily or twice weekly works exactly the same way.
- Adjust what counts as high risk. Remote access on ports 3389 and 22, exposed databases, and admin panels lead the report by default.
- Point it somewhere else: a different Slack channel for the alert, or a separate tab in the sheet for the history log.
FAQs
Do I need to install a scanner or run anything on my own network?
Will this fill my Slack channel with alerts every week?
What if my list uses hostnames instead of IP addresses?
How many addresses can it watch?
Where does the history live?
Related templates
When your flight moves, your calendar times get corrected automatically and you get a Slack note naming the meetings you're about to miss.
Every 15 minutes, forwarded phishing reports get traced back to the server that really sent them, with a verdict in Slack and the worst senders reported.
Every Monday, check every S3 bucket for public exposure, missing encryption and weak backup settings, then get the risks ranked in Slack.
Every weekday at 7am, sign in to the tender portals you track, filter new notices against your bid criteria, and open a deal for the ones worth chasing.
Every weekday at 4pm, spot the threads that went quiet, stage a ready-to-send nudge in your mailbox, and get a ranked Slack recap.
Every Monday, rank the week's matches by expected demand, put the big ones on your venue calendar, and post a rota-ready summary to Slack.
Stop hearing about an open port from someone outside your company.
Get a weekly read on what the internet can see of your infrastructure, filtered down to only the things that changed.