Use GitHub Innersource Advisories before internal packages hide security fixes

GitHub's official changelog image for new releases.GitHub
GitHub's official changelog image for new releases.GitHub
Tools & Apps

GitHub Advanced Security enterprise customers can now publish private internal advisories that trigger Dependabot alerts and fixes across repositories owned by the same enterprise.

GitHub has made innersource security advisories generally available for GitHub Advanced Security enterprise customers. Confidence level: confirmed. The change lets enterprises publish private advisories for internal components, then use Dependabot to notify affected repositories and open fix pull requests inside the same enterprise.

GitHub changelog release image
GitHub changelog release image
Image source: GitHub changelog.

What changed

GitHub announced on July 8, 2026 that GitHub Advanced Security enterprise customers can publish internal security advisories. These advisories work like GitHub's open source security advisories, but visibility stays restricted to repositories owned by the enterprise.

The practical change is the Dependabot connection. After an advisory is created for an internal component, GitHub uses Dependabot to identify repositories in the enterprise that use it. Notifications can include security alerts, version updates, and pull requests that upgrade vulnerable versions when a fixed version is available.

CapabilityWhat it doesBest fitCaveat
Innersource advisoryPublishes a private vulnerability notice for an internal componentShared enterprise packages and servicesRequires GitHub Advanced Security enterprise access
REST API managementCreates, updates, or withdraws innersource vulnerabilitiesSecurity automation and central response workflowsNeeds governance around who can publish advisories
Dependabot alertsNotifies affected internal repositoriesFinding dependent apps after a private fixWorks best when dependency metadata is complete
Dependabot pull requestsOpens upgrade PRs for fixed versionsCoordinated remediationStill needs tests, review, and rollout discipline

Why this is early

This is an official general availability release, not a leak or beta listing. It is still early operationally because many enterprises have not modeled private internal packages the same way they model open source dependencies.

GitHub's docs describe innersource advisories as a way for enterprises to alert internal repositories to vulnerabilities and ship automated fixes with Dependabot while keeping advisories private to one enterprise. The value depends on whether internal dependency graphs, package ownership, and fixed-version release processes are already clean.

Key takeaways

  • GitHub Innersource Advisories are now generally available for GitHub Advanced Security enterprise customers.
  • Advisories stay private to repositories owned by the enterprise.
  • GitHub added a REST API endpoint for creating, updating, and withdrawing innersource vulnerabilities.
  • Dependabot can notify internal repositories that use the vulnerable component.
  • Dependabot can also open pull requests to move affected repositories to a fixed version.

Availability and access

The feature is aimed at GitHub Enterprise Cloud organizations using GitHub Advanced Security. GitHub's changelog frames availability around enterprise customers, not public repositories or standard free-team workflows.

Teams should check whether their internal packages are represented in the dependency graph before relying on automated reach. If dependency data is incomplete, the advisory may be accurate while the affected-repository list remains partial.

Practical LinkLoot angle

Internal packages often spread faster than security ownership. A shared library, GitHub Action, container base, or service SDK can become a hidden blast radius when every product team vendors it differently.

Innersource advisories give security teams a cleaner pattern: publish the private advisory, identify affected internal repos, trigger alerts, and push fixed-version PRs. Pair it with LinkLoot's AI workflow automation guide if you are designing remediation workflows where humans approve the final merge but automation handles discovery and draft fixes.

What to verify before you act

  • Confirm your enterprise has GitHub Advanced Security access for the repositories that need coverage.
  • Check whether internal components appear correctly in GitHub's dependency graph.
  • Define who can create, update, and withdraw innersource advisories.
  • Test whether Dependabot opens upgrade PRs for one internal package before scaling the process.
  • Add a playbook for advisories that require manual remediation instead of a simple version bump.

Source check

Confirmed by: GitHub's July 8, 2026 changelog confirms general availability, GHAS enterprise scope, REST API management, enterprise-restricted visibility, Dependabot alerts, and fix pull requests.

Implementation context: GitHub Enterprise Cloud docs describe innersource advisories as private enterprise advisories that can alert internal repositories and ship automated fixes with Dependabot. LinkLoot treats this as a strong Security/Developer platform update, not as a small tool listing.

FAQ

They are private enterprise security advisories for internal components, designed to notify affected repositories inside the same GitHub enterprise.