Elixir source code obfuscation

NotQuiteLagom

I’m wondering about the best approach to “obfuscating” Elixir source code that needs to be available for a group of software developers as they need to use the components/functions but just the component API as the internals should be a black box.
I had a recent case of a group leaving the company and taking source code with them.
So, I was thinking…

pre-compiled Deps?
Obfuscating source code like in Javacscript but with the Mix format…
So, if you use a component/modular approach where each component/module has one owner but it’s needed for the global project and developers can customise those components (for example in the presentation layer like a button, but not only) in their code, what would be the best approach.
Thank you in advance!

7 comments

#security

0 1147 7

2022-10-12 01:56:10 UTC

First Post!

Show Best Posts
Show All (oldest first)
Show All (newest first)

cmo

You can give them a service to hit rather than the code. Most things can be decompiled these days.

Lawyers instead?

Post #1

Most Liked

cmo

Sound to me this topic is entirely about creating troubles for yourself

Post #3

mindok

IP protection is an org-level discussion, not just a technical one. Obfuscation is way down the list of things to think about - code is always exposed to being copied, decompiled etc by someone working on the codebase and honestly, the vast majority of the time it really makes no difference.

Really, the focus should be on the “secret sauce” unique to your application (hopefully there is such a thing). Secret sauce can be algorithms, datasets (e.g. used to train ML models), customer data etc, so understanding where and how value is created is key to any IP protection strategy. A lot of wiring up code is common to a large number of applications and if folks steal it, well, whatever - it shouldn’t make or break your company if it’s taken.

How you protect the secret sauce is then a combination of legal, social & technical. I have seen “inner-circle” developers who are “motivated” (better pay, equity, proven trustworthy, explicit legal threats or whatever) to be “stay close” being the only ones allowed to work on the core algorithms and outer-circle developers (e.g. contractors, new hires) only access the core algorithms via well defined APIs. This can be taken a step further if the algorithms are particularly valuable by, for example, offering an alternate, inferior algorithm with the same API for the purpose of building and testing integrations / UIs etc, but only deploying the real one into production to minimise the possibility of reverse-engineering.

Also, if an algorithm is valuable enough to want to prevent casual IP theft, it’s probably valuable enough to build some bits in a different language where the build artefacts are harder to reverse-engineer.

Post #7

hst337

Obfuscated code like in JavaScript can still be easily deobfuscated. Providing .beam is not secure because they can be easily decompiled (even by hand).

Post #4