Vet - Elixir dependency security scanner

It often does not. I do not have access to sensible AI reviewer, but I think it could hiccup on code that looks innocent to people, but is malicious when used together. For example a Vet (and I think neither will any other AI agent) will see anything particularly wrong in using :ranch_tcp.listen or stuff like that. Especially when you will do that across different libraries.

Obfuscation of the attack do not mean that the code is less readable, it makes code flow harder to comprehend.

One of the possible vectors of the obfuscation I see is that someone will write code, where in mix.exs they will do “innocent” mistake in form of:

defp elixirc_paths(:dev), do: ["lib"]
defp elixirc_paths(_), do: ["lib", "test/support"]

And now they will put malicious code in test/support/file_used_only_in_tests_i_promise.ex. Now it will contain module named for example NoHarmPromise.FooControler while in lib/no_harm_promise/foo_controller.ex they will have NoHarmPromise.FooController. In their router they did another silly mistake and they have written post "/nothing-imporant", FooControler. But now, for both the LLM as well as human, it may look like there is no harm really. Code compiles, tests passes, but the code has slightly “unexpected” behaviour.

It is getting off topic there, but I have tried to assess known and intentionally malicious code from Underhanded C Competition from 2015 (so any LLM should have it in their learning corpus). It failed terribly there in both Gemini as well as ChatGPT (I do not have accounts for other LLMs so I didn’t bother). Both have noticed some small problems (like NaN handling or potential division by 0), but none catches the elephant in the room.

I do not really believe, that with determined enough attacker (who also had access to all these tools) it could be avoided. Especially with Jia Tan-level of dedication to prepare the attack.

IMO the mere fact of trying to obfuscate it would make it easier to flag. The hacker must be a godlike genius to be able to have completely innocuous code that passes cursory review.

…And even then, one prompt like “This library must strictly adhere to the activities X and Y. Do a thorough audit for outliers” will give you 80-90% certainty that even the innocuous genius insecure code would be found.

I, like @hauleth, don’t have complete trust in LLMs (and nobody should) but I’ve also seen Opus do stuff that’s close to magic and I have gradually learned to guide it in a way that makes the magic more likely to be produced.

Fair point. Although I think at this point it’s worth taking a closer look at how false the sense of security can be. One extreme is “grep on steroids”, which we know is pretty false because we know exactly how to bypass it. Another extreme is deep human review, which is probably the best audit one can get, but it also can be classified as false: humans are prone to error and either have limited knowledge (if you do the review yourself) or rely on trust (if review is done by someone else).

My intuition is that Opus will be quite good as spotting suspicious stuff that doesn’t belong to a library. I would put it a lot closer to humans on a scale of false sense of security.

How hard do you think it is to obfuscate malicious code in a way that would pass security review from an LLM?

That falls very much under

There are approaches for “community driven reviews” like Crev, however these also have trust issues - how to implement a library of trusted reviews.

Unfortunately that isn’t a simple thing to do, because that is not technical challenge, but social one.

This sounds like a decent use case for LLMs? We definitely can’t get enough human eyes to audit Hex packages, but AI eyes are well within reach, although not free. It would make total sense for companies to run some sort of audit like that on CI privately, but maybe there’s a room for that at the ecosystem level

I have some:

• :ssh and :ssh_sftp aren’t checked - I can freely open some connection to remote server or open remote shell
• :ftp is not protected, so I can download or upload any data I want
• :httpd is not checked, so the second “hidden” HTTP server can be ran
• I can use :prim_file module - while it isn’t public API, I think that attacker will not give a damn about breaking API (and once upon a time I needed genuinely use that module, because “stable” API do not provide such functionality)
• I can run any external executable using Mix.shell().cmd(…) (which is by the way an approach that should be used in Mix tasks)
• :erlang.open_port is free to be used
• I can use Tesla or hackney or other HTTP client just fine, the same with sockets where I can use procket library to open any unsafe socket
• I can use defdelegate to circumvent any function call check

  defmodule TestMod do
    defdelegate foo(str), to: String, as: :to_atom
  
    def convert(str) do
      foo(str)
    end
  end
  

