GitHub and CodeWords: automating at the organization level

GitHub Actions is good enough that most automation questions have the same answer: put it in a workflow file. Building, testing, releasing, and anything that should gate a merge all belong there, and reaching outside for them is effort spent for nothing.

The questions Actions cannot answer are the ones that span repositories. How many of our services depend on the library we are about to change? Which repositories have no owner? Where is that vulnerable version still running? A workflow runs inside one repository and has no vantage point on the other four hundred.

What we'll cover

• What a workflow cannot see
• What the GitHub API reaches
• Connecting it to CodeWords
• Eight automations worth building
• Dependency and exposure questions
• Ownership, which decays quietly
• Building it so it survives
• Limits worth knowing about
• What to build first
• Frequently asked questions

What a workflow cannot see

Other repositories. A workflow can be given a token with broader scope, and at that point you have put an organization-wide credential inside a repository where anyone who can edit a workflow file can use it.

Patterns over time. How long reviews take across the organization, whether that is getting worse, which repositories consistently sit waiting. Each run sees one commit.

Anything nobody triggered. A repository that has had no activity for a year runs no workflows, which means the automation that would have noticed it is also not running.

The aggregate of its own results. Individual failures are visible in each repository; the fact that one test fails across nine repositories is not visible anywhere.

That last category is where the value concentrates, and it is why organization-level automation is worth running somewhere with a vantage point rather than inside any one repository.

What the GitHub API reaches

Repositories can be listed across an organization with their topics, visibility, default branch, and activity dates.

Pull requests and issues can be listed, read, created, commented on, and labelled, with review state and timing.

Contents of any file can be read without cloning, which is what makes manifest scanning practical across hundreds of repositories.

Dependency graph and Dependabot alerts report what each repository depends on and which dependencies have known vulnerabilities.

Code scanning and secret scanning alerts report findings, which is the security half of the picture.

Actions workflow runs can be listed with their conclusions and durations, which is how you get cross-repository CI trends.

Teams and CODEOWNERS describe who owns what, in theory.

Organization audit log records administrative events, which matters for anything security-adjacent.

Connecting it to CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which repositories, which question, and where the answer should go.
3. Authorize the connection with a fine-grained token or GitHub App scoped to the organization and the specific permissions needed, preferring read-only.
4. Describe the exceptions: an archived repository, one with no manifest, one you lack access to.
5. Run it read-only across everything and read the output before anything writes.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Eight automations worth building

Dependency inventory. Read every manifest across the organization and build a map of which repository uses which version of what. This single dataset answers most of the urgent questions you will ever be asked.

Exposure reporting on disclosure. When a vulnerability is announced, the answer to "are we affected and where" should be a query rather than an afternoon.

Ownerless repository detection. Repositories with no CODEOWNERS, no recent commits, or an owning team that no longer exists.

Review latency across the organization. How long pull requests wait, by repository and trend, reported as a team-level figure rather than per person.

Stale branch and fork reporting. Branches merged long ago, forks nobody has touched, and repositories that could be archived. Reported for a decision rather than deleted.

Cross-repository CI health. Which workflows fail most often, which are slowest, and which tests fail across several repositories, which is usually an infrastructure problem rather than a code one.

Secret scanning follow-through. Alerts that have been open beyond a threshold, with the repository and its owner named. The alert is only half the job.

Release note assembly across services. For anything deployed as a set, what changed in each component since the last release, gathered into one document.

Dependency and exposure questions

The clearest case for automating at organization level, because the alternative is genuinely painful.

Build the inventory before you need it. The day a vulnerability is announced is the wrong day to start writing a script that reads manifests across four hundred repositories. Run it weekly and keep the results.

Record the version, not just the dependency. "We use that library" is not an answer. "Eleven repositories use it, nine on a patched version, two on 3.1.4" is an answer.

Include transitive dependencies where you can. Most exposure is indirect, and a manifest listing only direct dependencies understates it substantially.

Track what is deployed, not only what is committed. A patched version in the default branch that has not shipped is not yet a fix, and conflating the two produces false comfort.

Report the un-scannable. Repositories with no recognisable manifest, or in a language your tooling does not cover, are gaps in the picture and should be visible as gaps rather than absent from the report.

Ownership, which decays quietly

Every organization of a certain age has repositories nobody owns, and it is never noticed until something breaks in one.

Ownership decays through reorganisation. A team is renamed, merged, or dissolved, and the CODEOWNERS files referencing it keep pointing at something that no longer exists.

Check that owning teams exist and have members. A file naming a team with no members is worse than no file, because it looks like ownership.

