GitHub Advanced Security Practice Questions

GitHub provides secret scanning for free on all public repositories to protect the open-source ecosystem. For private repositories, it is part of the paid GitHub Advanced Security license and must be explicitly enabled at the organization or repository level.

Dependabot alerts, which notify you of known vulnerabilities in your dependencies, are available for all repositories, public and private, even on the free plan. GHAS is not required for this core security feature.

When an alert is dismissed, GitHub remembers the code pattern and location. The alert will remain dismissed in subsequent scans of the same branch as long as the code that triggered it remains unchanged. However, if the code is significantly modified, CodeQL may reopen the alert because the context has changed and the original dismissal reason may no longer be valid.

GitHub secret scanning can be extended with custom patterns to detect proprietary or internal secret formats. Administrators can define these patterns at the organization or repository level by providing a name and a regular expression that matches the secret format, such as CORP-PROD-[A-Za-z0-9]{32}.

Dependabot PRs are created from a branch in the repository, just like any other PR. If the update causes failures, the correct procedure is to fetch and check out that branch (e.g., dependabot/npm_and_yarn/my-app/lodash-4.17.21), make the required compatibility fixes, and push the changes back to the same branch. This updates the pull request, triggers the CI checks again, and keeps the entire history of the remediation in a single PR.

While branch protection rules can require status checks, they have an option to 'Allow administrators to override'. Repository rulesets are a more powerful and flexible evolution of this. They can be targeted to multiple branches or tags, and critically, they can be configured so that no one, including administrators, can bypass the required checks, making them the most robust method for policy enforcement.

The Dependency Review feature, implemented as a GitHub Actions workflow (dependency-review-action), is specifically designed for this purpose. It runs on pull requests and can be configured with allow-licenses or deny-licenses to check for license compliance. By making this workflow a required status check, it can effectively block pull requests that introduce dependencies with non-compliant licenses. The dependabot.yml file is for configuring Dependabot updates, not for license checks on pull requests. Repository rulesets can enforce that the workflow runs, but the license logic is within the action itself. Secret scanning does not handle dependency licenses.

For a monorepo with multiple ecosystems, you must define a separate block for each package-ecosystem and specify its directory. This tells Dependabot where to find the manifest files for each service.

The groups key is the correct mechanism for bundling multiple dependency updates into a single pull request, reducing PR noise. You would define a group for npm and another for Maven within their respective ecosystem blocks.

Workflows triggered by pull_request from forks run in a restricted context with a read-only token and no access to secrets. This can cause the Initialize CodeQL step to fail if it needs to access certain resources or if the analysis is complex. To analyze code from forks securely, the workflow should be changed to use the pull_request_target event, which runs in the context of the base repository but checks out the code from the pull request's HEAD commit. This is a common and critical distinction for securing workflows that run on code from external contributors.

Push protection applies to all users, regardless of their permissions. A user, including an administrator, must explicitly bypass the block by providing a reason. The protection is not automatically disabled for administrators; they are subject to the same initial block as any other contributor.

While branch protection rules can require status checks, administrators can typically override them. Repository rulesets provide a more powerful and flexible way to enforce policies. By creating a ruleset that targets the main branch and requires the specific status checks, you can enforce the policy across the repository or organization. Crucially, rulesets have an explicit option to prevent even administrators from bypassing the rules, which meets the stated requirement.