4 MIN READ
Picture the modern security stack running on a typical engineering team. SAST on every PR. Dependency scanning on every PR. Secrets scanning on every commit. The intent is sound. The tax lands on whoever has to triage the alerts, fix the false positives, wait for the slow CI, and explain to the product manager why the deploy is two hours late. The cost is real, and most enterprises do not have a line item for it on the security budget.
Here is the part worth knowing. A typical engineering org in 2026 loses 8 to 15 hours per engineer per week to security related work, before any of it is actually a security incident. At a 40 hour week, that is a quarter to over a third of the working time. At a fully loaded cost of 100 to 200 dollars an hour, the tax lands somewhere between 80 thousand and 300 thousand dollars per engineer per year. Real, rarely budgeted, rarely acknowledged.
Where the tax shows up
SAST sits at the top of the list because the time cost is the largest. The static analysis tool runs on every PR, finds 50 to 200 issues per day, and sends a wall of red text back to whoever opened it. Most of the issues are false positives. Most of the rest are non-critical. The few that matter get buried in the noise, and triaging the inbox costs 2 to 3 hours per week per engineer.
Dependency scanning is the second biggest line item. The tool runs on every PR, finds 5 to 20 new vulnerabilities per week, and the upgrade that fixes one often breaks the build that depends on it. The triage cost, the upgrade testing, and the rollback when the upgrade breaks production all land on whoever was supposed to ship the feature.
Secrets scanning costs less in raw time but more in incident response. The tool fires on every commit, the test API keys in the codebase trigger the alert, the engineering lead adds them to the ignore list, the scanner finds the real key later, and they rotate it on a Friday afternoon. The access review sits at the bottom of the list. One to two hours per quarter, four to eight per year, a smaller line item but a real one that nobody schedules properly.
What the typical enterprise has tried
Most enterprises have tried the same three approaches, and most have ended up with the same three failures. The AppSec team owns the whole workflow. They run the tools, triage the alerts, become the bottleneck, and the engineering org waits days for a review that takes them an hour. The engineering team owns the whole workflow. They run the tools, triage the alerts, treat the alerts as noise, and the real issues get missed in the flood. The security org turns the tools off. The security posture drops, a breach happens, the tools come back on, and the cycle starts again. The three approaches together produce the failure pattern most enterprises have not escaped.
How to actually reduce the tax
Tune the tools first, and tune them for the false positive rate. A SAST tool that produces 200 false positives per day is one the engineers learn to ignore, and the real issues get buried in the noise. The same SAST tool configured to produce 5 false positives per day is one they actually read, and 200 real issues are now being seen. The difference is configuration, not coverage.
Automate the remediation second, because the vulnerability that can be fixed by an automated PR is a vulnerability nobody has to triage. The dependency upgrade that lands as a PR, runs the tests, and opens the review is an upgrade that ships. The vulnerability that requires a human to chase the right package version, test the upgrade, and write the migration script sits in the backlog instead. The difference is automation, not effort.
Measure the tax third, because the security org that knows the cost can justify the spend, prioritise the fixes, and make the case for the headcount. Without that number, nobody can tell whether the security stack is a net positive or a net drag on the wider org. The CISO who tunes the tools, automates the remediation, and measures the tax is the leader who reduces the tax without losing the security.
The bottom line
Tune the tools. Automate the remediation. Measure the tax. The developer security tax is not going away in 2026, and the CISO who treats it as a real line item on the security budget is the leader who reduces it without losing the security.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
