Tag Archives: static analysis

Does Cloud Change Static Analysis

Look, we all know that using static analysis tools can be a real pain. In the past I’ve talked about some of the reasons people struggle with the output of AppSec tools. Similarly people struggle with using static code analysis. I even did a poll about static analysis challenges at one point.

From the feedback I’ve gotten, it seems that some people think that doing static analysis via SaaS (IE the cloud) would address the problems I’ve discussed. There are real challenges in getting the most out of your static analysis, but the claim that somehow cloud will solve them is ridiculous marketing hype – why would it change at all? Why should developers even be able to tell the difference? It doesn’t address any of the core issues. There are benefits you can get from using cloud for your static analysis aka Static Analysis as as Service (SAaaS?) such as reduction of up-front costs, saved IT costs, and easy deployment. But the most common problems are the same whether you run the tool in-house or use a service.

The core problem I mentioned was really getting developers to buy-in. They need to believe in the results because they need to fix them. Once the developers start picking and choosing what to fix, you’ve lost. They’ll spend countless hours challenging results and explaining why they’re not important – the inappropriately labeled “false positive“. Changing the method or location of how you run static analysis may have ramifications on the overall process, but it will in no way affect how developers perceive the results.

Getting the static analysis tool running is one of the first steps in a successful rollout, but from there you’ve got to do several things to make sure that you’ll get the value you expect.

Static Analysis Policy

It begins with having a clear static analysis policy. The policy should include when static analysis must be run and when it can be skipped. It also needs to cover when suppressions are acceptable, how severity level affects fix now vs fix later, what rules you must run, and how to handle legacy code. Legacy is one of the big problems – do you fix everything in your code regardless of age? Can you just fix it when you happen to be editing one of the old files? Should you only run static on the code you actually change in old files? These are real issues that will occur when you deploy and if you don’t decide what is proper, each developer will do their own thing.


Developers need to be trained to use static analysis. Usually people remember to train on the mechanics of the tool, but not the further training that ensures success. Developers need to know when/how to suppress – does it go into the code or into an external system? They need to know how to find out more information about the problem. They need to understand what the severity levels mean and how it will affect their decisions.

It’s important as well that they understand the ramifications of a particular error. I’ve repeatedly had the experience of a team claiming a static analysis error was invalid when it was actually a real serious problem that they didn’t understand. Heartbleed is a classic example of this behavior. Finally your training needs to shift the mindset of the users from “static finds bugs” to “static finds bad code”. This distinction is crucial to get the most value. The “bugfinder” rules in static analysis are the proverbial tip of the iceberg. They’re only a small part of the full value. The bigger value is the rich set of coding standards that represent hundreds of man years in crafting best practices that help you harden your code and avoid problems in the first place.

Persistent Static Analysis Suppressions

Suppression handling can make or break your project. The symptom of this is developers saying things like “I keep fixing the same things.” What they mean isn’t that they’re fixing them, but they keep seeing the same violation and tagging it as invalid or acceptable every time the tool runs or versions change. They understandably view this as a stupid tool.

There are two schools of thought on suppressions. One is that they belong in an external system, whether it’s the static analysis tool itself, a file in source control, or a spreadsheet. The other idea is that they belong in the code. There are advantages to both, but I prefer the “suppressions in code” method. The benefits of this are that you never end up with issues that cause old suppressions to come back, because they’re tightly coupled to the code. A secondary benefit is that suppressions will end up in source control, you’ll know who did them, when they’re done, and if they left a comment you’ll even know why. This is really important if you operate in a compliance environment like FDA, Aircraft/DO-178B/C, or Automotive ISO 26262.

Good documentation

I’ve alluded to the idea that the docs need to explain why a particular static analysis rule is important. I’ve got several things I look for in good tool documentation.

  • Example bad code
  • Example fixed code
  • Impact – what will happen if you don’t fix this violation
  • Possible security relevance
  • Resources to learn more
  • integration to IDE – right-click on a violation to see the docs


Getting your static analysis rollout right is crucial to your success. There are many options from on-premise to cloud-based and you should carefully weight the benefits of each approach. But don’t expect the cloud to solve all the challenges you’ll face. There is no substitute for a well-planned tool deployment.


Keynote at EuroAsiaSPI2 2016 Conference

If you’re going to be in Europe in September, I’ll be speaking at the EuroAsiaSPI2 2016 conference in Graz, Austria on September 15th.

