There have been numerous high profile security breaches in recent years that may have been avoided had software vulnerabilities been more effectively addressed. Breaches include Ashley Madison, Telegram, and BitFinex, but most significantlyΒ EquifaxΒ andΒ Yahoo!.
Together, these breaches exposed the records of well over 4 billion private individuals. As you can imagine, in their wake security has been getting a significant level of increased attention.
And so it should. The internet and the services which run atop it have become so essential to the functioning of modern life. When things go wrong there, they can have disastrous consequences for so many people.
So as software developers we appreciateβββmore than ever beforeβthat if we create an application which is accessible via the internet, then it is a potential target.
That said, application security isnβt always easy to implementβββespecially when working for pointy-eared-bosses who place tight time and budget constraints upon us.
But just like testing, securityβs something that we have to accept responsibility for because weβre the ones who write the code.
Luckily for us though, as with using testing tools to help us thoroughly test our code, there are tools available to help us find potential security vulnerabilities. Theyβre called static application security testing (SAST), a type of static code analysis tool.
What is Static Code Analysis?
If youβve not heard the term before,Β according to OWASP, static code analysis:
Commonly refers to the running of Static Code Analysis tools that attempt to highlight possible vulnerabilities within βstaticβ (non-running) source code by using techniques such as Taint Analysis and Data Flow Analysis.
These tools, as the description indicates, donβt just find security vulnerabilities. They can also scan for a wide range of other problems, includingΒ coding standard violations,Β unused code,Β performance problems, andΒ error-prone code.
Regardless of the software language(s) that you use, there are a number of static analysis packages available for it. And in addition to these packages, there is a range of online services, often able to scan multiple languages and frameworks.
Hereβs a short list for PHP (as itβs the language with which Iβm most intimately familiar):
- OWASP WAP: Web Application Protection
- Side Channel Analyzer:Β Static Analysis for Detecting Side-Channel Vulnerabilities in PHP applications
- psecio/parse:Β A static scanning tool to review your PHP code for potential security-related issues
- PHP-malware-finder:Β Attempts to detect obfuscated/dodgy code as well as files using PHP functions often used in malwares/webshells
- progpilot:Β A static analyzer for security purposes
- Codacy
With all these libraries and services, youβd be forgiven for thinking that static code analysis would be a panacea for your security problems? For example;
- Write your code
- Run an analyzer
- Correct what it finds
- Youβre done!
And in some ways, this process is just such a panacea. But it is not without limitations as well; limitations you need to be aware of.
These include:
- Identifying false positives and negatives during software scans.Β It can be hard to analyze code in the context of a larger codebase. For example, how do you validate all calls to a function and what parameters are passed to those calls? How do you programmatically validate a function which is part of a larger call-chain?
- Difficulty detecting hard to find vulnerabilities, such as access control errors and misconfigurations.Β Itβs common for aspects of an application to be configuration-based. A prime example is configuring access control lists. If the application being scanned is built this way, and a static code analyzer is only checking code, it may report the application as containing no known vulnerabilities, but miss an ACL misconfiguration. Whatβs more, how can a static analyzer fully understand ACL lists?
These are just two drawbacks to bear in mind when working with static code analysis; there are others. That said, static code analysis is an excellent way to automate the process of identifying an extensive range of security issues, well before your clients and users encounter them.
While not perfect (but what is) it goes a long way to finding issues with your code, that would not normally be detected consistently and predictably.
Static Code Analysis Has OtherΒ Benefits
Getting back to the positives, in addition to finding security problems, static analysis tools can also be used to educate developers about security issues and about how to write more secure code.
Well, designed ones will not only find valid problems, they will also explain why the problem was identified.
Secondly, they can help the team grow a sense of trust in the security-readiness of the software that theyβre producing. Theyβre not a panacea, but they can still help to know that quality is improving.
Thirdly, theyβre automatable, as they can be integrated with your teamβs development tools. These include IDEs such asΒ PhpStorm, and development pipelines such asΒ Phing,Β Ant,Β Make,Β Codeship, andΒ Capistrano.
For example, you could integrate WAP asΒ a run configurationΒ in PhpStorm, and run it intermittently. You could also integrate it as part ofΒ a Git commit hook.
Integrating them with existing tools and workflows will help ensure that theyβre used consistently. As we all know, if somethingβs too hard to set up or to use, itβs likely going to be avoidedβeven if itβs the best tool in the world!
One Thing To Remember!
By now, you may be thinking that the essential thing to scan is your applicationβs code. And youβd not be wrong. But do we write code in isolation? Do we ever write code that doesnβt have external dependencies?
Iβd suggest that unless itβs aΒ veryΒ small script, then it will always have at least one dependency, if not several. Looking specifically to the language which I spend most of my time with, PHP, Iβd say that, more often than not, theyβre going to have at least one very obvious dependencyβββapplication frameworks.
If you take a look at some of PHPβs top frameworks (Laravel,Β Zend Framework, andΒ Symfony), you can see that each of them has at least a handful of vulnerabilities, which can lead to exploits. If youβre using Ruby, what aboutΒ Ruby on Rails? If youβre using Python, what aboutΒ Django?
This isnβt meant as a hack job on any one of these frameworks. I mention them just to point out that you have to be holistic in your security thinking. Make sure that you check your external dependencies and frameworks to see if they have vulnerabilities which need patching.
A Step-through Example
Now that weβve had a good introduction to static code analysis and started considering what to scan, letβs work through how to use static code analysis to find and resolve security issues in our code.
In this example, weβll use Codacy to scanΒ the Laravel framework codebase, PHPβs most popular application development framework.
Weβre not going to go too deep into Codacy. Weβll just stick to the essentials of what we need to know so that you get a broad overview of how the service works and how scans work. If youβd like to explore further, however, feel free to do so.
First: Import the project intoΒ Codacy

