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…

There’s more to it than meets the eye…

Building is harder than breaking. Well, at least most of the time. Building a quality software takes months maybe not years. And I’m not aware of a security weakness finding which takes a few weeks let alone months. Having said this I also have to admit that I don’t have any first-hand government level, cyber warfare exploit experience. So, what do I know… Nevertheless, A similar comparison is possible with fixing and hacking. Most of the time the fixing might seem easier, but it’s not. There are various difficulties a developer has to tackle to mitigate a security bug.

Defense is harder than attack. We, developers, should be prepared.


A journey of a software security request…

This is the story of a community triggered security request which was worked by the related project team and fixed by increasing the awareness through the sample code and the official documentation over a two-years period.

This is Bedirhan and in this post I’ll try to give you a pretty nice example of different phases and views of handling security concerns in real life. By the way I came across this example purely by chance and it was somehow exhilarating to dig the story further.

This is a relentlessly dug uncovered story of a security request

It All Starts with Curiosity

Here’s the starting point of the story. I…


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