Sobelow - Uncover vulnerabilities in your Phoenix projects


Sobelow is a security-focused static analysis tool for the Phoenix framework. For security researchers, it is a useful tool for getting a quick view of points-of-interest. For project maintainers, it can be used to prevent introducing a number of common vulnerabilities.

Currently Sobelow detects some types of the following security issues:

  • Insecure configuration
  • Cross-Site Scripting
  • SQL injection
  • Directory traversal
  • Unsafe serialization

Potential vulnerabilities are flagged in different colors according to confidence in their insecurity. High confidence is red, medium confidence is yellow, and low confidence is green.

There was some initial discussion, but I thought it could use its own thread. This is just the initial release, so additional features will be added over time, and I’m sure things will change and update based on feedback. Feel free to ask any questions here, or message me on the Elixir slack channel or Keybase chat. I’m @griffinmb on both!

You can find the repository here, and a video demo here!


If sobelow helps you find and fix a vulnerability, let me know! I’d love to hear where it helps out. Additional feedback, feature suggestions, etc are also greatly appreciated :slight_smile:


Pushed a couple small updates, including checks for some command injection vectors! Upcoming updates will focus on simplifying and streamlining the codebase and expanding checks that are already in place (e.g. additional SQL and XSS checks).


Just updated but –

10:17 ~/testcases/elixir/ncrud/nada(upgrade)[ruby-2.3.3@global]$ mix
Found existing archive: /Users/hassan/.mix/archives/sobelow.
Are you sure you want to replace it with
""? [Yn] Y
* creating /Users/hassan/.mix/archives/sobelow
10:18 ~/testcases/elixir/ncrud/nada(upgrade)[ruby-2.3.3@global]$ mix sobelow

For the time being, every update will end up going through the “replace existing archive” dialogue. In the future, I may implement some sobelow-specific upgrade functionality that allows that to be bypassed, but that will be closer to 1.0.

Let me know if I misunderstood your concern :slight_smile:

Let me know if I misunderstood your concern

Apparently discourse mangled my post, so –

1 Like

That makes more sense ha.

It looks like there was an inadvertent space in the version number. If you try again, it should work. If not, I pushed an update to trim the version number so it should work no matter what. Let me know if that fixes your issue!

It looks like there was an inadvertent space in the version number. If you try again, it should work.

It was a consistent failure.

If not, I pushed an update to trim the version number so it should work no matter what. Let me know if that fixes your issue!

Yep, installed the latest and it works now – thanks for the prompt
response and the cool tool :grinning:

Excellent! Glad that solved the problem. Thanks for the detailed bug report :smile:

This tool looks great! I’ll definitely be running it through my projects.

1 Like

Thanks, let me know if it helps you find and fix anything! :smiley:

Someone raised an issue about returning non-zero return responses for better integration within a CI pipeline (which you can view here:

Would love to know if there is any additional feedback on that subject as I’ll be working on that over the next couple of weeks while I streamline/expand.

As a flag maybe. But tbh, i would never put it in a CI system. Far too many false positive so far.

Which is normal and expected from my POV. I prefer that type of tools to give false positive than to give false negatives.

1 Like

I think for integrating with a CI system, a couple things would have to happen. Mostly, there would need to be some way to indicate that a finding is a false positive or otherwise not to be reported. I talked a bit about this in the initial thread – there are some pros and cons, but ultimately probably worth adding.

I’m also concerned with people only wanting to trigger responses on high-confidence findings, since low-confidence findings should still be validated, and (as in your case) high confidence findings aren’t 100% either.

And I think I’ve just talked myself into creating a system for flagging findings as do-not-report…

Thanks for creating this. I did find a few sql injection vulnerabilities in our project. This will be a great help to guide new devs to the right way. Another thing we could check for would be unsafe string to atom conversions.

A quick suggestion on hosting the archives. It is not a good idea to put binaries in your source code. You could do something similar to phoenix and create a different repository for archives:

1 Like

It’s also possible to install archives from hex with mix archive.install hex sobelow on newer mix versions. This should probably be the preferred method. It eliminates the issue of precompiling and erlang version compatibility since it’s compiled from source on target machine.


Awesome, glad it’s helping out!

Great idea, I’ll add that.

@minhajuddin, @michalmuskala - Great points RE the installation. Updated :slight_smile:

You should now be able to install with mix archive.install hex sobelow

1 Like

Whoo! What is the update path as updates are released? Same command? Does it automatically state when an update is released so we know?

1 Like

Updates should work with the same command. If they don’t, let me know and I’ll fix it! When you scan a project, Sobelow will occasionally (about once every 12 hours) check for available updates, so it should help you stay up to date.

Of course, since it’s still pre-1.0 there may be breaking changes from time to time, so if you ever find that you haven’t been notified of updates in a while, it may be a good idea to check back in on the repository!

1 Like