HTTP Parameter Pollution

There are a ton of weaknesses a developer should be aware of. A hacker’s job is to find and exploit these weaknesses. If, as developer, you feel that it is hard and uncalled for to keep-up and understand each and every one of these hacks, there’s good news.

A simple but good security perspective can help us produce quality software.

If you can follow a handful of best practices in software security, the majority of these weaknesses will go away automatically. …

Security analysis of an example code

ProcessBuilder is a Java class used to create Operating System processes. Therefore, needless to say, when coded insecurely it leads to serious security risks. In this post, we will go over an example code block utilizing ProcessBuilder and reveal a few security code best & bad practices through the analysis.

The power that APIs provide developers is immense. However, it is easy to ruin everything.*

So, without further ado here’s the code block;

String path = "C:\\Windows\\system32\\cmd.exe";ProcessBuilder pb = new ProcessBuilder(path);
Process pingProcess = pb.start();

Let’s read and comment on this simple code. It takes a user input (userInput) as an argument and executes ping command with it.

Let’s see what…

Read this and count to 10 if you feel you have to…

It’s not infrequent across developers to posit a certain claim that may cause more harm than good. Upon a task that can be fulfilled by searching and finding quality solutions already existed, we most deservedly think that “I’m clever, I can write one”.

But, why is it a bad idea to device a new algorithm instead of using an already existing one?

Creating a new or customizing an existing security related technique may be costly.

After all, if it’s all about correctness, the existing ones could be fallacious as well. Because, the stakes are high for mistakes. …

Geliştirme tavsiyesi değildir.

Zaman zaman sorumlu olduğunuz sistemler ile ilgili karşınıza çıkan güvenlik tarama araçlarının bulguları kuvvetle muhtemel canınızı sıkıyordur. Network, veritabanı uzmanı, developer, uygulama sunucu yöneticisi yani daha modern bir tabir ile DevOps sürecinin bir parçasıysanız, kim bilir belki de olur olmaz zamanlarda üzerinize atanmış güvenlik bulgularını anlayıp, çözmek yerine yok olmalarını dilemiş olabilirsiniz.

Developer iseniz doğru yerdesiniz. Bu yazıda, özellikle statik uygulama güvenlik testi (SAST) araçlarının bazı bulgularını düzeltmeden, nasıl kaçınabileceğinizi anlatmaya çalışacağım.

Yazılım güvenliğinde temel kamuflaj teknikleri.

Sadece yukarıdaki son cümle bile bir güvenlik uzmanının tüylerini diken diken etmeye yetecektir. Dolayısıyla bütün şimşekleri üstümüze çekmeden sorumluluk reddini şuraya bırakalım;

Bu yazıda listelenen veya ima edilen…

Progress with producing CodeThreat

This one and a half year has been packed with security centric static program analysis for the CodeThreat team. After all this time, we have come to know that designing and implementing a scalable, flexible and soundish code analysis solution is a highly challenging task. This is Bedirhan, and in this post I’ll try to bring in some perspective on how the project and the team progress and what expects us in the near future for which a historical view of the project annotated with experience is a meaningful route to follow.

CodeThreat static application security solution is one and a half years old now

Bootstrapping with Passion

First of all the core team is in…

for Static Application Security Testing Tools

All automated testing solutions produce results when run against a target system. That’s expected. What’s more interesting about this process is that we want these results to be as related as possible; we don’t want false alarms.

False alarms or in more technical terms false positives (FPs) are the anticipated byproducts of any automated testing. But, what makes a static application security tool to produce them? In this post, we’ll try to pinpoint some of the key sources of FPs and what the tools do about this situation.

What are the reasons for bad findings of a static application security testing automation?

The obvious reason that nobody likes false alarms is that because they…

Hint: The question is irrelevant.

Static and dynamic application security testing, called SAST and DAST respectively, are compared to each other once in while. Both being quite different automated solutions with the same goal, this is understandable. It’s important to understand that these technologies are not replaceable with one another. This is Bedirhan and in this post we will go through a discussion why this is so. Let’s dig in to find out more…

A sane SAST vs. DAST comparison

Here’s the key difference between the two technologies; static security testing is executed on applications that are not running, these tools work on the code resting, hence the name static. …

Hardship in producing a secure software

Not a single developer, analyst, project manager or business owner want to own an insecure software. Just like customers would never want to trust any insecure application with their valuable data. Having or using a rock solid secure application is a desired thing, but is it possible at all and what can we do about it?

Is secure software somewhere around the Never Land?

This is Bedirhan from the CodeThreat team, and in this post I’ll try to pinpoint difficulties of producing a secure software. First thing first; the number of new vulnerabilities published each year has a quite disturbing but factual outcome;

It is pretty hard to…

Program analysis fight against imperfection

It’s impossible to provide a correct solution to non-trivial security questions for security automation tools. Nevertheless, this limitation doesn’t actually undermine their value being great helpers to make our applications secure. Without the automated tools it’s quite hard to keep up with the speed of current development practices.

That being said, for example, we can’t build an algorithm to check whether a target program is SQL Injection free or not.

Imperfection is an inherent part of an automated security analysis solution and sensitivities are mechanisms to increase the precision of these tools (with a cost)

Sure, there are good tools to check this interesting property, however, never with %100 certainty. Please read our previous blog post for a proof. …

Security testing automation is stranded by Gödel

Everyone who has dealt with developing a comprehensive automated security testing tool knows that it is a challenging task. Staying on top of new security bugs and making the tool performant is one thing and keeping false alarms (false positives) and missed bugs (false negatives) as low as possible is something else. But there’s a one more and inherent limitation to any automated software security testing solution; SAST or DAST…

Sometimes, the most definite answer we can get out of a security testing tool is just a MAYBE

As a side note, we have written about soundness and precision in one of our earlier post and you can read about them in order to learn some fundamental terms…


CodeThreat is a static application security testing (SAST) solution. Visit

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store