EuroAsiaSPI2 is also known as European & Asian System, Software & Service Process Improvement & Innovation. The EuroAsiaSPI² conference presents and discusses results from systems, software and services process improvement and innovation or SPI projects in industry and research, focusing on the gained benefits and the criteria for success. This year’s event is the 21st of a series of conferences to which international researchers and professionals contribute their lessons learned and share their knowledge as they work towards the next higher level of software management professionalism.

I’ll be speaking on Software Safety and Security through Standards

Software has moved from the desktop in just about everything we touch. From smart thermostats to infusion pumps to cars software is pervasive and growing. These so-called “things” from the Internet-of-Things are increasingly carrying more logic and with it a larger risk of failure. Many of these devices are using in safety critical areas such as medical and automotive where they have a particular potential for bodily harm.

Most companies that have been building devices rightly view current software development as an almost insane group of cowboys and chaos. But there is hope, software CAN and MUST be treated an engineering practice. Coding standards move us from the build, fail, fix cycle back into a design, build, deliver cycle with high quality, safety, and security.

As it turns out, these same standards also provide benefits in the areas of cybersecurity, doing double duty. We will explore how standards help us move from finding bugs to building more robust software, how to prevent problems in the first place by proper coding, and how to leverage the efforts of others by using common accepted industry standards such as MISRA to achieve this goal.

To attend you can register here.

Prevent Automotive Software Bugs with Static Analysis

We all knows that automotive software is becoming increasingly complex. It’s gotten to the point that high-end cars not only have more code than jet fighter aircraft, but a LOT more code – in some cases as much as 100 million lines of code. Given that the automobile is a complex creation with lots of smart parts talking on multiple buses, trying to ensure that it’s bug-free is a frustrating and difficult task.

Bug in code
Bug in code

Anyone who knows me knows that I’m a huge proponent of software-development-as-engineering. This means that instead of simply chasing bugs and trying to test quality into a product, we change the way we build software and start by producing code that is less susceptible to bugs. Static analysis is the way to do this. For several years now a few vendors have been pushing the idea that static analysis is only for finding bugs, but it’s real power is in prevention. If you want your car to not have serious problems when it rolls out the door, static is your best friend.

Last week Adam Trujillo and I wrote an article in Embedded Computing Design detailing three simple static analysis rules to get you a jump-start into producing better automotive software. As it turns out there are a few MISRA rules that end up preventing a large number of very common and potentially dangerous problems such as buffer overflow.

It’s a short article but very practical. Give it a read and if you want to know more, be sure to let us know.

For more info check out these books:

Automotive Software Engineering: Principles, Processes, Methods, and Tools

Formal Techniques for Safety-Critical Systems

Effective Modern C++: 42 Specific Ways to Improve Your Use of C++11 and C++14

Halloween Security Slashers Webinar

Halloween themed software security webinar
Halloween themed software security webinar

I’m doing a Halloween themed Parasoft webinar this Friday on Stopping Software Security Slashers with Static Analysis. As always it’s a free webinar and you can register here.

We like to have fun at these holiday webinars, so we’ll investigate how some security issues are similar to the famous horror movie villains you know and love, like Jason, Freddy, Leatherface, Michael and Norman. I hope to see you there.


Stagefright, Heartbleed, and other grisly-sounding software defects are scary for good reason: they make applications vulnerable to menacing cyberattackers—no hockey mask or knife-fingered glove required. In the absence of an adequate defect prevention strategy, your application is likely to stumble as malicious (and even not so malicious) hackers bear down on vulnerabilities, potentially crashing the software or exposing sensitive data. If your software is deployed to a medical device, automotive system, or any other safety-critical application, this is only the beginning of the nightmare.

But your application deployment doesn’t have to end in gruesome horror. By implementing quality practices, such as a static analysis, throughout the SDLC, you reduce the potential attack surface cyberattackers can exploit. Moreover, by automating the continuous application of defect prevention technologies, you eliminate the possibility of defects recurring like a chainsaw-wielding maniac that won’t stay down.

In this webinar, we’ll look at why recently publicized defects are so scary and discuss how to take a proactive approach to ensuring the safety, security, and reliability of your applications. We’ll focus on how to leverage standards, such as OWASP, PCI DSS, and CWE, to evolve development policies from static analysis findings so that your application isn’t the next victim.