A new team is standing up GitHub Advanced Security on a private repository and wants their preventive controls to work on day one. They enable push protection and add a Dependency Review workflow on pull requests, but the dependency review job fails with an error that a required feature is not enabled, while push protection works as expected. Applying the prevention-first principle, what is the prerequisite they have missed, and why does it matter for the pre-merge dependency gate specifically?
- AThey have not granted the workflow contents: write permission, which Dependency Review needs in order to store the computed dependency diff back into the repository during the run.
- BThey have not enabled CodeQL code scanning, whose SARIF output Dependency Review consumes to determine which introduced dependencies are vulnerable.
- CThey have not enabled the dependency graph, which is on by default for public repositories but must be turned on for private ones, and Dependency Review needs it to diff the base and head dependencies. Correct
- DThey have not committed a lockfile to the default branch, without which Dependency Review has no resolved dependency set to compare across the pull request.
Why A is wrong: Dependency Review only requires read access to repository contents to compare manifests and does not write a diff back to the repository, so escalating to write permission does not fix a disabled feature. The permissions framing is plausible but targets the wrong prerequisite.
Why B is wrong: Dependency Review and code scanning are independent features; Dependency Review derives vulnerability information from advisories applied to the dependency graph, not from CodeQL SARIF. Enabling code scanning would leave the dependency graph still disabled and the same error in place.
Why C is correct: Dependency Review reads the dependency graph to compute the difference between the base and head of a pull request, and the dependency graph is enabled by default only for public repositories, so a private repository must have it switched on. With it disabled the action cannot read dependency data and reports a feature-not-enabled error, which is exactly the failure described.
Why D is wrong: A missing lockfile can reduce the precision of resolved versions but it does not raise a feature-not-enabled error, and Dependency Review can still operate on manifests. It explains a milder, different symptom than the explicit prerequisite failure in the scenario.