How tooling consolidation can help Dev and Sec work together
One underappreciated aspect of developer and security team friction is tool sprawl. See why it makes security enforcement and visibility so hard and learn how you can fix it.
Many organizations invest considerable resources in forging a strong security culture, one that prizes training, audits, incident response and software testing, and “active listening” in the belief that cross-team communications matter. Yet, these measures haven’t harmonized Dev and Sec teams. Ask around, and you’ll find the hallmarks of misalignment: inconsistent tooling, unfollowed security practices, security vulnerabilities, patch failures, cloud misconfigurations, and identity theft.
Despite rising investment in security, the finger pointing between Dev and Sec teams around responsibility and accountability continues mostly unabated. In short, Sec teams want Devs to get serious about security, and they want software tools with guardrails that prevent Devs from ignoring security best practices. In turn, Devs resist these efforts, complaining that security procedures are cumbersome and impair their speed with the onus for compliance left solely in their laps — adding further stress to their cross-team interactions.
While culture is important, software eats culture for breakfast. What really moves the needle for improving speed, safety, and Dev/Sec relations is workflow standardization and well-crafted guardrails, with modern, battle-tested tools that nudge teams toward better software delivery practices. The best way forward for organizations struggling with the balancing act between Dev and Sec is to start with tooling consolidation with the help of a platform team.
» The case for consistent tooling
The first step in a tooling consolidation initiative is to get managers and executives. It shouldn’t be too hard since 50% of CISOs are already asking for tool consolidation from their teams. The only thing teams have to do is make the case for consistent tooling. So here’s the story teams should start with:
For years, many organizations have allowed Dev and Sec teams to go their own way and choose their preferred solutions. Amid a prolonged shortage of security skills, the thinking went: “Why not prioritize comfort and familiarity? We don’t want to lose scarce talent.” The same argument has also applied to Dev tool preferences. However, this decentralized decision-making led to an unintended consequence: Tool sprawl and fragmented processes.
» The challenge
Armon Dadgar, HashiCorp Co-Founder and CTO has a good explanation for why that’s bad:
“I think the challenge in this model almost inevitably is 12 months, 18 months, 24 months into this, what we end up seeing is everything you'd expect:
- You have cost overruns because every team's doing it their own way. Nobody's paying attention to spinning down dev instances. Things are oversized.
- You have security vulnerabilities all over the place because the application teams are really focused on their applications. They're not really thinking about some of the Day 2 concerns: ‘Did I actually define my security groups correctly? Did I set the S3 bucket to private only?’
- Then you have all sorts of compliance challenges. As a security and compliance organization, there's no easy way to partner to solve those problems because every team is solving it their own way.
So you have a hundred app teams doing it a hundred different ways, and you have one security team, one compliance team trying to herd the cats.”
This “wild west” situation makes it incredibly hard to enforce security guidelines across an organization, and it makes it virtually impossible to audit compliance and security across so many different tools.
At many organizations, the pendulum is swinging back toward a unified solution.
» The solution
“When I look at it, I feel we are using far too many tools,” noted Harsha Vathsayayi, a product manager at Roche Informatics, a division of the world’s 5th largest pharmaceutical company. Vathsayayi determined that “too many tools negatively impact developer experience, which in turn decreases development.”
He believes that tool sprawl can lead to a breach. “When we talk about tool sprawl or shadow IT, we often see multiple instances of tools running on a developer laptop or a VM that no one knows about,” explains Vathsayayi. “We see there are a lot of attack surfaces because those tools are not developed as per organization guidelines. No one is scanning them, and no one knows what they're running, which means for a hacker, it's a large attack surface.”
Secret management was an initial focus of tool consolidation. The Roche Informatics team chose HashiCorp Vault Enterprise to satisfy many use cases with one tool:
- A central identity broker for credentials across the organization
- One unified secrets management and auditing platform
- Encryption as a service at rest and in transit
- Internal public key infrastructure (PKI)
Then, it adopted HashiCorp Terraform to standardize infrastructure automation and “provisioning on-prem, cloud, and even edge resources.” With one tool they now have:
- One auditable pipeline for fast, automated application infrastructure provisioning
- A platform and repository for building and reusing secure-by-default modules and configurations
- A policy as code checks and guardrails system (for enforcing security, cost, and reliability best practices)
Vathsayayi believes their tool consolidation paid organizational dividends. “If [developers] have too many tools, a lot of their precious time goes to context switching.” He advises: “Try to reduce the amount of tools and move towards common platforms or a centralized platform to improve the developer experience and also enhance productivity for the organization.”
» Consolidated platforms are difference-makers
Taming tool sprawl not only saves resources, it also reduces workflow complexity. With consistent tooling and automation, security teams waste less time and resources on audits, reviews, and fixes to code that should have been secure and compliant in the first place before moving to production.
» Best practices for platforms
A platform-based approach should leverage APIs, automated checks, and guardrails to prevent bottlenecks caused by manual reviews from Sec, Ops, or compliance teams, while ensuring security best practices are in place.
A modern platform can prioritize cloud security and the developer experience at the same time, establishing a secure and consistent workflow that supports all teams in the delivery pipeline — providing templates that empower even junior developers to become highly productive and secure on Day 1, and allowing all teams to focus on their expertise areas.
Organizations should consider tools and products that excel at these functions:
- Version control tooling
- Static and dynamic scanning tools
- Secrets management platforms
- Secret scanning tools
- Infrastructure provisioning platforms with built-in policies as code engines
- Secure remote access tools.
With tool and process consistency, you get smoother Dev and Sec workflows. That’s the objective of well-managed security and infrastructure lifecycles, and it ultimately leads to operational consistency across your infrastructure estate.
» Learn more
Read our white paper or attend our upcoming webinar to find out how tool consolidation fits into our bigger platform engineering strategy aimed at solving the friction between developers and security teams.
Sign up for the latest HashiCorp news
More blog posts like this one
HashiCorp 2024 year in review
The future looks bright as we look back at what we and our customers accomplished this year.
HashiCorp Ambassador call for submissions 2025
The submission window for HashiCorp Ambassador — our program to recognize individuals for knowledge sharing, mentorship, and kindness in the community — is now open.
Vault integrations with MongoDB, Private Machines, and walt.id strengthen customer security
Three new HashiCorp Vault ecosystem integrations extend security use cases for customers.