Securityblog

These are certainly strange times we are living in. None of us will ever forget what’s happening and we will all retell stories for the rest of our days. Many of us asked “tell me about the depression grandma”, similar questions will be asked of us someday. The whirlwind of confusion and chaos got me thinking about advice and who we listen to. Most of us know a staggering number of people who are apparently experts in immunology. I have no intention of talking about the politics of the current times, goodness knows nobody in their right mind should care what I think. What all this does have me pondering is what are experts and how can we decide who we should listen to? ...

Well, we’ve made it to the end. What started out as a short blog post ended up being 7 posts long. If you made it this far I commend you for your mental fortitude. I’m going to sum everything up with these 4 takeaways. Understand the problem we want to solve Push back on scanner vendors Work with your vendors Get involved in open source Understand the problem we want to solve In security it’s sometimes easy to lose sight of what we’re really trying to do. Running a scanner isn’t a goal in itself, the goal is to improve security, or it should be if it isn’t. Make sure you never forget what’s really happening. Sometimes in the excitement of security, the real reason we’re doing what we do can be lost. ...

If you just showed up here, go back and start at the intro post, you’ll want the missing context before reading this article. Or not, I mean, whatever. I’ve spent the last few posts going over the challenges of security scanners. I think the most important takeaway is we need to temper our expectations. Even a broken clock is right twice a day. So assuming some of the security flaws reported are real, how can we figure out what we should be paying attention to? ...

We’ve already discussed the perils of code and composition scanning. If you’ve not already read those, you should go back to the beginning. Now we’re going to discuss application scanning. The basic idea here is we have a scanner that interacts with a running application and looks for bugs. The other two scanners run against static content. A running application is dynamic and ever changing. If we thought code scanning was hard, this is even harder. Well it can be harder, it can also be easier. Sometimes. ...

If you just showed up here, go back and start at the intro post, you’ll want the missing context before reading this article. In this post we’re going to talk about a newer type of scanner called a composition scanner. The idea here is when you build an application today it’s never just what you wrote. It also includes source code from a large number of other sources. Usually these other sources are open source. ...

If you just showed up here, go back and start at the intro post, you’ll want the missing context before reading this article. The first type of scanner we’re going to cover are source code scanners. It seems fitting to start at the bottom with the code that drives everything. Every software project has source code. It doesn’t matter what language you use. Some is compiled, some interpreted, it’s all still source code. The idea behind a source code scanner is to review the code a human wrote and find potential security problems with it. This sounds easy enough in theory, but it’s extremely difficult in practice. ...

This post is the first part in a series on automated security scanners. I explain some of the ideas and goals in the intro post, rather than rehashing that post as filler, just go read it, rehashing content isn’t exciting. There are different kinds of security scanners, but the problem with all of them is basically the same. The results returned by the scanners are not good in the same way catching poison ivy is not good. The more you have, the worse it is. The most important thing to understand, and the whole reason I’m writing this series, is that scanners will get better in the future. How they get better will be driven by all of us. If we do nothing, they will get better in a way that might not make our lives easier. If we can understand the current shortcomings of these systems, we can better work with the vendors to improve them in ways that will benefit everyone. ...

Are you running a security scanner? It seems like everyone is doing it, maybe it’s time to get with it. It’s looking like automated security scanning is the next stage in the long winding history of the security industry. If you’ve never run one of these scanners that’s OK. I’m going to explain what they are, how they work, how we’re not using them correctly, and most importantly, what you can do about it. If you are running a scanner I’m either going to tell you why you’re doing it wrong, or why you’re doing it REALLY wrong. If you’re a vendor who builds a security scanner I assure you I understand there is a high probability I am indeed an idiot and don’t know what I’m talking about. I’m sure everything will be fine. ...

Unless you’ve been living under a rock for the past few … forever, you may have noticed that open source is taking took over the world. If software ate the world, open source is the dessert course. As of late there have been an uptick in stories about backdoors in open source software. These backdoors were put there by what is assumed to be “bad people” which is probably accurate since everyone is a villain in some way. ...

Recently there was a thread on Twitter I stuck my nose into about appsec and why it doesn’t work. I have a response in there that I believe is a nice way to explain my biggest problem with appsec. I would sum it up as “Appsec isn’t people”. Here is a clever image to help. You know you can take it seriously because the text is green. The best way to think about this is to ask a different but related question. Why don’t we have training for developers to write code with fewer bugs? Even the suggestion of this would be ridiculed by every single person in the software world. I can only imagine the university course “CS 107: Error free development”. Everyone would fail the course. It would probably be a blast to teach, you could spend the whole semester yelling at the students for being stupid and not just writing code with fewer bugs. You don’t even have to grade anything, just fail them all because you know the projects have bugs. ...