Deciding generally if you should use packages from a certain ecosystem based on the perceived quality of the average developer in that ecosystem seems strange. Not using Hex packages and rewriting them from the scratch seems like a huge amount of wasted effort and will likely lead to less reliable software. How long do you think it would take to get a feature parity with packages such as Phoenix or Ecto, not to mention fix all the bugs that have already been discovered by their thousands of users?

You need to make your decision on a package by package basis to determine if you can trust it. We have some tools to help you with that such as https://diff.hex.pm and https://preview.hex.pm

I would likely sidestep the immediate questions and wonder if it actually makes sense to have answers for them. There’s imo different ways to look at the problem you seem to face.

Are third party dependencies possible attack vectors?
Yes – no matter how one turns the coin.

Having acknowledged that there’s two options:

1. Not using third party code and writing everything on your own.
   Works, but isn’t necessarily effective. (Also there’s no guarantee you’ll do better)
2. Using third party code, accepting the risk, but doing the best to mitigate it.

For option 2 what can be done lessen the possibility to accidentally pull in code, which poses a security risk to whatever the code was pulled into?

You seem to want to argue about the people building hex packages. I don’t think one can make a good argument over the whole of all developers with packages on hex. Also everyone of us makes errors and mistakes – even the most senior/experienced of developers. So imo your argument will always be kinda moot.

There are other means of reducing risk though, which is review. Whenever a library is added it goes through a review process (in however fancy form that may be, could even include how much “professional experience” you expect out of the author) and is only used once reviewed. Whenever the library is updated you can use e.g. diff.hex.pm to make sure nothing changed in a way violating previous review checks. Some companies even run their own internal registries, which holds only reviewed packages. One actual benefit of the elixir ecosystem over the node one is that it’s likely much easier to go the review route, as you’re not running with 1000s of dependencies. I’d expect that number to be more in the 100-200 range for most projects.

Github also recently added elixir/erlang into it’s security advisory database. That can be another source of being made aware of issues.

Wait until they find out about programming languages. And operating systems. And embedded firmware.

If there’s code running or hardware hardware-ing that YOU didn’t design, there’s some level of supply-chain risk. The question is deciding what level is acceptable for your organization, and then verifying that things meet your requirements.

“Well I’ve heard this community’s developers are smarter / better / faster / longer than $OTHER_COMMUNITY” isn’t a part of that process.