Weekly DigitalOcean security audit into Jira tickets

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.