The second pillar in our four pillars of digital security is static analysis. Static analysis has been around for a long time. It is a method of examining source code without executing the program. Think of static analysis like spelling and grammar check for a document you are working on. It ensures you are using the correct structure in a sentence or paragraph. Making sure your periods and commas are where they need to be, and spelling and grammar are up to snuff.

This process provides an understanding of code structure and makes sure code adheres to certain standards. Standards such as OWASP. These standards not only look at code security but code quality as well. In my opinion, quality is just as important because poor quality can certainly leave you open to vulnerabilities.

There are a number of coding standards used by the wider security community. They can be specific to a particular industry, framework, or language. Finding and using the one that works best for your particular need is going to be much more useful to you. In some cases, you may not have a choice, as you may be obligated to follow a particular standard. Standards such as PCI or OWASP Mobile top 10 2016 which checks your code for uses cases like:

  1. Improper Platform Usage
  2. Insecure Data Storage
  3. Insecure Communication
  4. Insecure Authentication
  5. Insufficient Cryptography
  6. Insecure Authorization
  7. Client Code Quality
  8. Code Tampering
  9. Reverse Engineering
  10. Extraneous Functionality

Our mobile applications contain on average 170k lines of code. That doesn’t account for third-party libraries and the code they bring to the table. As you can see, that leaves a lot of room for error. Due to the fact we are asking more from our mobile apps, I expect the number of lines of code in apps to go up, despite how efficient languages are becoming.

Scanning source code with any scanner can be very noisy at first. It is important that you devote upfront the time needed to fine-tune the scanner, and reduce the number of false positives. If you do not, it will become very frustrating, and that’s when actual vulnerabilities get ignored. Over the years I have seen this happen time and time again. It is also important to have a process around what happens when a vulnerability is found, such as creating a ticket in a ticket/bug tracking system to be verified and addressed. If a ticket is never created, it means the problem did not exist.

If you have never partnered with a company to do static analysis scans, it can be very overwhelming at first. Here are some helpful questions to ask vendors you’re considering:

  • What languages do you support?
  • What fine-tuning features do you have?
  • Do you support coding standards out of the box? If so, which ones?
  • Can you document notes with the vulnerabilities you find? This will come in handy because there will be times you want to accept the risk. Documenting who made that decision and why can go a long way.
  • How do you integrate with a modern Continuous Integration (CI)/Continuous Delivery (CD) pipeline?
  • How quickly can you adopt new languages or updates to current languages? (ask for examples)
  • Can we add our own rules to your system for our project?

Something else worth mentioning while I have your attention. Scanning your code early and often in your SDLC will save you a significant amount of time and cost to fix the little issues you will find along the way. Otherwise, if you wait until the end of a project you have three choices:

  1. You delay the launch of your application.
  2. You devote time and more resources (cost) to fix critical issues and try to launch on time.
  3. You launch knowing you have critical vulnerabilities, which could open you up to a lawsuit of some kind. Especially if you store PII, financial information, or even just usernames and passwords.

Conclusion:

As you can see, scanning your source code can be a complicated task to onboard. However, once you get past the intitial learning curve and take care of the upfront work, it will benefit you in the long run. To reiterate: make sure you do your research on your code scanning platform, make sure you work with your teams to make implementation as pain-free as possible, and have a plan for late game vulnerabilities.