Code of Conduct
What article on docs.github.com is affected?
https://docs.github.com/en/code-security/concepts/supply-chain-security/about-supply-chain-security
What part(s) of the article would you like to see updated?
The Feature Availability section (https://docs.github.com/en/code-security/concepts/supply-chain-security/about-supply-chain-security#feature-availability) is broken into three parts: public, private, and any, due to distinctions that appear to be outdated. Specifically, they state that for public repositories:
Dependency graph: Enabled by default and cannot be disabled.
Dependency review: Enabled by default and cannot be disabled.
Whereas for private repositories:
Dependency graph: Not enabled by default. The feature can be enabled by repository administrators. For more information, see Exploring the dependencies of a repository.
Dependency review: Available in private repositories owned by organizations that use GitHub Team or GitHub Enterprise Cloud and have a license for GitHub Code Security or GitHub Advanced Security. For more information, see About GitHub Advanced Security and Exploring the dependencies of a repository.
However, (a) there are two changelog/GitHub announcements that this has changed:
(i) https://github.blog/changelog/2025-05-15-users-can-now-disable-dependency-graph-for-public-repositories/
- "You can now disable the dependency graph for public repositories."
(ii) https://github.blog/changelog/2025-06-17-dependency-graph-now-defaults-to-off/
- "Following last month’s change that added the ability to turn off dependency graph, the setting for newly-created public repositories will now default to off."
(b) In addition, other docs state or imply that it is not the case:
(i) https://docs.github.com/en/code-security/concepts/supply-chain-security/about-dependency-review
- "The dependency review feature becomes available when you enable the dependency graph"
- "Repository administrators can enable or disable the dependency graph for repositories. "
(ii) https://docs.github.com/en/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/enabling-the-dependency-graph
- "When the dependency graph is first enabled, any manifest and lock files for supported ecosystems are parsed immediately."
This also comports with the GitHub UI as a maintainer. So I think the doc cited in this issue is stale, and rather than revising only the bullet points that are incorrect, the whole section should probably be condensed, because the distinction between public and private repos is now very minimal - if that section were written today, I doubt it would be presented in this way. Although there are still some minor public/private differences, the three-part structure no longer seems justified.
Additional information
No response
Code of Conduct
What article on docs.github.com is affected?
https://docs.github.com/en/code-security/concepts/supply-chain-security/about-supply-chain-security
What part(s) of the article would you like to see updated?
The Feature Availability section (https://docs.github.com/en/code-security/concepts/supply-chain-security/about-supply-chain-security#feature-availability) is broken into three parts: public, private, and any, due to distinctions that appear to be outdated. Specifically, they state that for public repositories:
Whereas for private repositories:
However, (a) there are two changelog/GitHub announcements that this has changed:
(i) https://github.blog/changelog/2025-05-15-users-can-now-disable-dependency-graph-for-public-repositories/
(ii) https://github.blog/changelog/2025-06-17-dependency-graph-now-defaults-to-off/
(b) In addition, other docs state or imply that it is not the case:
(i) https://docs.github.com/en/code-security/concepts/supply-chain-security/about-dependency-review
(ii) https://docs.github.com/en/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/enabling-the-dependency-graph
This also comports with the GitHub UI as a maintainer. So I think the doc cited in this issue is stale, and rather than revising only the bullet points that are incorrect, the whole section should probably be condensed, because the distinction between public and private repos is now very minimal - if that section were written today, I doubt it would be presented in this way. Although there are still some minor public/private differences, the three-part structure no longer seems justified.
Additional information
No response