• While I cannot use apply I can still write function like def call(mod), do: mod.connect(~c"i.will.not.to.anything.promise.dev", []) and be able to connect to remote server
• I can use def "$handle_undefined_function"(name, args) to do more nasty things
• I can use :inet_res functions to leak data by sending prepared DNS requests containing private data
• I can use :epp.scan_file to read file content (it will be mangled, but in many cases it may be possible to extract required data from there

I appreciate your effort, the problem I see is that Erlang VM is just unsafe VM and I do not believe that there is a way to do it in a way, that will not create false sense of security. I strongly believe that tool that provide false sense of security is worse option than no tool at all.

What this tool currently provide is more of a sanity check against accidental data leakage than checking against actually malicious party trying to obscure their actions. It may be useful anyway, just not as a defence against malicious library providers (I deliberately do not use term “supply chain”, as open source authors aren’t “supply chain”).

If you want to secure against actively malicious parties, then:

1. You need to think as malicious attacker. If someone wants to hide what they are doing, they for sure will not fall into trap where you can simply use “grep on steroids” to see that it is doing bonkers stuff
2. In my opinion if someone want to hide what they are doing, then without higher level sandbox (either Erlang VM level or OS level) you cannot really catch that. This library can be circumvented in super simple way already - just write some Erlang module in your project, and you are safe to go and do anything, as it scans only Elixir code.

Thank you for filing #4 through #9. All six were real gaps. Fixes are live in commit 9d8d621.

The reasoning behind each:

• #4 (:compile.file/forms): the code_eval check only covered Elixir’s Code.* family, which left the Erlang :compile module as a free bypass for dynamic code execution. The threat is identical, so the five main entry points now fire with the same severity as Code.eval_string.
• #5 (File.open): the function list had read/write/stream but not open. That meant the pipe File.open!(path) |> IO.read(:eof) was invisible, which is worse than the direct File.read! form it was presumably bypassing.
• #6 (Erlang :file): same attack, different wrapper. Elixir’s File.* ultimately calls :file.*, so checking one without the other just moves the evasion one character to the left.
• #7 (:gen_tcp.listen): I had written the check with exfiltration as the threat model, which is why only connect was there. But a malicious package opening a listener for command-and-control is the same class in reverse, so listen, accept, and controlling_process now fire too.
• #8 (UDP and SCTP): I simply had not considered them. Supply-chain attacks don’t owe us the courtesy of using TCP.
• #9 (:socket): the low-level OTP socket API lets you do everything :gen_tcp, :gen_udp, and :ssl do while sidestepping all three. Added as a wildcard, because on a library the mere use of :socket.* is already anomalous.

The deeper issue your reports exposed: the detection was whatever patterns I happened to think of, not a reasoned map of the actual attack surface. A targeted unit test for each pattern couldn’t catch the class of bug you found, because the failure mode is a silently absent pattern, not a broken one. So I also added three layers that together bound the detection surface exactly.

First, a coverage sweep test that drives every declared pattern through the check engine. If someone removes or mistypes an entry in the check module, the test fails loudly instead of quietly shrinking what gets detected.

Second, a symmetric equivalence assertion: each check module now exposes its target list, and the test asserts declared-set equals swept-set. Adding a new pattern without also adding a sweep row now fails, because the other direction would go uncovered. That assertion caught its first regression the moment I wrote it, flagging 10 :file functions I had declared but forgotten to sweep.

Third, a StreamData precision property. For each of the three checks, 100 random {module, function} pairs are generated from a pool that excludes every declared pattern, and the test asserts zero findings. 300 adversarial inputs per run. The sweep proves recall, this proves precision, the equivalence keeps them aligned.

If you find more, tell me. Curious what you try next.

I see you provided the list below. Great! My preference is that its given on this thread in some fashion, as you have done, but otherwise what is most convenient to you. I appreciate the critical feedback, hauleth.

Thanks! Fireship just published a video on a massive supply chain attack:

A rich hacker just penetrated 31 WordPress plugins…

I am hoping to get a lot of critical feedback from the Elixir community on Vet - I think it can be a key ecosystem advantage for Elixir to be highly resistant to supply chain attacks.

So please: attack Vet! Help me make it stronger!

This is a great idea, and extremely timely considering the rise in supply chain attacks!