Development vs. security: The friction threatening your code

Developers are driven to deliver new features quickly, while security teams prioritize risk mitigation, which often puts the two at odds.

61% of developers said that it’s critical that security doesn’t block or decelerate the development process or become a barrier to business success. Despite this, collaboration between development and security teams is essential to strengthen both software quality and security, especially given the rising number of data breaches and ransomware attacks.

For example, the Log4Shell vulnerability, which exposed a critical flaw in a widely used open-source library, showed how a single overlooked issue in the software supply chain can create widespread risk.

Common pain points

In Q1 2025, Sonatype identified 17,954 open source malware packages, showing that attackers are turning their focus to the software supply chain.

In some organizations, security is treated as a final checkpoint rather than a core part of the development process. When problems are found late, it leads to delays, extra work, and tension between teams.

Security teams aim to reduce risk by implementing controls or guidelines that developers often find too complex to put into practice. These rules can feel like obstacles. When the rules are unclear or don’t fit how developers work, they cause frustration instead of help.

“It is common for the security team to run tools adjacent to developer tools and suffer from long feedback cycles,” said Josh Lemos, CISO at GitLab.

Strategies to bridge the divide

Shift-left security approach

Integrate security checks early in the development process, ideally as code is being written or tested, without disrupting workflows. This shift-left approach helps catch issues sooner, reducing the time and stress of fixes later.

Use tools that fit into the workflow

Security tools should work where developers already work, in their code editors, in pull requests, in the CI/CD pipeline. If they’re too slow or confusing, people will ignore them.

Automated tools can check for things like bad dependencies or insecure code. If they’re simple and give useful feedback, developers will use them. This is the basic idea behind DevSecOps, putting security tools into the development process, not around it.

Cross-functional collaboration

When security teams get involved early in the planning phase, they can help identify potential risks before any code is written. At the same time, developers can understand the security requirements from the start, allowing them to make better decisions about software architectures and dependencies.

Try adding security incident retrospectives so teams can discuss issues openly and focus on solutions. The goal is to learn and improve the process rather than point fingers.

Measuring progress

Track key metrics such as time to fix vulnerabilities, number of security issues caught early, tool adoption rates, and policy violation trends. Dashboards displaying these metrics promote accountability across teams, and help identify areas for improvement.

Building secure software without sacrificing speed

Building trust between teams doesn’t happen overnight. Security and speed can go hand in hand. If teams work together from the start, use the right tools, and communicate, they can build secure software without slowing down.

As Karl Mattson, CISO at Endor Labs, noted, “Developers can capitalize today on a series of quite new strategies which significantly better address source code security, and which remove legacy barriers in the way of handling scale and complexity.”