Fast, cheap, good: pick two. That was always the mantra in any design or process. But for software security, does this tradeoff have to exist? I spoke with Moti Gindi, Chief Product Officer at Apiiro about why compromising development velocity for security (or paying out the nose for both) isn’t always the rule for software development organizations.
Ryan Donovan: What is the traditional tradeoff between development velocity and strong security?
Moti Gindi: For years, the traditional mindset assumed a tradeoff: accelerating development velocity meant compromising on security. Manual processes like threat modeling, security reviews, and compliance questionnaires often slowed innovation and deployment, creating this perceived tradeoff. However modern strategies—such as security-by-design, embedding security natively into the developer toolchain, and automation—enable organizations to integrate security into development workflows, proving that productivity and security can advance together without compromise.
RD: There have been a lot of engineering org movements to focus on and systematize security engineering in the “shift left” movement, DevSecOps, and platform engineering. Do these make this tradeoff easier to balance?
MG: Yes, these organizational investments aim to promote methodologies to embed security into the early stages of development, making it proactive and less disruptive. By automating processes with modern technologies and empowering developers with security ownership, risks are identified and mitigated earlier. This reduces the cost and time associated with vulnerabilities downstream while maintaining development velocity.
RD: Does automation make this tradeoff moot or is there still a tradeoff to consider?
MG: On the one hand, automation enabled by GenAI tools in software development is driving unprecedented developer productivity, further emphasizing the gap created by manual application security controls, like security reviews or threat modeling.
But in parallel, recent advancements in code understanding enabled by these technologies, together with programmatic policy-as-code security policies, enable a giant leap in the value security automation can bring. Automating manual processes significantly reduces the friction with development velocity by streamlining processes, minimizing human error, and enabling early prevention and near real-time risk mitigation.
However, it does not entirely eliminate the tradeoff. Initial setup, maintenance, and adapting automation tools to evolving requirements require investment and effort. Additionally, over-reliance on automation without human oversight can miss nuanced or contextual security issues, making a balance of automation and expertise critical.
RD: Automation makes processes faster, easier to perform, and more reliable. However, it takes time to build/test initially and can make it harder (or at least perceived to be harder) to move to something different in the future. What factors do you consider on whether or not something should be automated?
MG: Key considerations include security task frequency, complexity, risk of human error, and the efficiency gains from automation. High-frequency, repetitive, complex tasks critical to security—like security reviews, threat modeling, and risk analysis—are ideal candidates for automation, as they improve reliability, consistency, accuracy, and scalability.
RD: Can automation mitigate supply chain risks via dependencies and vendors?
MG: Automation is an essential element for mitigating supply chain risks, particularly when paired with innovative approaches like the eXtended Software Bill of Materials (XBOM), which enhances visibility by providing a graph-based inventory of application components, their interrelationships, and associated risks throughout the entire development lifecycle.
By leveraging automation tools such as XBOM analyzers, organizations can achieve real-time monitoring and deeper contextual insights into risks associated with third-party dependencies, secrets, sensitive data, and infrastructure configurations. This continuous assessment ensures not only faster remediation but also a more holistic understanding of application and supply chain risks.
RD: What cultural changes do engineering organizations need to make?
MG: Organizations must cultivate a culture that values security as a shared responsibility across all teams. This involves empowering developers with tools and training, encouraging collaboration between security and development teams, and promoting transparency. A security-conscious culture should prioritize enabling teams rather than enforcing rigid controls.
RD: What’s the first step?
MG: The first step is recognizing security as a shared responsibility across the organization, not just a specialized function. Equipping teams with automated tools and clear processes helps integrate security into everyday workflows. Establishing measurable goals and metrics to track progress can also provide direction and accountability. Building cross-functional collaboration between security and development teams sets the foundation for long-term success.
RD: Whenever I see “development velocity” and “cultural changes” together, I tend to wonder at the risk of burnout by adding so many responsibilities to software developers. How can we alleviate that?
MG: Indeed. Especially when security is not a trivial domain and requires context and expertise to be implemented efficiently. The key is automation.
Automation of security controls minimizes manual effort, allowing developers to focus on generating functional code that is secure from the beginning, and stays secure as the application evolves: start-secure and stay-secure. It saves the unexpected crisis derived from high-urgency security incidents discovered in production or the frustration of code being blocked from deployment due to downstream security measures out of the control of the developer. It enables developers to focus on building and creating, to feel empowered rather than overwhelmed.
RD: What are the pitfalls and how have you seen organizations fail to achieve this balance?
MG: A common pitfall is treating security as an afterthought, leading to disruptions that strain teams and delay releases. Conversely, overburdening developers with security responsibilities without proper support can lead to frustration and neglect of critical tasks. Failure to adopt automation or align security goals with development objectives often results in inefficiency and poor outcomes. Organizations that succeed focus on clear communication, balanced priorities, and leveraging tools that enhance both productivity and security.
RD: Management and non-engineering folks can sometimes struggle to fully grasp the benefits of improving systems unless there’s an incident. How can teams get buy-in from the higher-ups to prioritize behind-the-scenes upgrades, the kind of stuff that ends up on tech debt wishlists?
MG: The first step is aligning these initiatives with business goals to ensure leadership understands their strategic value.
But in addition, and many organizations miss that, there is concrete dollar value achieved by automation, secure by design, and embedding security early into the development toolchain. It is the direct outcome of the advancements enabled by these approaches in terms of risk mitigation, cost savings, and developer efficiency. These are measured by clear KPIs, reduced MTTR (mean time to repair), Windows-of-Exposure, production security patches, security-originated production blocks, deployment rates, manual work hours reduction, etc. All of these can be directly translated to a concrete “business case” quantifying the benefits of investments in security automation. An example of such direct dollar savings can be found here.