Someone raised an issue about returning non-zero return responses for better integration within a CI pipeline (which you can view here: Issue · GitHub).
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.
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: GitHub - phoenixframework/archives: Holds archives for released Phoenix versions · GitHub
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 
You should now be able to install with mix archive.install hex sobelow
Whoo! What is the update path as updates are released? Same command? Does it automatically state when an update is released so we know?
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!
Just ran sobelow on my big giant work project, it found only one thing:
HTTPS Not Enabled - High Confidence
However we run it behind nginx that does have https enabled, so eh, need a way to disable it. ^.^
Also, got this warning at the bottom of the scan:
$ mix sobelow
##############################################
# #
# Running Sobelow - v0.2.3 #
# Created by Griffin Byatt - @griffinbyatt #
# NCC Group - https://nccgroup.trust #
# #
##############################################
HTTPS Not Enabled - High Confidence
-----------------------------------------------
warning: an expression is always required on the right side of ->. Please provide a value after ->
nofile:119
... SCAN COMPLETE ...
What’s with the nofile bit?