Can we Improve on Software Supply Chain Security With IP Restriction?

Nathan Naveen Mar 17, 2026

What happens if we miss a vulnerability? How can we make sure it doesn't exfiltrate all of our data?

The Problem

What is the point of software supply chain security? Software supply chain security primarily focuses on ensuring we upgrade our dependencies to versions that have been patched for known vulnerabilities.

If a malicious actor uses a vulnerability that affects us, they can do three things. One, they can exfiltrate secrets, user data, and proprietary data. Two, they can encrypt your databases (etc) and ransom them back to you. Third, they could inject a malicious script into your code.

The issue with software supply chain security is that we might miss a vulnerability or two. A vulnerability might not be reported, or we might be a bit slow on implementing a patch/dependency update. That is why we created Bomfather as a last line of defense.

Up until now, Bomfather has had solutions for malicious actors encrypting your databases to ransom or injecting malicious scripts into your code, but we didn’t know how to deal with a malicious actor exfiltrating data. That is why we have implemented our IP protection.

The Solution

Imagine that our secrets are stored in a database and that every executable except for a couple of trusted ones is malicious. How can we make sure that only our trusted executables can access the external database?

To solve this, we decided to implement IP protection. This limits which IPs/DNSs an executable can access, and which executables can access an IP/DNS. If a malicious actor can’t access your DB, then they can’t steal your secrets.

All security provided by Bomfather is implemented using eBPF. We secure IPs by hooking into lsm/socket_connect. We restrict both IPs and DNS addresses. For a specific executable, we can restrict what IPs it can access. And we can stop every other executable from accessing the IP.

The Difference between this and a Firewall

Traditional firewalls usually enforce traffic rules at the host or network boundary. If multiple executables run on the same host, they often share the same network policy. Instead, this solution is restricted to the executable level.

An Example of How this Works

We have been talking very theoretically, so this might be easier to understand with an example.

Imagine that we have a KMS, and only a signer should be able to access it. We can attach two restrictions to the signer. Only the signer can access the KMS. And, the signer isn’t allowed to access any IP other than the KMS.

This works by allowing the signer to access the KMS and ensuring that no one else can.

We can take this example up a notch. If a malicious process modifies the signer then it can access the KMS, and exfiltrate data. To solve this, we can use fs-verity to sign the binary and only allow the unmodified signer to access the KMS (Read a bit more about this in our blog post about securing builds with fs-verity).

Conclusion

In the end, this is a huge step forward in supply chain security since there is always the chance we miss a vulnerability, and if we do so, we need a way to make sure it can’t steal anything valuable!

All of our blog posts are also available on Substack. Subscribe to get new posts delivered to your inbox!