Security scanning not in the pipeline

What this looks like

A feature is developed, tested, and declared ready for release. Then someone files a security review request. The security team, typically a small centralized group, reviews the change against its checklist. The team finds a SQL injection risk and two outdated dependencies with known CVEs. It also finds a hardcoded credential that someone committed six months ago and forgot.

The release is blocked. The developer who added the injection risk has moved on to a different team. The credential has been in the codebase long enough that no one is sure what it accesses.

This is the most common version of security as an afterthought: a gate at the end of the process that catches real problems too late. The security team is always understaffed for the volume of changes flowing through the gate. Its members develop reputations as blockers. Developers learn to minimize what they surface in security reviews and treat findings as negotiations rather than directives.

The security team hardens its stance. Both sides entrench.

In less formal organizations the problem appears differently: there is no security gate at all. Vulnerabilities are discovered in production by external researchers, by customers, or by attackers. The security practice is entirely reactive, operating after exploitation rather than before.

Common variations:

• Annual penetration test. Security testing happens once a year, providing a point-in-time assessment of a codebase that changes daily.
• Compliance-driven security. Security reviews are triggered by regulatory requirements, not by risk. Changes that are not in scope for compliance receive no security review.
• Dependency scanning as a quarterly report. Known vulnerable dependencies are reported periodically rather than flagged at the moment they are introduced or when a new CVE is published.

The telltale sign: the security team learns about new features from the release request, not from early design conversations or automated pipeline reports.

Why this is a problem

Security vulnerabilities follow the same cost curve as other defects: they are cheapest to fix when they are newest. A vulnerability caught at code commit takes minutes to fix. The same vulnerability caught at release takes hours - and sometimes weeks if the fix requires architectural changes. A vulnerability caught in production may never be fully fixed.

It reduces quality

When security is a gate at the end rather than a property of the development process, developers do not learn to write secure code. They write code, hand it to security, and receive a list of problems to fix. The feedback is too late and too abstract to change habits. Consider a developer who has never seen a SQL injection attack. To that developer, “use parameterized queries” means something different than “this specific query on line 47 allows an attacker to do X.”

Developers often fix release-time security findings incorrectly. They work under time pressure and do not fully understand the attack vector. A superficial fix that resolves the specific finding without addressing the underlying pattern introduces the same vulnerability in a different form. The next release, the same finding reappears in a different location.

Dependency vulnerabilities compound over time. A team that does not continuously monitor and update dependencies accumulates technical debt in the form of known-vulnerable libraries. The longer a vulnerable dependency sits in the codebase, the harder the upgrade. Over time the dependency gains more dependents, more integration points, and more behavioral assumptions built on top of it. What would have been a 30-minute upgrade at introduction becomes a week-long project two years later.

It increases rework

Late-discovered security issues are expensive to remediate. A cross-site scripting vulnerability found in a release review requires not only fixing the specific instance but auditing the entire codebase for the same pattern. An authentication flaw found at the end of a six-month project might require rearchitecting a component. The flawed assumption was the foundation of that component.

The rework overhead is not limited to the development team. Security engineers must re-review the fix, and project managers must reschedule release dates. Sometimes legal or compliance teams must assess exposure. A finding that takes two hours to fix may require 10 hours of coordination overhead.

The batching effect amplifies rework. Teams that do security review at release time tend to release infrequently to minimize the number of security review cycles. Infrequent releases mean large batches. Large batches mean more findings per review.

More findings mean longer delays. The delay causes more batching. The cycle is self-reinforcing.

It makes delivery timelines unpredictable

Security review is a gate with unpredictable duration. The review time depends on the complexity of the changes, the security team’s workload, and the severity of the findings. It also depends on negotiation over which findings must be fixed before release. None of these factors are visible to the development team until the review begins.

