The state of software in 2025 is in a weird place. There is less software that runs locally without any kind of ads. A lot of software, including games, depends on command servers that could be switched off at any time. Many IoT devices become e-waste after just a few years. A lot of software is getting bricked or hidden behind paywalls. The philosophy of self-reliant software development becomes increasingly compelling. The safest software is software that runs independently. Network isolation provides the strongest defense against supply chain attacks. Software that operates entirely offline cannot:
- Download malicious updates
- Communicate with command and control servers
- Exfiltrate sensitive data
- Receive new attack vectors This approach requires designing systems with network assumptions built-in from the beginning, rather than bolting on network features later.
Runs with Minimal Permissions #
When it comes to cybersecurity, there’s a golden rule that’s deceptively simple yet incredibly powerful, give software only the permissions it absolutely needs to do its job. This “principle of least privilege” isn’t just security theater; it’s your digital insurance policy. Think about it this way: if a hacker manages to break into an app that only has basic user permissions, they’re stuck in a pretty small sandbox compared to if they hijacked something running with admin rights. It’s like the difference between a burglar getting into your guest bathroom versus handing them the keys to your entire house, your car, and your safe deposit box. Plus, when software suddenly starts trying to access files or systems it normally wouldn’t touch, that unusual behavior stands out like a sore thumb making it much easier to spot trouble before it spreads. Linux systems have spent decades perfecting these permission systems for good reason, and smart developers know that working with them, not against them, is the key to building software that won’t become tomorrow’s security nightmare.
Contains No External Dependencies #
Every dependency you add to your project is another potential entry point for attackers. Self contained software avoids this by building everything in-house rather than relying on external packages. This approach eliminates third party risks since you’re not trusting code written by unknown developers who might have different security standards. It also prevents dependency confusion attacks. Those sneaky tricks where attackers upload malicious packages with names similar to popular libraries. When you control your entire codebase, you don’t have to worry about supply chain compromises or the headaches of managing conflicting package versions. Sure, it means more development work upfront, but you get complete visibility into what your software is actually doing and full control over its security posture. Sometimes the safest approach is simply not to trust anyone else’s code in the first place.
The Trade-offs #
Software isolationism comes with significant costs:
- Development Speed: Writing everything from scratch is slower than leveraging existing packages.
- Maintenance Burden: Updates are a problem. Self written code requires ongoing maintenance that would otherwise be community distributed.
Practical Implementation Strategies #
Locally run programs. #
This is the opposite of cloud dependent microservices. Examples include:
- Source code never touches internet-connected machines.
- Dependencies are manually vetted and transferred via isolated media.
- Build systems operate in completely isolated environments.
- Deployment happens through secure, one-way channels.
Minimalist Architecture #
Design software with radical simplicity, I wish all Utilities such as TVs, washing machines etc work on this principle:
- Single-purpose tools that do one thing exceptionally well. I feel a lot of tools can be built from the scratch.
- Minimal codebases that can be fully audited by small teams.
- Standard library reliance rather than external packages.
- Static compilation to eliminate runtime dependency loading.
Cryptographic Verification #
When dependencies are absolutely necessary:
- Cryptographically sign all code and verify signatures before execution.
- Pin exact versions rather than accepting version ranges.
- Maintain local mirrors of critical dependencies.
- Implement reproducible builds to verify package integrity.