A dependency scan warns of a vulnerable library several hours before the release. The developer finds a solution, but it might affect some working features, and security and operations teams wait for approval to take any action. The end-of-line race against the clock to finalize releases is well known to teams that postpone security decisions to the final hours of a release. DevSecOps teams can streamline such processes by establishing protocols and providing feedback as the work progresses. This article discusses the location and responsibilities involved in making such determinations and decisions and examines approaches to negotiating releases in the presence of an unresolved security problem. Why the Final Security Gate Slows Everyone Down It is a difficult situation, however, to discover that a design choice needs to be changed. Late findings also raise new questions that should have been asked earlier. Should the developer be expected to investigate every scanner finding? Can t...
The control that held your infrastructure together was plan review, meaning a person reading a diff and deciding whether to approve it. Not the policy document and not the pipeline configuration. It worked because change arrived at human speed. That condition no longer holds. An agent opens 40 pull requests before lunch. Reviewers approve them to clear the queue. The approval requirement is still declared in the workflow file, still blocking the merge, still writing an audit event, and no longer doing its job. Nothing removed plan review. Change volume saturated it. A saturated control emits the same signals as a working one. What Plan Review Was Actually Doing The approval action performed four distinct functions. Nobody designed that bundle; it accumulated over time, with a required reviewer after an outage and a checklist after an audit, each attaching to the action already in the workflow. Policy compliance: Does the change conform to the rules the organization agreed to? Bl...