Lab: enforce and remediate a DevSecOps gate

Outcome

Add a safe security or quality scan to a training pull-request pipeline, make it block a deliberately introduced harmless finding, remediate the finding, and record the exception/remediation evidence.

Before you begin

Use a disposable repository and scanner test fixture or a fake provider-approved token pattern. Never commit a live token, private key, customer data, malware, or intentionally exploitable production code.

Do

1. Enable dependency and secret scanning supported by the training platform, or configure an approved test scanner in the pipeline.
2. Add a policy that fails the pull-request check only at the documented threshold, for example a deliberately introduced lint/security test fixture or known test dependency.
3. Protect the default branch with the check.
4. Write a short exception template: owner, affected component, severity/evidence, compensating control, expiry, and remediation issue.

Verify

Capture the failed check, relevant finding, branch-protection result, corrected passing check, and the issue or exception record. Explain why the threshold, a scanner result, and a deployment approval are different controls.

Break and fix

1. Introduce the safe test finding. Confirm the gate blocks merge.
2. Temporarily make the threshold so broad that the finding passes. Explain the risk and restore the documented threshold.
3. Remediate the finding or apply a time-bound documented exception, then prove the workflow behaves as designed.

Scenario practice

1. Configure: Choose a scan type, blocking threshold, branch-protection rule, and exception owner for a repository handling a public web service.
2. Diagnose: A scan reports a finding but the pull request can merge. Which evidence distinguishes a scanner alert, a failed check, and a required branch-protection status check?
3. Distinguish: Contrast remediation, a time-bound risk acceptance, a false-positive dismissal, and a deployment approval.

Clean up

Delete the training repository, test dependency, test token fixture, exceptions, and notification integrations that are no longer required.

Sources and re-audit

• GitHub code scanning, secret scanning, and required status checks, checked 2026-08-22.

Re-audit when the selected scanning product, branch-protection checks, exception policy, or GitHub security feature availability changes.

Related

github-advanced-security · secret-scanning · dependency-vulnerabilities · compliance-gate · All labs