GitHub has given enterprise security teams a new way to treat internal software vulnerabilities more like public open-source flaws. On July 8, 2026, the company made innersource security advisories generally available, connecting private vulnerability records to Dependabot alerts and, when a fixed version exists, automated update pull requests.

The feature addresses a familiar blind spot. Large organizations often reuse private libraries, frameworks, actions, and services across many repositories. Once that reuse grows, an internal component becomes part of the software supply chain. A flaw in one shared package can affect dozens or hundreds of projects, but public advisory databases may know nothing about it.

Why internal code needs an advisory channel

Security teams can already announce a flaw through tickets, email, or chat. The difficult part is translating that announcement into an accurate list of affected repositories and getting each owner onto a safe version.

Innersource advisories create a machine-readable path for that work. They use a structure similar to public security advisories while keeping visibility inside one GitHub enterprise. That lets a platform or product-security team describe the affected package and vulnerable version range once, then use GitHub's dependency data to distribute the warning.

The result is less like a broadcast memo and more like an internal vulnerability feed tied to the code that actually consumes the component.

How the workflow works

GitHub's documentation describes a three-part flow.

First, an enterprise creates and installs a GitHub App with permission to manage innersource vulnerabilities. The security team then describes the vulnerability using the Open Source Vulnerability, or OSV, format and sends it to GitHub's enterprise innersource vulnerability API. The record identifies the package, affected versions, and, when available, the fixed version.

Second, Dependabot uses the enterprise dependency graph to find repositories that rely on the affected component. Those repositories receive a security alert carrying an "Innersource" label, which distinguishes the private notice from a public open-source advisory.

Third, if the advisory points to a fixed package version that is available to the repository, Dependabot can open a pull request updating the package manifest. The advisory can later be updated or withdrawn through the same API-based workflow.

This closes an important operational gap: vulnerability discovery, affected-repository identification, and remediation can now sit in one connected flow instead of being managed as separate spreadsheets and ticket searches.

What the release changes - and what it does not

The biggest change is distribution. A team that maintains a widely used internal package can notify dependent repositories without publishing the vulnerability to the public GitHub Advisory Database. GitHub says an advisory may describe either an internal component or an open-source component, which can help an enterprise coordinate private remediation independently of public disclosure.

That does not make the feature a replacement for incident response or coordinated disclosure. Teams still need to investigate impact, decide who should know, release a tested fix, handle exploited systems, rotate exposed credentials when necessary, and meet any legal or disclosure obligations. The advisory pipeline helps propagate a known issue and its fix; it does not make those judgment calls.

Important limits for enterprise teams

The feature is available only to enterprises with an active GitHub Code Security or GitHub Advanced Security license. GitHub also says the current scope is enterprise-wide: an advisory cannot be limited to one organization or a selected group of organizations inside the enterprise.

Each enterprise can have up to 2,000 active innersource advisories. Dependabot alerts and updates must be enabled on receiving repositories for the automated workflow to work. If the relevant security license expires or Code Security is disabled, existing advisories stop being visible and no longer propagate alerts, although GitHub retains the underlying data for restoration if the license is reactivated.

Coverage also depends on accurate package identifiers, version ranges, available fixes, and dependency data. An advisory with the wrong coordinates or an incomplete version range can miss consumers or create noisy alerts. Teams should treat advisory quality as part of their security engineering process, not as clerical metadata.

A practical rollout plan

An enterprise adopting the feature should begin with a small set of heavily reused internal packages. For each one, it can define an advisory owner, the expected OSV package identifiers, severity and embargo rules, and the path for publishing a fixed version.

A pilot should verify that representative repositories receive the Innersource-labeled alert and that a fixed version produces a usable pull request. Teams should also test how advisories are corrected or withdrawn, and decide how to handle repositories that cannot accept an automatic upgrade.

The useful metric is not the number of advisories created. It is the time from confirming a vulnerability to getting affected repositories onto a safe version, with clear evidence about what remains exposed.

Why this matters

Modern software security is increasingly a distribution problem. Finding a flaw is only the beginning; the real work is locating every consumer, delivering the right fix, and proving that remediation happened.

GitHub's innersource advisories bring the private half of that process closer to the open-source security model. For enterprises that already build on shared internal components, the feature can turn a fragmented warning process into a repeatable supply-chain response - provided the dependency data, package ownership, and remediation discipline are already in place.

Sources

GitHub Changelog, July 8, 2026:

https://github.blog/changelog/2026-07-08-innersource-security-advisories-are-generally-available/

GitHub Enterprise Cloud documentation, Innersource advisories:

https://docs.github.com/en/enterprise-cloud@latest/code-security/concepts/vulnerability-reporting-and-management/innersource-advisories

GitHub Enterprise Cloud documentation, Managing innersource advisories:

https://docs.github.com/en/enterprise-cloud@latest/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/manage-innersource-advisories