For a long time, security in software delivery was a gate. The work got done, and then someone reviewed it for security, and then it shipped or it did not. I think that model finds problems at exactly the moment they are most expensive to fix, and I have come to treat security as part of the pipeline instead.
Why the gate is the wrong place
A gate at the end sees the finished thing. By then the design is settled, the code is written, the tests pass, and there is a date. Anything the gate finds has to be fixed against all of that. The result is predictable: small findings get fixed, large findings get argued about, and the largest findings get accepted with a plan to address them later, which is a sentence I have come to distrust.
The other problem with a gate is who stands at it. If security is something a separate group does at the end, the team that wrote the code learns that security is not their job, and the gate gets busier every year.
What I think belongs in the pipeline
Dependency checks on every change. Not a quarterly scan, a check that runs when a dependency is added or updated and fails the build on a known problem. The question of whether a package is safe to add is a question for the moment it is added.
Secret scanning before anything is committed, or as close to it as the tooling allows. A credential that reaches the repository has already leaked, whatever happens next.
Permissions as code. What a service can reach, what a build can do, who can deploy, written down in files that go through review like everything else. Permissions that live in a console get changed by hand and forgotten.
A hard look at the pipeline itself. The continuous integration (CI) system runs with real credentials and runs code from pull requests, which makes it one of the most interesting targets in the company. What it is allowed to do, and what untrusted changes can make it do, deserves the same review as production.
And the mechanical checks, the linting rules that catch the known-bad patterns, because a rule that fires in the editor is cheaper than any review.
Ownership is the part that matters
I think the checks matter less than who owns them. A pipeline the team runs, understands, and can change is a pipeline the team will keep honest. A pipeline imposed from outside, that fails for reasons the team does not understand, gets worked around, and a worked-around check is worse than none because it reports green.
So my view is that the team owns its security checks the way it owns its tests. A central security group sets the standard and helps. The team runs it.
What a pipeline cannot replace
None of this replaces thinking. A pipeline cannot tell you that the feature you are building should not exist, that the data you are collecting is more than you need, or that the trust boundary you drew is in the wrong place. Those are design questions, and I think they belong at the start, in the design conversation, with someone asking what could go wrong.
The pipeline handles the known problems so that the people can spend their attention on the unknown ones. That division is the point. A gate at the end tries to do both, late, and does neither well.
Photo source: https://photos.robertstowe.com/iguazu-falls