IMWorld Bucharest

I’ve just had the great pleasure to present again in Bucharest at this year IMWorld an introduction of security tools. We had some WiFi issues, so I had to change slightly the workshop contents, but the audience was very sympathetic and overall we were all pleased with the results!

As the slides are covering only the introduction to the topic, I will now detail here the workshop contents so that you can reply what we did live!


SIS tools (Sensitive Information Scanners) are used to examine your codebase for the presence of information that should not be disclosed, like AWS or PGP keys.



Let’s start having a look at git-leaks. You can download the binary from here, unpack it and check it works with the command:

gitleaks-linux-amd64 –help

As you can see there’re a lot of options, with the ability to run it against an entire organization for example, but you can now run the command against a sample repository:

gitleaks-linux-amd64 –repo=

As you can see it is reporting problems: launch it again with –verbose, few problems pop up (what about those AWS keys???), you can also add  –report=report.csv –csv to generate a csv report.

Now, why don’t you look at one of your OWN repositories? You could be surprised! Or try this one:

gitleaks-linux-amd64 –repo= –verbose



trufflehog is a python tool, so extremely easy to install if you are on Linux! Just type:

sudo pip install trufflehog

You can check it works with:

trufflehog –help

There’s a lot you can do here: you can have tghe output in HSON, you can define extra rules, and so on. It deserves a bit of experimenting! But for the time being, please rtun on the first repository:

trufflehog –regex

Again, we can see the AWS keys popping up (ops!). Now, try one of your repos, or maybe this one:

trufflehog –regex –entropy=False



Due to the slightly more complicated installation, we won’t have a look at these ones, but I suggest you check them out as well:

  • gitrob: very comprehensive analysis
  • git-secrets: a git hook provided directly by AWS



SDA tools (Sensitive Dependency Analysis), also known as SCAN (Software Composition ANalysis) are used to examine the software component you use in order to check if any of them is affected by known vulnerabilities. Here I will gently shamelessly plug the tool my startup is building, Meterian, and I hope you do not mind 🙂



Download the latest client from the website and run it against a sample project (you can use this one we used in the previous blog post):

cd /your/project/folder
java -jar /path/to/meterian-cli.jar

You will probably be asked to authenticate, just use your GitHub or google account to do so. You will see some scores (the security one will be, well, very low!) and a report will be generated: just click on the link to access it (again, same social login). If you used my example, jackson-databind 2.8.8 is definitely a winner! It’s potentially exposing your project to at least four different exploits… nice!

You can also see a list of possible upgrades for your libraries and (if the feature is

enabled for your account) also the full list of components and the related versions.



Download the client from the website, following the link from Github, in a folder, and run it against the same project used before:

cd /your/project/folder
dependency-check/bin/ –project sample –scan .

The long NVD database download may happen, it will take a while! Well, just have a coffee or something, then come back in 10 minutes and then find an HTML report in the folder:


Just open the report with a browser, you will see a list of the offending libraries.


SCA tools (Software Code Analysis), are used to examine the code you write, either in binary or source format.



Download and unpack the tool, then set the SPOTBUGS_HOME variable:

export SPOTBUGS_HOME=/path/to/spotbugs-3.1.3

Spotbus has a UI (of course it works also from the command line): launch the UI and do a quick demo:

java -jar $SPOTBUGS_HOME/lib/spotbugs.jar

Get some code on your laptop (I suggest the fastjson project, it has a wide attack surface): create a new project, select the binary output of the project (you may need to run mvn package on the project to get it) and select also the source code. Click the button and then dig into the problems: you have a lot to get through!

Spotbugs has a nice plugin, findecbugs, that specifically finds security problems: once you downloaded the plugin, copy the jar file in the plugin folder of spotbugs:

cp findsecbugs-plugin-1.8.0.jar $SPOTBUGS_HOME/plugin/

Open spotbugs again, re-run the analysis and enjoy a tour of the newly “security” section!


Download and unpack the tool, run the tool against the sample project from the newly created folder:

bin/ pmd -f text -d /path/to/project -R rulesets/java/quickstart.xml

There’re a number of rules here, enjoy some time in investigating them!


This can only be used as a plugin tool but it’s pretty effective!  Clone the repository:

git clone

Or just download the zip:

wget && unzip

Move to /examples, change the pom.xml so that it references 3.2.1 of errorprone and:

mvn clean package

Notice that the system stops with an error (the exception not thrown) plus the suggestion: fix the errors one by one, see the compilation passing :).


This is the last category of tools we see today, and it’s quite an interesting one. RASP tools basically will melt with your code, deploying an agent within it (typically using code instrumentation) and they will actively track any malicious activity: when that happens, the tool will take some preventive measures (i.e. stop the user session) and report the issue back to your company risk assessment system.


This is an open source tool by Baidu, that shows an interesting take on the probkem.

Download and install a fresh Tomcat from here, unpack and start Tomcat the usual way:

cd apache-tomcat-8.5.6/
bin/ run

Access and see Tomcat working!

Clone the test cases from here, move into the subfolder java/vulns and create the war package:

mvn package

Copy the newly created package under the /webapps subfolder of Tomcat: the server will promptly hot-deploy the application.

cp openrasp-testcases/java/vulns/target/vulns.war apache-tomcat-8.5.6/webapps/

Visit to see the application page (you may need google translate at this point to get a bit of English!) and try the exploit 002 and 004.2: see how is easy to bypass security and executing commands on the server.

Now, download the 0.31 Java openRASP from here, unpack and install it on Tomcat:

java -jar RaspInstall.jar -install  /path/to/apache-tomcat-8.5.6

Now, restart tomcat, you will see the OpenRASP logo in the console. Start tailing the openRASP log:

tail -f /path/to/apache-tomcat-8.5.6/rasp/logs/alarm/alarm.log

Try again to execute the vulnerabilities and… surprise!

  1. you are blocked with a fancy page 🙂
  2. the logs show the intrusion with complete detail

Hope you enjoy it!