Transit mobile-backend pull requests must not merge until security findings are reviewed. Which pipeline enhancement belongs there?
Select an answer to reveal the explanation.
Short Explanation
You want security findings reviewed before transit backend code reaches the main branch, so make a passing scan a merge gate. Green unit tests, reports saved without blocking, and future-fix promises don’t enforce that checkpoint.
Full Explanation
A required security-scanning gate must pass before a transit mobile-backend pull request can merge, ensuring vulnerability findings are reviewed under policy rather than after code reaches a protected branch. This matters because transit app backends handle rider data, credentials, and integrations; blocking merge on scan policy requires remediation or a recorded exception before affected code proceeds. Skipping all scanners and merging when unit tests are green fails because unit tests do not substitute for dependency CVE and SAST checks: passing tests can still accompany critical vulnerabilities. Saving vulnerability reports to a shared team folder after each build, without blocking merges, may preserve information but does not enforce a pipeline control or prevent vulnerable code from merging. Allowing critical findings because the author promises a future fix also fails: a promise is not a control, and without a gate, critical issues can remain in the main branch until an incident. Exam caveat: configure the gate according to severity and municipal risk policy—for example, fail on critical or high findings while routing lower-severity findings to a backlog, without silently ignoring critical issues. Practical check: open a transit backend pull request that introduces a known-vulnerable test dependency or another scanner-detectable issue; confirm that the merge is blocked until remediation or a formal exception is recorded, and verify that scan results are retained with the pipeline run for audit.