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.

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

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…

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. …

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?

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…

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.

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

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…

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…

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.

This…

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.

It All Starts with Curiosity

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

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.

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