# Weekly DigitalOcean security audit into Jira tickets

> Every Monday, find the servers and databases you have accidentally left open to the internet, file the urgent ones as Jira tickets, and get a Slack recap.

- Workflow type: agent
- Services: DigitalOcean, Jira, Slack Bot
- Categories: Engineering, Operations
- Published: 2026-08-14

## What it does

- Checks every DigitalOcean server, managed database, and security certificate each Monday for anything exposed to the public internet.
- Flags four specific risks: servers with no firewall attached, sensitive ports open to the world, databases reachable from anywhere, and certificates expiring within 30 days.
- Files Jira tickets for the urgent findings only, naming the exact server, its region, and the rule that needs fixing, and skips anything that already has an open ticket.
- Posts one Slack recap grouped by severity, including the lower-priority items it deliberately chose not to ticket.

## What you'll need

- A DigitalOcean account with the servers, databases, or certificates you want watched.
- A Jira project where the security tickets should be filed.
- A Slack workspace and the channel your ops team actually reads.

## Prompt

Every Monday at 8am, audit my DigitalOcean account for security exposure and turn the real problems into Jira tickets. DigitalOcean has no built-in security posture product, so this workflow is my drift detector for infrastructure that has quietly been left open to the internet.

Start by pulling the full inventory from DigitalOcean. Use List All Droplets to get every Droplet with its name and region. Use List All Firewalls to get every cloud firewall, its inbound rules, and the Droplets it is applied to, and use List Firewalls for a Droplet to confirm coverage for any Droplet whose firewall assignment is not clear from the account-wide list. Use List All Database Clusters to get every managed database cluster with its name, engine, and region, then use List Database Firewall Rules on each cluster to read its trusted sources. Use List All Certificates to get every TLS certificate with its expiry date. Page through all results so nothing is missed.

Flag exactly four things. First, Droplets with no cloud firewall attached at all. Second, inbound firewall rules that allow 0.0.0.0/0 or ::/0 on a sensitive port: 22 for SSH, 3306 for MySQL, 5432 for Postgres, 6379 for Redis, 27017 for MongoDB, and 9200 for Elasticsearch. Third, managed database clusters whose trusted sources allow the whole internet. Fourth, TLS certificates expiring within the next 30 days. Watch for rules expressed as a port range or as all ports rather than a single number: a rule opening all ports to the world exposes every sensitive port at once, so treat it as the most severe finding even though no specific port is named.

Keep the output signal rather than noise. Ports 80 and 443 open to the world are normal for web servers, so never flag those. Rank every finding as critical, high, or medium. Treat a database port reachable from the whole internet, or a managed cluster whose trusted sources allow the whole internet, as critical. Treat SSH open to the world, and a Droplet running with no cloud firewall at all, as high. Treat a certificate expiring inside 30 days as medium, moving it up if it expires within the next week. Where a finding does not fit neatly, use your judgement and say briefly why you ranked it where you did.

Before filing anything, run Search Issues (JQL) in Jira to find open tickets that already cover these resources, and skip any resource that already has an open ticket for the same finding. Match on the resource name together with the nature of the finding, not the resource alone, so a Droplet with an open SSH ticket still gets a new ticket if its Postgres port turns out to be exposed as well. This dedupe pass is what stops the workflow refiling the same wall of tickets every Monday.

Use Create Issue for critical and high findings only, and never file a ticket for a medium finding. Each ticket must name the affected Droplet or cluster, its region, and the exact offending rule including port, protocol, and source range, so whoever picks it up can act without going back to the console. Put the severity in the summary and describe the suggested fix in the description.

Finish with a single Slack Bot Send a Message recap to my ops channel. Group it by severity, list the new ticket keys along with the resource each one covers, then list the medium findings that were reported but deliberately not ticketed so nothing is silently dropped. If the audit turns up nothing new, still post a short all-clear so I know the check actually ran.

## How to customize

- Change the schedule. Monday at 8am is the default, but daily or fortnightly works the same way.
- Adjust which ports count as sensitive. Ports 80 and 443 are always ignored, since public web traffic is normal for a web server.
- Move the ticketing threshold. By default only critical and high findings become tickets and everything else is just reported, but you can include medium findings too.

## FAQ

### Will this flood my Jira board with tickets every week?

No. It only files tickets for critical and high findings, and before filing anything it searches Jira for open tickets covering the same resource and problem. A server you have not fixed yet will not be reported again next Monday. Lower-priority findings are mentioned in the Slack recap instead of becoming tickets.

### Does it flag normal website traffic as a security risk?

No. Ports 80 and 443 being open to the world is how a public website is supposed to work, so those are never flagged. It looks for the ports that should almost never be public, like remote server access and database connections.

### Can it fix the problems it finds automatically?

No, and that is deliberate. It only reads your DigitalOcean setup and reports what it finds. Closing a firewall rule can take a live service offline, so a human reviews the ticket and makes the change.

### Do I need a dedicated security team to use this?

No. It is built for small teams with no security tooling. Each ticket names the affected server, its region, and the exact rule that is wrong, so whoever picks it up knows what to change without any prior security background.

### What if my team uses a different issue tracker?

The same workflow can file into another tracker instead. Jira is the default here, and the Slack recap works the same way regardless of where the tickets land.

Use this prompt in General Input: https://www.generalinput.com/prompts/weekly-digitalocean-security-audit-into-jira-tickets