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.