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.