4 MIN READ
Here is the tension that nobody has resolved in 2026. The engineer wants the tool that ships, fast, in the IDE they already use. The security side wants the tool that audits, gates, and reports. Both are right. Neither will move. The friction lives between the two functions, and the engineer is the one who has to navigate it every commit.
The 2026 tooling math is rough. Most engineers are already carrying 12+ tools in the workflow (the IDE, the version control, the CI/CD, the test framework, the deployment tool, the monitoring, the secret management, the package manager, the docs, the chat, the project tracker, the design tool). The security function wants to layer on four more (the SAST, the DAST, the SCA, the secrets scanning). Add 8 to 15 minutes per commit, 30 to 60 minutes per pull request, 2 to 4 hours per deployment. The dev experience suffers. The compliance coverage does not catch up. Both sides get worse at the same time.
Where the tension comes from
Speed drives most of it. The engineer wants the fast feedback loop, the security side wants the thorough review, and the two coexist badly inside a single tool. Friction comes next. The security tool wants the explicit approval, the engineer wants the automatic approval, and the two coexist badly inside a single workflow. Visibility rounds out the top three. The engineer wants the local environment, the security side wants the centralised environment, and the two coexist badly inside a single CI/CD pipeline. Metrics sits as the source nobody talks about. The engineer gets measured on shipped features, the security function gets measured on prevented incidents, and the two measures point in different directions. The four together produce the tension the typical company has not resolved.
What the typical org has tried
The security wins approach has been the most common attempt. The security function mandates the security tools, engineers work around them, coverage drops, the security function adds more tools to compensate, the cycle continues. The dev wins approach has been the next most common. The dev side rejects the security tools, the security function loses the battle, the policy gets abandoned, and the company ends up with the security posture of 2018. The one off integration approach has been rarer but more instructive. The two functions get together and integrate the security tool into the dev workflow, the integration works for the one team, the integration does not scale to the other teams, and the integration sits as a one off that does not get replicated. The three together produce the failure pattern the typical company has not escaped.
How to actually resolve it
Treat the dev experience as a first class requirement. The security tool that breaks the engineer workflow ends up as the security tool the engineer works around. The security tool that fits the engineer workflow ends up as the security tool the engineer uses. The first move decides whether anything else matters.
Build the security into the platform. Policy as code, security as code, secure defaults. The security that lives in the platform becomes the security the engineer does not have to think about. The security that lives in a separate tool sits as the security that does not run.
Measure the dev experience and the security together. Whoever gets measured on only one optimises for the one at the expense of the other. Whoever gets measured on both finds the balance. Whoever skips this step owns the failure the first two moves built.
The bottom line
Treat the dev experience as a first class requirement. Build the security into the platform. Measure the two together. Whoever does those three resolves the tension. Whoever does them out of order, or skips the first, owns the failure.
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.
