Attackers are increasingly focusing less on finished software and more on the systems used to build it. They go after it while it is still being assembled, planting malicious code in open source dependencies, build pipelines, and source code repositories before a single product ships. That change in tactics shows up clearly in the numbers. Software supply chain attacks have run at more than twice their earlier pace since April 2025, averaging 28 incidents a month against roughly 13 a year before. The target is no longer the locked door at the end of the process. It is the unlocked workshop where the software gets built.
Vatsal Gupta has spent more than 13 years building the systems that decide who, and what, can reach an organization’s most sensitive resources. A Senior Security Engineer focused on identity and access management, he designs access governance for the source code infrastructure of one of the largest technology companies, an environment where engineers once obtained repository access with little approval and kept it long after they needed it. He is a Senior Member of the IEEE, and his work sits on a problem the wider industry is only now confronting: the repositories and pipelines behind modern software have become a favored target precisely because access to them went unchecked for years.
The Access Layer Nobody Was Watching
For most of the past decade, software development environments grew faster than the controls meant to govern them. Teams spun up repositories, added collaborators, and granted permissions to keep projects moving, and almost none of that access was ever reviewed or removed. The result was a quiet accumulation of standing access across the exact systems that produce a company’s software. Each new repository became one more place where access could be granted quietly and forgotten just as quietly. Attackers understand the value of that workshop, because reaching the source gives them a path to everything built downstream.
Gupta led the design and delivery of an enterprise-wide access governance platform for source code repositories, built to replace a model that had no real governance at all. Before the work, developers could request and retain repository access without structured approval, review, or automatic removal, including access to confidential projects. The platform he architected enforces least privilege through scoped access templates, structured approval workflows, automated provisioning, and automated revocation when someone changes roles or leaves. It also closed a gap where any repository administrator could grant access to sensitive projects with no oversight, and it replaced a manual, periodic access review with an automated, audit-ready process.
“The hardest problem in access is not granting it. It is taking it back,” Gupta says. “Most organizations are very good at saying yes and almost incapable of saying no once the work is done.”
Least Privilege as the Control
Most of the access organizations hand out is never used. Across cloud environments, only about 8% of granted permissions are ever exercised, while the remaining 92% sit dormant. Every one of those unused permissions is a path an attacker can take once a single account is compromised. Least privilege is the practice of closing those paths before they can be exploited, granting each person and system only what the task in front of them requires.
Putting that principle into practice across thousands of teams is where most programs stall. Gupta’s approach centered on access templates that map cleanly to real engineering roles, so that requesting the right level of access is faster than over-requesting. Approvals route automatically to the people accountable for each resource, and access expires or is revoked through the lifecycle rather than lingering by default. The model also treats access as something that should lapse on its own rather than persist, so the environment trends toward least privilege over time instead of drifting away from it. The design goal was to make the secure path the path of least resistance, so developers move faster, not slower, under tighter control.
“Security that fights the developer loses,” Gupta explains. “If the governed way to get access is slower than the ungoverned way, people will route around you, and you have made the problem worse.”
From Engineering to Standards
Identity and access management has grown from a back-office function into one of the central problems in security. As organizations adopted Zero Trust models, the question of who can do what, on which system, and for how long moved to the front of every architecture review. The people solving it in practice increasingly carry that work into professional institutions and standards bodies, where the controls one company builds become patterns the whole industry can adopt.
Gupta is part of that wider effort. He recently wrote a peer-reviewed piece for IDPro on applying least privilege to the software supply chain, arguing that the systems producing modern software have become a favored target because access to them went unchecked for years. Alongside his enterprise work, he contributes to industry groups developing modern authorization and identity governance practices, bringing problems he has solved on real systems into the guidance other teams will build against.
“Standards are where good security stops being one team’s secret and starts being everyone’s default,” Gupta notes. “The work only matters at scale if it outlives the system you first built it for.”
The Hard Part Is Migration
Designing least privilege on paper is straightforward. Retrofitting it onto systems that thousands of people already depend on is not. The moment a governance program touches live access, it risks breaking the workflows that keep engineering moving, and a control that interrupts shipping rarely survives contact with a deadline. The difficult engineering is in the transition, not the target state.
Gupta’s largest challenge was migrating a sprawling base of existing, ungoverned permissions into a structured model without disrupting active development. That meant sequencing the rollout carefully, preserving the access people genuinely needed while stripping what they did not, and building specific controls for the most sensitive projects first. He also built a migration path for permissions that had never passed through a formal approval process, mapping each one to a defined role or removing it outright. His perspective is informed by work beyond his own systems, since he reviews submissions for the IEEE/ACM Secure Development Conference, evaluating how other practitioners build security into software from the start.
“You cannot flip a switch on access governance in an environment this large,” Gupta observes. “You earn it permission by permission, and the goal is for most people to never notice the change.”
What Comes After the Repository
The cost of getting this wrong keeps rising. Global losses from software supply chain attacks are projected to reach $60 billion in 2025, and the trend lines point upward rather than down. Source code repositories are only the first layer. Every tool in the software development lifecycle, from build systems to package registries to the automated agents now acting inside pipelines, presents the same governance question.
Gupta’s current focus is extending the same governance model beyond repositories to the rest of the development toolchain, so that access is requested, approved, and revoked the same way no matter which system it touches. The harder frontier is non-human access. Automated systems and AI agents are increasingly granted broad, standing permissions to do narrow jobs, and they rarely fall under the reviews built for human users. Bringing those identities under least privilege is, in his view, the next version of the problem he has already solved once.
“We spent years assuming the people inside the building were safe and the threat was outside,” Gupta reflects. “The work now is to assume nothing, check everything, and make that the easiest way to operate. Access should be a decision, not an inheritance.”
