Innersource security advisories go GA: a private channel for private vulns

Your platform team ships an internal package. Half the org pulls it. Someone finds a bug that in the wrong hands is a full RCE. What do you do next: file a public CVE and telegraph the vuln to the internet, or drop it in a Slack channel and hope every downstream repo notices before an exploit does?

Neither has ever been a good answer. On July 8 GitHub made a third option generally available: innersource security advisories, an internal advisory channel wired into Dependabot, with visibility restricted to repositories owned by the enterprise. You now get the public-advisory workflow without the public part.

What actually ships

The feature sits inside GitHub Advanced Security for enterprise customers. Per GitHub's changelog, an enterprise can publish an advisory about a component and keep its visibility scoped to enterprise-owned repositories. A new REST API endpoint sits behind it, with the usual create, update and withdraw verbs.

That last detail matters more than it looks. If the only path were the UI, this would be a nice ticketing surface with a padlock on it. An API makes it a control plane: internal SBOM tooling, vulnerability scanners running on your build fleet, and the security-response playbooks your team already keeps warm can all file advisories the same way they might file JIRA tickets today. The advisory becomes a first-class object your automation can produce.

How it reaches a repo

Publishing the advisory is only half the job. The other half is fan-out. GitHub uses Dependabot as the delivery mechanism. Once an advisory exists for a component, Dependabot notifies the repositories inside the enterprise that use that component. Two things fall out of that: security alerts on affected repos, and version-update notifications. Where a fixed version exists, Dependabot will open a pull request to bump the vulnerable dependency.

Translate that into the developer inbox: the same loop that already lands "please upgrade lodash to a fixed version" PRs on your repos now lands "please upgrade @yourco/kafka-client because your platform team said so" PRs on the same repos. From the receiving repo's point of view, nothing has changed. That is the point.

Where the trust boundary moved

Before this, "internal CVE" was close to an oxymoron in most orgs. Public advisories were, by definition, public, which made them a bad venue for a vuln in your bespoke auth library. Private issues in a single repo did not federate anywhere. So the actual mechanism most teams used was a Slack message and a shared spreadsheet. That does not scale past two teams and one dependency graph.

Here is the trust boundary that moved: an advisory is now an enterprise-scoped object, and Dependabot honours that scope. Controlled disclosure inside the walls, without leaking anything outside them. If you own a shared platform monorepo, or a family of internal SDKs used across product teams, this closes a gap that has been open since Dependabot existed.

The catch you signed up for

Two limits are worth naming out loud.

First, the feature is bound to GitHub Advanced Security on the enterprise plan. If your CI/CD stack lives elsewhere, the private-advisory workflow does not follow you. Portability across ecosystems is still your problem.

Second, this will only ever be as good as the discipline you put into it. No one files internal advisories by accident. If your security team is not empowered to publish them, or the platform group does not know it can, the feature launches with zero entries and stays there. A private CVE feed with nothing in it is worse than useless; it lulls you into thinking a channel exists when nothing has ever come down it.

Other ecosystems approach the same shape from different angles. GitLab has security policies and its own dependency scanner. Artifact registries such as Nexus and Artifactory expose vulnerability views over hosted internal packages. OSV publishes advisories in a machine-readable schema, though the public/private distinction is not what it is for. This is not the first attempt at broadcasting internal vulns; it is the first one that plugs directly into the PR-creating half of Dependabot, scoped to a single enterprise.

Ship the plumbing, then ship the culture. Otherwise you have a very expensive announcement board with an audience of zero.