How to perform static code analysis

Some of your organization’s biggest security vulnerabilities just might be lying beneath the surface of your source code. Common security frameworks, such as the OWASP Top 10, point to several vulnerabilities that are rooted in how source code is written. Threats of injection and insecure design, along with ineffective cryptography and type violations can all stem from insecure source code. The solution? Implement tools and practices that empower your team to perform secure coding and static analysis of code on a regular basis.

What is static code analysis?

Static code analysis analyzes source code in search of bad quality code, potential vulnerabilities, and other types of flaws. It’s most effective when used at the beginning of the software development life cycle (SDLC) and then continued throughout. When used for security purposes, it’s known as static application security testing (SAST).

SCA tools enable development teams to shift left — applying code fixes earlier in the software development process — by empowering them to fix errors while code is still fresh on their minds. Implementing static code analysis tools for code scanning greatly improves an organization’s security posture by catching vulnerabilities and enabling teams to remediate them before the code ever runs. 

Why do development teams do static code analysis?

There have been static code analysis tools since the mid 1970s, but it has been shown that developers try to circumvent these tools. The main complaints are that these tools are very slow, produce too many false positives, and the presentation of results is hard to understand and act upon. So, most of the time, it falls on peer code reviews to ensure code security.  

Developers have to spend extra hours to perform this function, yet still miss important details, due to human error. The use of automated static code analysis tools enables teams to dramatically improve overall accuracy and efficiency. Modern tools like Snyk Code solved the scan time and actionability issue and can significantly speed up the code production process.

The best results are achieved when tools are automated and included into any step of the integration and deployment of an application. Modern applications use fully automated CI/CD pipelines. Modern static code analysis tools integrate into every step. It starts with being available in the developer workbench (IDE), includes scanning every change on the code base within the version management system, scanning during the build and more.  

How to perform static code analysis for security and quality

In the past, SAST was used mainly by the security teams and in an audit manner: Security scans produced reports and were fed back to developers using tickets. Automated static analysis of code followed by manual remediation should be a developer-friendly practice that empowers development teams to create more secure code, rather than a drag on their time and hindrance to their productivity. SAST can be easily integrated into a typical CI/CD pipeline, as it takes a minimal amount of extra time to complete, is automated, and can interface directly into early stages of the SDLC. Here’s how to get started on using a SAST tool within your organization:

1. Select a tool.

You’ll want to select a tool that can flag errors that fall under two different categories:

• Quality – Does the code have any programming errors such as undefined values, syntax or standard violations, etc.? 

• Security – Is the code built with insecure design, and does it contain any vulnerabilities?

2. Run the tool on the code, using predefined rules and conditions.

After you’ve established how your code gets selected, in relation to the rest of your developers’ overarching processes, it’s time to run the tool itself. Depending on your teams’ needs, you can start the scanning process with a manual kick-off or an automation that’s set to run at a specific stage (e.g. after each pull request, etc.). Your analysis tool should be equipped with predefined rules and conditions, including in-house parameters and standard security frameworks. 

3. Review the results, including screening for false positives.

Always use a tool with a low false positive rate to keep your developers happy. But no tool is perfect, so it's important to screen the results for false positives. To determine whether or not a flagged error is legitimate, you need to dig into the exact location and cause of the vulnerability. 

It’s important for your tool to include detailed reporting features such as explaining how the error was created and what the exact risk factors are. This way, your team can easily pinpoint whether or not a given result is a legitimate one, or a false positive. As mentioned, it also helps to use a static code analysis tool that actively works to avoid false positives in the first place. 

4. Prioritize the fixes by urgency.

The fixes should be prioritized by risk level, urgency and type. The context of the vulnerability (i.e. where it’s located in your application’s infrastructure or what type of data it’s adjacent to) should be taken into account during triaging. Some tools — like Snyk Code — have the ability to perform this step automatically, using artificial intelligence to help developers see the errors in context. Additionally,  an issue type typically has several appearances in a given project. Clustering issues of the same type helps to learn how to fix an issue once and apply it several times at once.

5. Execute the fixes, starting with the most urgent ones.

The last step: to remediate any code errors. This can seem intimidating to developers who aren’t familiar with secure coding practices. So, it’s essential to use a tool that includes actionable steps for fixing found vulnerabilities. Static application security testing should not only be focused on remediation, but also on educating your teams. A good SAST tool gives teams the details and actionable follow-up steps that they need to grow in their secure coding practices. 

How to choose a static application security testing tool

There’s a variety of SAST tools out there, so your team will need to answer a few questions to discover which one is the best fit for you and your existing processes:

• Language/framework compatibility. Does this tool accommodate your teams’ primary coding languages and frameworks?

• Integration with other development tools. Does this tool integrate with your existing solutions, such as CI/CD pipeline tools and source code repositories?

• Low false positives. How does this tool account for false positives? Since many SAST tools are notorious for providing inaccurate results, does your chosen tool include additional features for avoiding false positives? 

• Scanning speed. Does the tool check code in a reasonable amount of time, so your developers can implement fixes in real time? 

• Detailed reporting. Does the tool report back vulnerabilities in an easy-to-comprehend, developer-friendly format? And does it suggest actionable steps for remediating any found vulnerabilities?

Static application security testing has to be developer-friendly. It’s all about using a tool that will integrate seamlessly into your existing pipeline and provide actionable, accurate results. The goal: to empower your developers to shift security left, as well as grow in their secure coding skills with educational resources.

Snyk Code, our SAST tool, facilitates this approach to static code analysis with built-in, human-in-the-loop AI that has ingested millions of open source libraries. It’s built to provide intelligent, contextual scan results and provide practical remediation steps so your developers can make fixes in minutes, then get right back to coding. Want to see Snyk Code in action? Try our free code quality & vulnerability checker today. 

Performing static code analysis FAQ's