August 26, 2024
Back to blog
August 13, 2025
Your software isn't built in isolation. Every application, every system, every piece of code your company relies on is part of an intricate web of dependencies that many organizations barely understand. And that web is more fragile than you think.
We sat down with Niels Ingi Jónason, a security engineer who's seen this problem from multiple angles. At Syndis, he performed pentests, at Lacework, he was part of the internal security team protecting the company. Now, as co-founder of Icelandic cybersecurity consultancy Ambaga, he's helping other companies wake up to threats they never saw coming.
What your development team isn't telling you
Picture this scenario: One of your developers needs to solve a problem. They find an open-source solution on GitHub, add it to your codebase, and move on. That decision just made a complete stranger part of your business infrastructure.
"You have an engineer on your team that has an issue they have to solve and they quickly discover that somebody else has already solved the issue and made it open source," Níels explains. "That engineer makes the decision, okay, I'm just gonna use this tool. And that's just some random person somewhere in the world, who then has full control of that software and is now a part of your supply chain."
This isn't theoretical. Your software supply chain includes everything from the text editors your developers use to the Linux distributions running your servers. Each represents a potential entry point for attackers.
Unlike traditional supply chains with clear business relationships and accountability, software dependencies often trace back to individual developers working on passion projects. No contracts. No SLAs. No guarantee they won't decide to sabotage their own code next week.
Technical employees are your biggest risk
Here's something that might surprise you: the technical staff you trust most with security might actually be your biggest targets.
Níels points out that, "The technical people are usually the most interesting people to target and can also be the easiest people to attack. They end up leaking stuff on the public internet or they use a lot of different tools, which you can use as an entry point."
While you're busy training your HR team to spot phishing emails, attackers are targeting the developers who have access to your build systems, your code repositories, and your production environments. They're the ones installing tools, managing dependencies, and pushing code that runs your business.
The attack vectors are everywhere.
Compromised package registries. Hijacked maintainer accounts. Cryptocurrency mining malware. Even geopolitical tensions can turn routine dependencies into security nightmares when developers decide to sabotage their own packages.
How a simple GitHub rename became a security concern
Níels discovered firsthand how easily things can go wrong. He discovered a supply chain vulnerability in our own systems here at Aftra.
When we renamed our GitHub organization from "syndis-software" to "aftra-software," we were just aligning our repositories with our new company name. Standard practice. Nothing suspicious.
But GitHub's forwarding mechanism left a window of opportunity. The old name became available for registration.
Níels registered it within minutes and found that several systems were still pointing to repositories under the old name. He copied all the public repositories to maintain functionality, then added something extra: backdoors in every piece of software.
"I added backdoors into all of the different software," he explains. "It was still the exact same software that you guys had on your open source repositories with the added backdoor, which in this case was just a ping back, just to let me know that it actually worked."
Two days later, his phone buzzed with a notification. The backdoor had been activated in an internal GitHub Actions workflow. He had gained access to Aftra's build process through a perfectly innocent organizational change.
This wasn't due to negligence or poor security practices. We had simply used a standard GitHub feature that most users don't realize creates a security vulnerability. We did everything right and still got compromised.
Fortunately for us, Níels let us know quickly about this issue and it was resolved right away.
Why your typical security playbook won't work
The best cybersecurity focuses on preventing problems before they happen.
- Build secure code.
- Patch vulnerabilities early.
- Block threats at the perimeter.
But supply chain security is different. You can't control every dependency, every maintainer, every package registry. You're building on a foundation you don't own, maintained by people you've never met.
"In many ways it's more reactive security," Níels explains. "How can I make sure to make this as difficult as possible? I can't make it impossible, so I just have to make it as hard as possible for someone to break this part of the chain."
That doesn't mean giving up. It means getting smarter about what you can control. He suggests:
Don't rush to update everything. This sounds counterintuitive, but unless a package fixes a critical vulnerability, consider waiting 24-48 hours. If it's malicious, the community usually catches it quickly.
Automate what you can. Tools like Dependabot can help identify known vulnerabilities, though they'll generate noise you need to manage.
Demand transparency. Ask vendors for Software Bills of Materials (SBOMs).
Remember Log4j? Companies spent weeks figuring out if they were even running the vulnerable code. Don't be caught off guard.
Plan for the worst. Since you can't prevent every supply chain attack, focus on detection and response. Have detailed logs. Know what's running where. Practice incident response.
This is now a boardroom issue
New regulations like NIS2 and DORA are making this personal for executives. Under NIS2, leadership in critical sectors can be held personally liable for cybersecurity failures. Not just financially liable. Personally liable.
As Mikko Hypponen noted at a recent cybersecurity conference here in Iceland: "Companies usually survive a breach, but you (the leadership) won't."
The data backs this up. Leaders of companies hit with major attacks are often forced to step down. The price of not investing in supply chain security isn't just about money—it can cost key people their careers.
But most executives still think about supply chain security in terms of traditional vendor management. They want contracts and SLAs for dependencies that might be maintained by a college student in their spare time.
This is why companies like Ambaga exist. Most organizations can't afford a full-time security engineer, but they still need the expertise.
"We thought, what if they could rent a security engineer?" Níels asks. "Maybe they just need one fourth of a security engineer instead of a full time engineer."
What you can do right now
Start with frameworks like SLSA (Supply-chain Levels for Software Artifacts). They outline specific threats and countermeasures, so you can prioritize based on your resources and risk tolerance.
Make supply chain security part of your company culture.
When security researchers reach out about vulnerabilities, don't shoot the messenger. "Everyone has vulnerabilities and everyone has more vulnerabilities than they know of," he reminds us. Companies that respond well to vulnerability reports not only protect themselves better, they help the entire community learn.
Most importantly, recognize that this isn't a problem you solve once. Supply chain security is an ongoing process that requires both technical measures and organizational commitment.
The question isn't whether you'll face supply chain attacks. It's whether you'll be ready when they happen.
Your software supply chain is already more complex and fragile than you realize. The random developers whose code is running your business don't owe you anything. The packages your systems depend on could disappear or turn malicious at any moment.
That's not fear-mongering. That's reality.
The good news? Now that you know, you can do something about it. Because the cost of preparation is always less than the cost of being caught unprepared.
This article is based on a podcast episode with Níels Ingi Jónasson entitled “Supply chain security: You’re only as secure as the tools you use.”
