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…

Do we actually need it for secure software?

Before I draw all the flashes of anger from all the software security-aware professionals out there, I insist you give some time to contemplate on the subtitle for some time.

Input validation is the heavily recommended technique in order to prevent malicious attacks against our software albeit from analyst and developer perspective it is sometimes treated as a burden. In this post, you can find a discussion over whether we can write secure code without using input validation whatsoever.

Do we actually need input validation when securing a software?

This is Bedirhan and I’ll present some solid examples that allows to ask that “obnoxious looking” question in a short while…

Automation is a key process for secure software development. It is a requirement because we are extremely short on resources and we need to catch-up with the speed of development to production. This is Bedirhan and in this post I’ll try to explain what security automation brings into our dubious battle against hackers. Equally importantly, I’ll try to list the stuff we should know about any security automation technology so that we never assume that we win the battle when we have them in-place.

Automation: A vital piece of the security puzzle that we should understand well

We produce huge amounts of code and it should be tested, deployed & maintained. Sure, we…


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