In the early months of 2026, three separate incidents made their way through security circles and engineering Slack channels alike.
Axios, a tool so widely used that it's tucked inside more than 100 million software installations every week, got hijacked for a few hours and used to deliver malware to anyone who happened to install it during that window. Around the same time, a breach touching Trivy, a popular tool teams use to scan their software for weaknesses, rippled outward. It eventually reached Mercor, where it exposed 4TB of internal data including contractor records, and separately gave attackers access to hundreds of private code repositories inside Cisco's development environment.
Different companies, different tools, different teams, and yet the same root cause ran through all three: Someone had access they shouldn't have had.
For anyone who works in logistics, this should sound familiar even if the technology isn’t. A compromised credential behaves a lot like a stolen keycard at a distribution facility. The lock itself was tightly secured — the problem was that the wrong person ended up holding a working key.
Most development teams would never skip a code review. It's baked into how software gets built: Someone writes code, someone else checks it, and a flawed change gets caught before it ships. That discipline runs deep.
Credentials rarely get the same treatment. A small team often shares one login to a package library because setting up individual accounts felt like overhead nobody had time for. A deployment script, the small program that pushes new code live, holds a password written in plain view because it was the fastest way to get something working at 11 p.m. before a deadline. None of this comes down to carelessness. Teams are optimizing for shipping speed, which is exactly what they're supposed to do, all while credential management becomes someone else's problem for another day.
The trouble shows up once that "someone else's problem" gets exploited. A single login almost never opens just one door. Whatever that account was trusted with, a code repository, deployment pipeline and cloud server comes along with it. When that happens, the damage moves outward, riding every connection that account had built up over time.
What makes the 2026 incidents worth paying attention to is that they all happened in similar ways, against similarly well-resourced teams. At some point, a pattern like that stops being a string of bad luck. It becomes a predictable category of risk. And once a risk is predictable, a small team can plan for it.
Plenty of dev teams already do the right things on the code side. They keep an inventory of every component in their software, often called a software bill of materials (SBOM), and they lock dependencies to specific, tested versions rather than letting them update automatically. Both of these are genuinely good practices.
But think of an inventory list the way a warehouse manager would. Knowing exactly what's sitting on every shelf doesn't stop someone with a stolen badge from walking in and rearranging things overnight. The list tells you what should be there. It says nothing about who's allowed to change it.
That's the missing piece. Locking software components to specific, tested versions, and keeping a full inventory of what's inside a piece of software tells a team what's running, but not who can still get in and change it tomorrow. Closing that distance means building something underneath those practices. Every dev team needs a clear and deliberate sense of who holds the keys and how easily those keys could end up somewhere they shouldn't.
Tackling these vulnerabilities won’t necessarily require an enterprise-level security budget, nor even a dedicated hire. Most of it comes down to a handful of habits, the kind any team can start putting in place this week:
Shorten how long credentials live. A login or API key that never expires is a gift to anyone who manages to steal it. Access that automatically expires after a few hours or a day shrinks that window dramatically. Many platforms now offer this kind of short-lived access as a built-in option; someone usually just needs to turn it on.
Look at who genuinely needs access to what. It's common for everyone on a small team to share broad permissions because it's simpler to set up that way. Giving each person, and each automated tool, only the access their specific job requires keeps a small mistake from turning into a large one. A script that automatically pushes new code live shouldn't also be able to erase a company's live database.
Get secrets out of plain text. Passwords, API keys and other login credentials left unprotected in a settings file or code repository are visible to anyone who gains even brief access. A password manager or basic secrets vault keeps that information locked away, and there are accessible options built specifically for small teams without a dedicated security budget.
Build a rotation habit. Credentials shouldn't only get changed after something goes wrong. A recurring reminder to rotate keys and passwords on a set schedule, even a quarterly one, catches a stolen credential before anyone gets the chance to use it.
Know who can publish, push or deploy code to a live server, and review that list every so often. Team members change roles, contractors finish projects, and access that made sense six months ago often outlives its usefulness until someone checks.
Software supply chains will keep growing more interconnected, and that's not a reason for alarm. It's simply the direction the industry is moving, and it means credential discipline is becoming as routine and expected as code review already is.
The teams that build these habits now, while it still feels optional, are the ones least likely to spend next year explaining a breach to their customers. Treat access with the same seriousness given to the code itself, and the rest of the work gets considerably easier.
Chris Skipworth is chief executive officer of Passpack.
