Why Traditional IAM Falls Short in the Software Development Lifecycle

Static IAM approaches overlook the massive growth in non-human identity service accounts and contractors. It is less common than many assume for outsourced developers to access an organization’s internal environment, as much of their work is performed externally. But that reality can foster a dangerous assumption: if the work happens outside the organization’s walls, it does not pose risk. In practice, the opposite is often true. 

That code is still your real estate, and you deserve to have a say regarding how it's secured. The recent Schneider Electric breach demonstrates the consequences of failing to properly manage entitlements for service accounts and automated connections: hackers accessed sensitive data by exploiting credentials associated with non-human identities in its development environment, stealing 40GB of data, including 400,000 records with names, emails, and critical project details. 

Shadow IT has also become an enormous challenge, with 30-40% of IT spending in large enterprises and 43% of all business applications now falling into this category. Why? Because developers are paid to push code. They're creating inventory, incentivized to deliver, not to wait for the glacial speed of enterprise procurement. This shadow IT problem is far bigger than most CISOs recognize, and it doesn't matter how much Okta or Saviynt you have if developers are "running their own race" with tools acquired outside official channels. 

Finally, IGA hasn't adapted to the complexity of modern development. Your IGA might handle Salesforce and Office 365 permissions, but what about CircleCI or JFrog? Most enterprise IT organizations don't grasp the complexity and minutia of development tools — runtime environments, container registries, artifact repositories, code repositories, CI/CD pipelines — with potentially 6-7 different types in each category within a given enterprise SDLC. The harsh reality is that most IGAs can manage permissions for only a fraction of these essential SDLC tools. 

The security consequences of overprovisioning

When faced with the time-consuming complexity of managing granular permissions across dozens of development tools, most VPs of Engineering and CTOs opt for the path of least resistance, granting broad administrative privileges to entire engineering teams. It's understandable from a productivity standpoint; nobody wants to be a bottleneck when a critical release is imminent or explain to the CEO why they missed a market window because a developer couldn't access a repository. 

However, when everyone has admin privileges, attackers who gain access to just one set of credentials can do tremendous damage. They gain not just access to sensitive code and data, but the ability to manipulate build processes, insert malicious code, or establish persistent backdoors. This problem becomes even more dangerous when combined with the prevalence of shadow IT, non-human identities, and contractor relationships operating outside your security perimeter. 

The good news? It doesn't have to be this way. More sophisticated approaches to access control that maintain developer productivity while dramatically reducing exposure are emerging. By moving away from the “admin for everyone” approach, organizations can begin to address the fundamental security gaps in modern development environments.

A better path forward: just-in-time permissioning 

The answer to stronger security that doesn’t hinder developer productivity lies in implementing just-in-time permissioning within the SDLC, a concept successfully adopted from cloud infrastructure management that can transform how we handle development access controls. 

The approach is straightforward: instead of granting permanent administrative access to everyone, take 90 days to observe what developers actually need to do their jobs, then right-size their permissions accordingly. For situations where developers need temporary elevated access, implement a chat-based request system through Slack or Teams, for instance, that allows for quick permission elevation with automatic expiration dates. 

This creates a win-win scenario. Developers maintain their ability to move quickly when needed, while security teams dramatically reduce the attack surface. The key innovation is not just the easy elevation of privileges but the automated revocation of those privileges when they're no longer needed. 

Importantly, this approach doesn't require ripping and replacing your existing IAM or IGA investments. These tools remain critical staples for your broader enterprise, handling access and permissions for Office 365, CRM, and ERP systems. What I'm advocating is an additional layer specifically designed for the unique challenges of development environments, where specialized tools like CircleCI, JFrog, and various container registries operate outside the scope of traditional identity solutions. 

For security leaders, the message is clear: your developer force, though potentially a small percentage of your total workforce, manages your most valuable digital assets. The code they write becomes your product, your customer experience, your competitive advantage.

Properly securing this environment requires recognizing its unique challenges and implementing solutions specifically designed to address them. The technology exists today; implementing it is a strategic decision that will pay dividends in both security and development efficiency.