“Security Slows Us Down” and 4 Other AppSec Myths Dev Teams Still Believe

Application security has changed more in the past three years than in the previous decade. Regulatory frameworks like the CRA and DORA are turning vulnerability tracking and SBOM generation into legal obligations. 

And yet, a surprising number of engineering organizations still operate under assumptions that were formed in an era when security scans blocked pipelines, open-source dependencies were a rounding error in the codebase, and when fixing before release was an actual plan. These five myths have long stopped reflecting reality, yet they continue to shape decisions in teams that haven’t revisited them.

 

Myth: “Security scans slow down the pipeline”

Truth: They did, when scans ran synchronously and gated the build. That was a reasonable architecture in 2018. The current standard, documented in the OWASP DevSecOps Guideline and implemented in AWS’s reference DevSecOps pipeline, is to run SAST and SCA as parallel pipeline stages alongside the build. The developer pushes code; unit tests and compilation run in one lane; SAST and SCA run concurrently in separate lanes. A full scan of a large codebase can still take thirty minutes or an hour, but nobody waits for it — results arrive asynchronously to a dashboard or IDE.

For pull requests, teams run lightweight scans on changed files only, reserving deep scans for nightly builds or release candidates. Quality gates block merges only on new critical findings; everything else passes as advisory. The pipeline never stops; the scan runs beside it and speaks up only when something dangerous appears.

What to do: Configure AST tool as a parallel CI stage. DerScanner plugs into GitLab CI, Jenkins, and TeamCity as a non-blocking step; its AI triage (DerTriage) filters up to 95% of false positives, so when a finding does surface, it’s worth the engineer’s time. The IBM 2024 Cost of a Data Breach Report puts the ROI in plain terms: organizations with security automation resolve breaches 98 days faster and save $2.2M per incident.

 

 

Myth: “We barely use open source”

False. The Linux Foundation’s Census III found open-source components in 96% of commercial codebases; a typical application averages around 150 direct and transitive dependencies. Juniper Research projects supply chain attacks against these components will cause $80.6 billion in damages by 2026.

What to do: Run an SCA scan on one project this week. Just one. Look at the dependency tree and count all the components. You might be surprised how many of them developers weren't aware of. 

DerScanner’s SCA generates an SBOM automatically, maps transitive dependencies, scores package health on eight metrics, and flags supply chain specific threats like typosquatting, MavenGate, and starjacking.

 

 

Myth: “Our code passed QA, so it’s secure”

Reality: Log4Shell, December 2021. The Apache Log4j library was present in millions of Java applications, and it passed every functional test in every one of them. It logged messages correctly, formatted output correctly, handled concurrency correctly. CVE-2021-44228 had nothing to do with incorrect behavior: Log4j’s JNDI lookup feature worked exactly as designed, which is what made it a critical remote code execution vector. 

No QA specialist asked if an attacker injected a JNDI string into a log message and executed arbitrary code on the server. Because why would they?

What to do: Accept that QA and security testing answer different questions. QA asks if the software works, SAST asks if it can be exploited, and SCA asks if the components software depends on are safe. Run all of them. 

 

Myth: “We’ll add security before release”

Truth: In 2017, Equifax had two months to apply a patch for CVE-2017-5638 in Apache Struts. Applying it during development would have been a routine dependency update — a few hours of work and a standard regression test. The patch was deferred. The result: $1.4 billion bill.

A vulnerability caught during coding is a line change in a file the developer has open. In staging, the same fix requires context-switching, re-reading old code, and coordinating regression tests. 

 

In production, add: 

• emergency patching, 

• cross-environment deployment, 

• incident communication to customers, 

• forensic analysis, 

• and the opportunity cost of pulling engineers off the roadmap. 

 

What to do: Shift Left. DerScanner’s DerCodeFix generates context-aware code patches alongside each finding with actual fixes in the project’s language and framework.

 

 

Myth: “AppSec is the security team’s job”

Even if the company has a dedicated security engineer or a small AppSec team — the math still doesn’t add up. 1-2 security specialists cannot physically review every pull request, dependency update, and config change produced by a team of fifteen or twenty developers shipping daily. 

What to do: Make security a property of the pipeline. Automated scans on every commit, AI triage that filters noise, and fix suggestions that speed up changes — security team focuses on architecture, threat modeling, and policy, while the repetitive analysis is handled by tools.

 

Every one of these myths was true under older tools and older pipeline architectures. The tools caught up, but the question is whether the assumptions have caught up with them.