Compare declared owners against actual contributors. Where the people committing are not on the owning team, one of the two is wrong.

Report repositories with no activity and no owner together. Those are the candidates for archiving, and archiving is a decision a person should make with the list in front of them.

Run it quarterly. Ownership is not a thing you fix once. It decays at the rate your organization changes.

Building it so it survives

Read-only by default. Nearly everything worth building here reads. Write access should be granted for the specific automation that needs it and nothing else.

Use a GitHub App or fine-grained token. Scoped permissions, revocable, and not tied to a person who may leave.

Paginate properly. An automation reading the first page of repositories works perfectly in a small organization and silently under-reports in a large one.

Handle archived and empty repositories. Both exist in quantity and both break naive assumptions about a default branch and a manifest.

Report to a place, not to individuals. Organization-level findings are team conversations. Individual messages about repository hygiene read as blame and get muted.

Limits worth knowing about

Rate limits are the main constraint for organization-wide automation, and REST and GraphQL have separate budgets. The GraphQL API can fetch far more per request, which frequently makes it the right choice for cross-repository queries.

Secondary rate limits apply to bursts of concurrent requests and are separate from the primary budget, so parallelism needs pacing regardless of remaining quota.

Search has its own tighter limits and result caps, so anything analytical should enumerate rather than search.

Dependency graph coverage varies by ecosystem, so the inventory is more complete for some languages than others, and that variation should be visible in the report.

Enterprise and cloud differ in available endpoints, so material written for one may not apply to the other.

What to build first

The dependency inventory, read-only, run weekly. It needs no write permissions, it takes an afternoon, and it converts the worst question you will be asked — are we exposed, and where — from a day of investigation into a lookup.

Two habits make the difference. Run it across everything including the repositories you assume are dormant, since those are where old versions survive. And report the gaps as well as the findings, because a report that silently omits what it could not scan is a report that overstates how much you know.

Frequently asked questions

Why not use Actions for all of this?

Use Actions for anything about one commit or one repository, which is most day-to-day automation. Reach outside for questions that span repositories, because a workflow can only answer those by holding an organization-wide token inside a repository, which is a credential in a place anybody with write access can use.

Does this replace Dependabot?

No. Dependabot raises alerts and opens pull requests, and it is good at that. What it does not do is answer aggregate questions across the organization or track how long alerts stay open with an owner named. The automation reads its output and turns it into a picture.

How do I avoid rate limits across a large organization?

Use GraphQL for cross-repository queries, request only the fields you need, cache what does not change often, and schedule the heavy passes rather than running them on demand. Secondary limits on concurrency bite before the primary budget does, so pace the parallelism.

Should the automation open pull requests?

It can, and consider whether a human-readable report is better first. A report gets discussed; forty automated pull requests across forty repositories get closed unreviewed, which is worse than not opening them.

What permissions should it have?

Read-only on repository contents, metadata, and the security alerts you care about. Add write for the one automation that genuinely writes, scoped to the repositories it touches, using a fine-grained token or App rather than a personal token.

Can it tell me what is actually deployed?

Only if something records deployments, which is worth building for exactly this reason. Committed and deployed are different states, and a security report conflating them will tell you a vulnerability is fixed when the fix has not shipped.

How do I handle repositories in languages our scanning does not cover?

List them as unscanned rather than omitting them. A report covering eighty percent of repositories and saying so is useful. One that covers eighty percent and reads as complete is actively misleading, and it will be read as complete.

How often should the inventory run?

Weekly is enough for dependency and ownership data, which changes at the pace your organization does. Run it more often and you are mostly re-reading unchanged manifests; run it monthly and the answer is stale the day you need it most.

Can it help with a monorepo?

The cross-repository questions largely disappear, which is one of a monorepo's genuine advantages, and the ownership and review-latency questions remain. Point the same automations at directories rather than repositories and most of them still apply.

Should findings go to repository owners or to one place?

One place first — a security or platform channel — so somebody can triage before anything reaches forty repository owners. Fanning out raw findings produces forty people each assuming somebody else owns the shared dependency, which is how nothing gets done.

What about repositories in other organizations?

Scope the automation per organization and run it separately, since tokens and permissions are per organization. Where the same dependency question spans several, collect the inventories centrally and analyse them together rather than trying to query across the boundary.

Can it report on Actions usage and cost?

Yes, by reading workflow runs across the organization with their durations. Minutes consumed by repository and by workflow is a report almost nobody runs, and it usually identifies one or two workflows running far more often than anybody intended.

Related reading

• Bitbucket and CodeWords
• Jenkins and CodeWords
• CodeWords integrations and templates