Find Early. Fix Early.

Software Security & Static Code Analysis

Software is a complex piece of technology in the very heart of our lives from health to entertainment, from finance to connectivity. No doubt, security should be an integral part of this technology. As the history incessantly reveals malicious intentions against services are not new and software open to whole Internet usage is not an exception. Software products are constant and increasing targets for activists, organized or unorganized hackers, script kiddies, bug hunters and even the governments.

Writing rock solid code is hard. As the requirements evolve and get complex, software divaricates. Ensuring the code written is secure becomes extremely difficult, let alone the code produced works as intended.

Producing secure software requires many security related actions to be taken. These actions are but not limited to;

  • Determining security requirements
  • Including security cases along with the use cases
  • Producing threat models
  • Executing static code analysis
  • Running penetration tests

There are more than one software security maturity models, such as OpenSAMM [1], detailing, planning and formalizing these security actions. According to these maturity models there are many venues that must be visited with many levels for a process to produce a software whose security can be measured.

One of most important and somewhat widely adopted software security action next to penetration testing is the security static code analysis. Security static code analysis is executed on the static code by the help of another software with a mainly security perspective focusing on finding weaknesses without running it. There are many challenges to static code analysis such as hard to perform flow and control analysis, possible false-positives, performance issues on huge projects. However, being automatic static code analysis has also huge advantages;

  • Repeatable
  • Doesn’t need expertise
  • Takes short time

What Does AttackFlow Offer?

Repeatable tests enable measurements which is a prerequisite for comparison and proving that a process helps or not. AttackFlow runs each time you make a syntax error-free change in your source code or checkout someone else’s code into your development environment.

Software security expertise is key for finding the security bugs, understanding them and applying the right solution. But it is not always easy to readily find these abilities in development or quality assurance teams. AttackFlow enables developers to find critical security bugs in the source code without any prior knowledge. The finding notifications, explanations and references are detailed enough for a developer to go after fixing the bugs. If the fix is good, there’s no need to wait for deploy or commit or even full compilation. AttackFlow will no longer find the related bug again.

While the development focus is on the current module of code, the AttackFlow executes instantly finding security vulnerabilities. It’s true sense of “what you see is what you code” in security wise. This way manual code reviewers also benefit from the technology checking existence of security bugs as well as conforming to best practices and other custom policies.

With all these advantages it’s also important to know that there are venues that static code analysis comes short. No static code analysis can find business logic problems, for instance. However, with AttackFlow constantly analyzing the old and the new code you are typing, there will be an increase of security falsification awareness in developers, which is the key understanding to prevent any business logic problems.

A phenomenon that nearly every software security expert agrees upon is that in the software process “the early the bugs are found, the less cost they induce logarithmically”. The cost here is not only the money or time, it also means the level of stress on the shoulders of a developer in case of a successful hack.

References

[1] http://www.opensamm.org

AttackFlow Team