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.
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.
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.
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.
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.
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.
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.
The best cybersecurity focuses on preventing problems before they happen.
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.
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.
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.
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.
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.
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.
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.”