Hey folks, I'm reaching out because our company develops software that we often have to deploy directly onto our customers' AWS accounts or their own on-premise setups. We're having a tough time figuring out how to safeguard our source code since it ends up on infrastructure that our customers control.
Initially, we ran our Python applications on their EC2 instances, but it didn't offer much security because the customers could easily access the source code. We looked into techniques like obfuscation and using `.pyc` files, but they didn't seem secure enough due to how easily they can be reverse-engineered.
Currently, we're using distroless Docker images stored in our private ECR, which we run as ECS tasks in the customer's environment. This way, only the ECS service has the permissions to pull the images, and since the containers are distroless, customers can't execute commands to view the code. However, we realize this is not a foolproof security measure, as it depends on specific ECS behaviors. Also, this approach doesn't hold up with EKS—where customers can attach debug containers—and it's not suitable for on-premise deployments.
It's worth noting that while we do have a SaaS option, many customers have strict regulatory requirements that mandate they keep everything within their own infrastructure. So, I'm looking for advice on better, more portable ways to secure our source code in these scenarios. What methods do you use to protect your codebase when it's on environments you don't control?
3 Answers
Have you looked into using GraalVM? It could be a potential solution for your case. You could construct a viable deployment using graalpy along with containerization to protect your source code.
I'm guessing you need the software on their setup because it processes data from their infrastructure. Have you considered modifying your software to deploy just a thin client there? The client could gather necessary data and send it back via API to your backend, which means customers wouldn't have access to your IP, just the outputs.
Some of our clients have policies that don’t allow any data to leave their servers, even for their internal processes. So that might not be a feasible option for everyone.
It’s always a challenge to protect your code on customer infrastructure. Historically speaking, once customers have direct access, it’s nearly impossible to fully secure your code. The aim should be to make access to it difficult enough that it’s not worth their while. For some of our clients, hosting apps through our account isn’t an option—especially in government-related cases. They want to keep things on their side for various strategic reasons, even if the documentation permits it.
I'd agree. It sounds like you’re already aware that true security is tough here. The goal is about making it hard enough to deter unauthorized access.
Thanks for suggesting that! I think GraalVM plus container integration could really work for us.