Security testing for a product happens only in a two-week window before each release, and late findings repeatedly delay launches. Leadership wants most code vulnerabilities found within hours of the code being written. What DevSecOps change addresses this?
Select an answer to reveal the explanation.
Short Explanation
Finding a bug the day you write it is like catching a wrong turn at the first intersection instead of fifty miles later. Shifting left puts SAST and SCA into CI so every commit gets checked automatically. The trap is any answer that just moves or stretches the big test at the end — that's still late.
Full Explanation
Shift-left security moves testing earlier in the software development lifecycle so defects are found when they are cheapest to fix. In practice that means running static application security testing, which analyzes source code for insecure patterns, and software composition analysis, which identifies vulnerable or risky open-source dependencies, automatically in the CI pipeline on each commit or pull request. Developers receive findings within minutes of writing the code, fix them while the context is fresh, and the release no longer waits on a late batch of discoveries. Lengthening the pre-release window keeps testing at the end and makes delays longer rather than eliminating them. Moving testing into production with a bug bounty exposes customers to vulnerabilities and shifts discovery even later, which is the opposite of the goal. A quarterly external penetration test is valuable as independent validation but is periodic and late, so it cannot deliver findings within hours of code being written. Exam caveat: shift left does not remove later testing; DAST, penetration tests and runtime protection still add coverage that code analysis cannot. Operational check: confirm the CI pipeline runs SAST and SCA on every pull request, that findings appear in the developer's review, and that the mean time from commit to finding is measured in hours.