To get your project into Codacy, the first thing that you need to do is to import it. This is quite trivial if your Codacy account is linked to either aΒ GitHubΒ orΒ BitbucketΒ account.
If so, as you can see in the image above, scroll through the list of projects, and check one or more of them that you want to import.

After that, the projectβs code will beΒ reviewed,Β cloned, andΒ analyzed. Depending on the size of the project, this may take a bit of time.
For what itβs worth, I imported a large project yesterday, which took about 15 minutes to prepare. However, Iβve never found the import process to take more than about 3β5 minutes normally.
Second: View The Security Vulnerabilities
Once the projectβs completed, youβll be redirected to the projectβs dashboard, which you can see above. As Codacy performs a wide-range of static code analysis, not just for security problems, youβll see project analysis for a number of those areas.
However, you can see a birds-eye-view security score on the lower left-hand side of the dashboard, just above βOpen Pull Requestsβ.

To view, the security vulnerabilities click βSecurityβ in the left-hand navigation menu. There, youβll see the 15 categories which Codacy uses to classify security problems; includingΒ Auth,Β CSRF,Β DoS,Β SQL Injection, andΒ XSS.
Only categories marked with a red cross contain security problems.

One thing to bear in mind; not all of the security patterns are enabled by default. This can be a good thing, depending on your projectβs age. In the example Iβm using,Β which is Laravel, this is not an issue.
You can see that it performs quite well, as youβd expect. However, it does show problems inΒ File Access,Β Input validation,Β Other, andΒ Regex. Looking in βOtherβ, you can see that one issue has been flagged in one file. The other categories only refer to the same file.
On a side note; as a PHP enthusiast, Iβm proud that no PHP-issues were found.
Three: View AnΒ Issue

Looking at the issue, you can see that itβs highlighted βGeneric Object Injection Sinkβ as the problem inΒ public/js/app.js
. Expanding it out further, you can see quite a detailed description of why the issue has been flagged and what it may mean.
Itβs worth noting here,Β again, that highlighted issues may be false positives or false negatives. So you have to be discerning when reviewing issues and determine if they are actually an issue or not.
Four: Fix anΒ Issue
When youβve found a genuine issue, something which needs fixing, you can begin doing so from the dashboard. Codacy helps you in two ways. Firstly, the dashboard gives you an estimate of the time it would take to fix. In this bugβs case, itβs anticipated that it should take no longer than 15 minutes to fix.
Secondly, you can create an issue in either GitHub or Bitbucket directly from the issue. By clicking βSettingsβ (the cog icon next to βView Fileβ)Β ->
βGitHubβΒ ->
Β βCreate Issueβ a popup window appears, which you can see below.
The window contains a default issue title, pre-filled with the identified issue, and a message with some default information, including the message, commit hash, file name, and line number.
From there, you can then resolve the issue with a future pull request, and then rescan the codebase to ensure that the issue is no longer reported.
Wind Up
And thatβs been a rapid introduction to static code analysis, how it can be integrated into one or more places in your development tools and workflow, as well as a working example of how to use it to identify (and stay abreast) of security vulnerabilities within your application.
If this is your first time hearing about the concept and the tools, I strongly encourage you to have a look through the supplied list of tools, along with the links in the further reading section.
That way, youβll progressively expand your knowledge and awareness of how to develop more secure, more robust software. If youβd like to know more about Codacy, feel free toΒ sign up for a 30-day trial, and begin analyzing your applications.
About Codacy
To help address software vulnerabilities Codacy is used by thousands of developers to analyze billions of lines of code every day!
Getting started is easy β and free! Just use yourΒ Β GitHub, Bitbucket or Google account toΒ sign up.