GitHub Advanced Security Free Sample Questions

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.

For transitive dependencies, a direct patch for the sub-dependency may not exist or be the correct solution. The proper approach is to identify which direct dependency in the manifest file (e.g., package.json) is responsible for including the vulnerable package. Often, updating this top-level dependency to a newer version will, in turn, pull in a non-vulnerable version of the transitive dependency. Dependabot alerts often provide this context.

GitHub's code scanning feature is designed to ingest security results using the industry-standard Static Analysis Results Interchange Format (SARIF). To integrate a third-party tool, the output must first be converted into a valid SARIF v2.1.0 file. This transformed file can then be uploaded to the /code-scanning/sarifs API endpoint or using the github/codeql-action/upload-sarif action in a workflow. Direct upload of custom JSON is not supported.

The fundamental difference is that for compiled languages (C#, Java, C++, Go), CodeQL needs to observe the build process. It hooks into the compiler to understand how source files are related, how libraries are linked, and to build an accurate, queryable database representing the code's structure and data flow. For interpreted languages (Python, JavaScript, Ruby), there is no compilation step, so CodeQL can extract this information directly from the source code itself without needing to monitor a build.

The Security Overview is a centralized dashboard that aggregates security alerts from all enabled features (Code Scanning, Secret Scanning, Dependabot) across the repositories in an organization. It allows security managers and administrators to quickly identify repositories with the most critical alerts and track overall risk trends without needing to inspect each repository individually.

Secret scanning validity checks are designed for this exact scenario. When a secret from a supported partner is detected, GitHub can optionally send the token to the provider's endpoint to verify if it is still active. This information is then displayed on the alert, allowing teams to filter for and prioritize the remediation of secrets that pose an immediate, confirmed risk.