This unpredictability makes release date commitments unreliable. A release that is ready from the development team’s perspective might sit in the security queue for a week. Then the security team sends it back with findings that require three more days of work. The stakeholder who expected the release last Thursday receives no delivery and no reliable new date.

Development teams respond to this unpredictability by buffering. They declare features complete early and use the buffer to absorb security review delays. Buffering is a reasonable adaptation to an unpredictable system, but it means development metrics overstate velocity. The team appears faster than it is.

Impact on continuous delivery

CD requires that every change be production-ready when it exits the pipeline. A change that has not been security-reviewed is not production-ready. If security review happens at release time rather than at commit time, no individual commit is ever production-ready. The CD precondition is never met.

Moving security left makes security a property of every commit rather than a gate at release. That shift is a prerequisite for CD in any codebase that handles sensitive data, processes payments, or must meet compliance requirements. Automated security scanning in the pipeline is how you achieve security verification at the speed CD requires.

The cultural shift matters as much as the technical one. Security must be a shared responsibility - every developer must understand the classes of vulnerability relevant to their domain and feel accountable for preventing them. A team that treats security as “the security team’s job” cannot build secure software at CD pace, regardless of how good the automated tools are.

How to fix it

Step 1: Inventory your current security posture and tooling

1. List all the security checks currently performed and when in the process they occur.
2. Identify the three most common finding types from your last 12 months of security reviews and look up automated tools that detect each type.
3. Audit your dependency management: how old is your oldest dependency? Do you have any dependencies with published CVEs? Use a tool like OWASP Dependency-Check or Snyk to generate a current inventory.
4. Identify your highest-risk code surfaces: authentication, authorization, data validation, cryptography, external API calls. These are where automated scanning generates the most value.
5. Survey the development team on security awareness: do developers know what OWASP Top 10 is? Could they recognize a common injection vulnerability in code review?

Expect pushback and address it directly:

Step 2: Add automated security scanning to the pipeline

1. Add Static Application Security Testing (SAST) to the CI pipeline - tools like Semgrep, CodeQL, or Checkmarx scan code for common vulnerability patterns on every commit.
2. Add Software Composition Analysis (SCA) to scan dependencies for known CVEs on every build. Configure alerts when new CVEs are published for dependencies already in use.
3. Add secret scanning to the pipeline to detect committed credentials, API keys, and tokens before they reach the main branch.
4. Configure the pipeline to fail on high-severity findings. Start with “break the build on critical CVEs” and expand scope over time as the team develops capacity to respond.
5. Make scan results visible in the pull request review interface so developers see findings in context, not as a separate report.
6. Create a triage process for existing findings in legacy code. Based on severity, tag each finding as accepted risk with justification, add it to a remediation backlog, or fix it immediately.

Expect pushback and address it directly:

Step 3: Shift security left into development

1. Run security training focused on the finding categories your team most frequently produces. Skip generic security awareness modules; use targeted instruction on the specific vulnerability patterns your automated scanners catch.
2. Create secure coding guidelines tailored to your technology stack - specific patterns to use and avoid, with code examples.
3. Add security criteria to the definition of done. Include no high or critical findings in the pipeline scan and no new vulnerable dependencies. Require secrets management through the approved secrets store.
4. Embed security engineers in sprint ceremonies - not as reviewers, but as resources. A security engineer available during design and development catches architectural problems before they become code-level vulnerabilities.
5. Conduct threat modeling for new features that involve authentication, authorization, or sensitive data handling. A 30-minute threat modeling session during feature planning prevents far more vulnerabilities than a post-development review.

Expect pushback and address it directly:

Measuring progress

Related content

• Pipeline architecture - design the pipeline stages that include security scanning
• Deterministic pipeline - security scans must produce reliable, repeatable results to be trusted
• Compliance interpreted as manual approval - automated security controls support the case for replacing manual compliance gates
• Separation of duties as separate teams - related pattern where security review creates organizational walls
• Single path to production - security scanning in the single path ensures every change is verified