Weekly MongoDB Atlas security audit with Linear tickets

Every Monday at 7am, audit the security posture of all of our MongoDB Atlas projects and file remediation tickets for the serious problems. This is a review only workflow: it reports and files tickets, and it never changes anything in Atlas.

Start by discovering the full estate rather than working from a hardcoded list. Use MongoDB Atlas List Organizations to get every organization the API key can reach, then use List Projects in Organization for each one to build the complete set of projects. For every project, pull List IP Access List Entries and List Database Users.

Review the access list entries for each project and flag anything risky. Treat an entry of 0.0.0.0/0, which exposes the project to the entire internet, as the most severe finding. Also flag CIDR ranges that are unusually wide for a single office or server, meaning anything broader than a /24, with progressively higher severity as the range widens. Flag entries with no comment, since the comment is the only record of why an entry exists and an unexplained rule is one nobody can safely remove later. Flag temporary entries whose expiry date has already passed but which are still present on the list.

Then review the database users. Flag any user holding broad roles such as atlasAdmin, readWriteAnyDatabase, or dbAdminAnyDatabase, and note which databases each role actually spans. Flag users that look stale or cannot be attributed to a specific person or service, for example generic names like test, temp, demo, backup, or admin, and any user whose name gives no clue who owns it. The user listing does not include last login activity, so base attribution judgements on the username, the authentication method, and the roles and scopes visible in the listing, and say plainly when a user is suspicious rather than provably unused.

Assign each finding a severity of high, medium, or low based on how much access it grants and how exposed it leaves the data. Then post one ranked summary to the #security channel using Slack Bot Send a Message, worst first, grouped by project. Include the total number of projects audited, a count of findings by severity, and for each finding the project name, the specific entry or user, and a one line reason it is risky. If a week comes back clean, still post the summary confirming the audit ran and nothing was flagged, so silence is never ambiguous.

For each high severity finding, create a ticket with Linear Create Issue. Give it a title that names the project and the specific entry or user so repeat findings are easy to recognize week over week, and a description that states the project, the exact access list entry or database user, why it is risky, and the concrete suggested fix, such as narrowing the range to the known application servers, adding a comment describing the purpose, removing an entry that expired on a given date, or replacing a broad role with a scoped one. Medium and low severity findings belong in the Slack summary only and should not generate tickets.

Under no circumstances should this workflow delete or modify an access list entry or a database user. Do not call Delete IP Access List Entry or any operation that edits users or network access, even when a finding looks obviously wrong. Auto revoking network access can lock production applications out of the database, so the deliverable here is the reviewed ticket and a human makes the final call.