Task 1.4: Manage access, governance, and supply chain security

• AGive her the admin role on the six repositories

  Incorrect

  Admin access would show the data, but it also hands her administrative control of the repositories.

• BAdd her to a team that has triage access to the six repositories

  Incorrect

  Read and triage access give no security overview data at all.

• CGrant her access to security alerts in the six repositories

  Correct

  Members with security alert access see all security alert data for those repositories.

• DAsk an enterprise owner to share the enterprise-level overview with her

  Incorrect

  There is no sharing of an overview; what she sees depends on her own access to the repositories.

In the organization's security overview, owners and security managers see every repository. A member with write access sees code scanning and Dependabot data for those repositories, and read or triage access shows nothing. A member who has been granted access to security alerts for a repository sees all security alert data for it, without any administrative rights.

• AThe repository also needs GitHub Code Security before bypass settings can be edited

  Incorrect

  Bypass settings belong to Secret Protection's push protection; Code Security isn't involved.

• BBypass lists accept individual users only, not teams

  Incorrect

  Bypass lists are built from roles and teams, so a team can be added.

• CThe repository has more custom patterns than delegated bypass supports

  Incorrect

  Custom pattern counts have nothing to do with the bypass settings.

• DAn owner configured delegated bypass for the whole organization

  Correct

  When delegated bypass is configured at organization or enterprise level, the repository-level settings are disabled.

Delegated bypass can be configured for a repository, or for an organization or enterprise through a custom security configuration. If an organization or enterprise owner configures it at that level, the repository-level settings are disabled.

• APush again with --force, which skips push protection

  Incorrect

  A force push is still checked by push protection.

• BPush the same commit to a different branch, which the denial doesn't cover

  Incorrect

  Push protection checks pushes to the whole repository, so another branch meets the same block.

• CRemove the secret from the commit before pushing it again

  Correct

  After a denial, the secret has to come out of the commit before the push can succeed.

• DClose the secret's alert as used in tests, then push

  Incorrect

  Closing an alert doesn't approve a blocked push.

The contributor is told the decision by email. If the bypass request is approved, the commit containing the secret can be pushed; if it is denied, the contributor must remove the secret from the commit before the push succeeds. A force push, a push to another branch or closing an alert doesn't get around the block.

• ACycloneDX

  Incorrect

  The export uses SPDX.

• BSARIF

  Incorrect

  SARIF is for code scanning results.

• CCSV

  Incorrect

  The dependency graph's SBOM export isn't a CSV file.

• DSPDX

  Correct

  The dependency graph exports an SPDX SBOM.

You can export the current state of a repository's dependency graph as an SBOM in the industry-standard SPDX format, from the UI or the REST API.

• ATrusted automation such as a migration bot

  Correct

  Exemptions are for trusted automation that pushes frequently.

• BNew contributors who are still learning the codebase

  Incorrect

  Exemptions risk leaks and are not for general contributors.

• CAny developer who has bypassed push protection before

  Incorrect

  Past bypasses aren't a reason for exemption.

• DExternal collaborators on public repositories

  Incorrect

  Exemptions should be granted with caution, to trusted automation.

Exemptions skip push protection entirely for all of an actor's commits. They are designed for trusted automation, such as migration bots or service accounts, that pushes many commits with minimal friction, and should be granted with caution.

• AA software bill of materials exported from the dependency graph

  Incorrect

  An SBOM lists the dependencies; it doesn't record where an artifact was built.

• BArtifact attestations generated in the build workflow

  Correct

  Attestations are signed claims that link an artifact to its workflow, repository, commit and triggering event.

• CA published repository security advisory for each release

  Incorrect

  Advisories describe vulnerabilities, not how a release was built.

• DDependabot security updates on the release branch

  Incorrect

  They update vulnerable dependencies; they don't prove provenance.

Artifact attestations create signed provenance claims for the software you build, including the workflow, repository, commit SHA and triggering event, so consumers can verify where and how it was built, for example with gh attestation verify. On GitHub Free, Pro and Team they are available for public repositories; private and internal repositories need GitHub Enterprise Cloud.