Audit your CircleCI contexts and shared build secrets

Build me an internal app my platform team opens once a month to audit our CircleCI contexts and the shared build secrets inside them. Right now that audit means clicking through organization settings one context at a time, and there is no single place that shows what secrets exist, who is allowed to use them, and which ones have gone stale. I want that one place.

The main view is a table of every context in the organization, loaded with List contexts. For each context, call List environment variables to get the variable names and their created and updated timestamps, and Get context restrictions to get the projects and groups allowed to use it. Use Get a context for the created date and any other basic detail. Columns: context name, number of secrets it holds, allowed projects (or a clear "unrestricted" marker when there are none), the date of the oldest secret update, and risk badges. Sort the riskiest contexts to the top by default, and put summary counters above the table for total contexts, total secrets, unrestricted contexts, and stale secrets.

Important: List environment variables deliberately does not return the values of the secrets, only their names. That is exactly what I want, because this screen gets shared in review meetings. Never try to fetch or display a stored secret value anywhere in the app, and say plainly in the interface that values are never retrieved.

Flag risky contexts automatically with three rules, and show which rule fired on each row. First, a context with no project restriction at all, meaning any project in the organization can use its secrets. Second, variable names that look like production credentials, matching words like PROD, PRODUCTION, LIVE, RELEASE, DEPLOY, ROOT, or ADMIN, especially when combined with SECRET, TOKEN, KEY, PASSWORD, or CREDENTIAL. Third, secrets whose updated timestamp is more than a year old, which almost always means nobody has rotated them. Make the stale threshold and the production word list adjustable in a settings area rather than hardcoded.

Clicking a context opens a detail view showing every secret name in it with its created and updated dates and its own stale flag, plus the full list of project and group restrictions. This is where the fixes happen.

Let me fix things in place from that detail view. Add or update an environment variable to rotate or replace a secret, taking the name and the new value as input and making it clear the value is written and never read back. Remove an environment variable to drop one. Create context restriction to lock a context down to a specific project. Delete context restriction to remove one. And Delete a context for ones nobody uses. Put every destructive action behind a typed confirmation where I have to type the exact context or variable name before the button becomes active. The delete context dialog must state that deleting a context also deletes every environment variable inside it and that any job depending on it will start failing. Refresh the affected row after each action so the table always reflects reality.

For anything I would rather hand off than fix on the spot, give me a button that files a remediation ticket in Linear with Create Issue. Pre-fill the title with the context name and the problem, and the description with why it was flagged, the secret names involved, the current project restrictions, and the date of the audit. Let me choose which Linear team it goes to, populated from List Teams, and remember that choice. Store the filed issue identifier and URL against the context so next month the row shows that a ticket already exists and links to it instead of offering to file a duplicate. Keep a light audit history too: context, what was flagged, whether it was fixed or ticketed, and when, so each monthly review starts from what was left open last time.

Explain the permission requirement up front, in a banner at the top of the app. Context endpoints in CircleCI require organization admin membership, and a token without it comes back as a permission error, sometimes disguised as a not found response. If the context list fails that way, show a clear message saying the connected account needs organization admin access, rather than rendering an empty table that looks like the organization has no contexts.

One more thing on design: the app handlers run with the connection of whoever set it up, so do not build per viewer permission tiers or role checks. The typed confirmation dialogs are the safety mechanism for the destructive actions.