Static Code Analysis & Static Code Review: Are These Key SOC 2 Controls?

Static code analysis and static code reviews are key controls in a company’s control environment, specifically related to the system development lifecycle and change management processes, and should be considered for inclusion in a company’s SOC 2 control inventory.

Adopting static code analysis and static code reviews and integrating these controls into a Company’s control environment will assist to embed security into the company source code pipelines and protect against vulnerabilities and issues that frequently make their way into production environments.

What is Static Code Analysis?

Static code analysis is most often performed with automated tools that attempt to identify possible or probable vulnerabilities within a Company’s static source code. Static source code is non-running source code. Performing a static code analysis is a method of debugging by automatically examining source code before the program is run. It’s typically performed by analyzing a set of code against multiple sets of coding rules. The coding rules are best practice coding rules, as well as custom coding rules relevant to the Company performing the analysis. The static code analysis is attempting to find deviations in the code that could be incorrect, inefficient, poor style, or other imperfections.

Typically, static code analysis and static code reviews check for the following in the source code:

1. Code issues and security vulnerabilities.
2. Qualify of documentation.
3. Consistency in formatting with overall software design.
4. Compliance with project requirements, coding standards, and best programming practices.
5. Violations of rules and conventions impact on program execution.

 

Is Static Code Analysis the Same As a Static Code Review?

Static code review is not the same as static code analysis. Static code review is typically something people (humans) do, (rather than an automated or machine tool). Static code review may include a colleague/mentor/professor/friend reviewing a developer’s code and providing constructive criticism. While Static Code Analysis is typically performed with automated tools.

Static code analysis can be performed at the start of the system development lifecycle during source code development, or at a set periodic frequency over the entire code base. Static code reviews, on the other hand, would typically be performed at the start of the system development lifecycle during source code development.

Is Static Analysis Better Than Dynamic Analysis?

A Company may ascertain that static code analysis is not necessarily due to the performance of dynamic code reviews. It is accurate that both evaluation types detect defects. The difference is where they find defects in the code changes development process. As discussed previously, static analysis identifies defects before you run a program (e.g., between coding and potentially unit testing); while Dynamic code analysis identifies defects after you run a program (e.g., during unit testing).

Dynamic code analysis is a great control, however, IT management should keep in mind that some coding errors might not surface during dynamic unit testing. Therefore, there are defects that dynamic testing might miss that static code analysis could find. As a result, both dynamic and static reviews are both appropriate controls to maintain together in the system development life cycle.

 

Importance of Static Code Evaluations In a Company’s SOC 2 Control Inventory

The SOC 2 trust service criteria are focused on determining the suitability of the design and operating effectiveness of controls. Specifically, the controls that are relevant to the security, availability, or processing integrity of information and systems, as well as the confidentiality or privacy of the information processed by the systems.

Controls that may be considered in a healthy control environment that support a Company’s SOC 2 compliance are static code analysis and static code reviews. Static code evaluations (whether it be a review or analysis) fit nicely as a control within the AICPA SOC 2 under the Trust Service Control Criteria 8.1 –

“The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.”

However, the outcome and results of performing strong static code evaluations ultimately result in impacts on nearly all the Trust Service Criteria areas.

How Do Static Code Evaluations Impact the SOC 2 Trust Service Criteria Areas?

Wisdom says that secure systems require information technology (IT) administrators and users to:

1. Stay on top of security patches.
2. Use a firewall, ACLs, VPC, VPN, etc.
3. Scan regularly for viruses with up-to-date virus signatures.

While these are all sound tried and true controls, these are only partial controls to secure a system to be compliant with the SOC 2 trust services criteria. The methods described are defense mechanisms that protect the application and systems from pre-existing security flaws. To create truly secure systems a Company must have secure infrastructure and applications that are designed to withstand a malicious attack at the source code level. Many security bugs occur because the code expected certain input (the developer wrote code that expected certain input) and the attacker provided something different, and that difference caused a security issue.

Examples of vulnerabilities based on trusting input in code:

1. Buffer overruns.
2. Integer overflow attacks.
3. Cross-site scripting issues.
4. SQL injection attacks.

Many engineers have said that a fundamental building block of software is the code quality behind the software. Taking that one step further, the quality of code may directly relate to whether the software or software is secure, reliable, and stable. If the system is not reliable and stable, then controls in Logical Access, System Operations, Availability, Confidentiality, and Privacy are all subject to failures that could impact SOC 2 compliance.

This brings us back to static code analysis and code reviews. One of the best ways to determine that a Company has high-quality code in the Company’s control set is that the Company conducts periodic static code analysis and regular static code reviews. These code evaluations should not only be conducted on the new code that is being developed to be deployed to production, but also on the static code that the system is composed of. These tests may identify bugs and security vulnerabilities in the production environment that are new vulnerabilities after the original code was developed. Static code analysis may be incorporated into the software development life cycle at many different stages in order to incorporate quality assurance and enforce the use of coding standards prior to running the code.

 

Benefits of Static Code Analysis & Static Code Review

There are many benefits of static code evaluations even beyond the scope of SOC 2 compliance. These benefits may include:

• Cost and time savings.
• Improving code security.
• Lower amounts of code defects.
• Streamlined processes.
• Reduced risks associated with complex, large codebases.
• Continuous improvements.

The benefits of the static code analysis performed indirectly impact many areas of the SOC compliance, however, the benefit of improved code security has a direct impact on the SOC compliance. Code security is a major concern and must be analyzed for vulnerabilities such as insufficient encryption, research leaks, insecure interfaces, buffer overflows, etc.  Static code analysis can be configured to automatically check code for security flaws as the developers write it, which also helps to prevent data breaches. Incorporating these code checks early in the process as a preventative control can reduce both the cost and risk of downstream security threats.

Pitfalls to Static Code Analysis

A pitfall to static code analysis is that the tool used is dependent on factors that include:

• The type of development environment.
• Other development tools used.
• Specific Company frameworks.
• Codebase size.
• Code languages.
• The Company’s overall development workflow.

If the static code analysis tool is not configured properly, then the tools may have poor accuracy and longer scanning times.  These pitfalls may impact the developer’s trust and may also return false positives. When there are too many false positives, the development teams may start paying less attention to alerts, or ignore the alerts altogether. Therefore, it is critical to configure the static code analysis properly from the start.

Conclusion

In conclusion, a strong system development life cycle may include controls around:

1. Partition of development and production.
2. Documentation of code and code changes.
   1. Layered testing of code changes (static code analysis, unit, dynamic analysis, regression, continuous integration, end-to-end integration, acceptance, functional, etc.)
   2. Approvals for code changes.
   3. Peer Reviews for code changes.
   4. Change documentation is detailed.
3. Coding standards, practices, and methodologies for quality code.
4. Periodic code evaluations.
   1. Static code analysis.
   2. Dynamic code analysis.
   3. Statice code reviews.
5. Continuous training for developers and employees on new coding risks.
6. Segregation of duties (developer’s access to production restricted).
7. Code change monitoring.
8. Backups of code for recoverability consideration.

Static code analysis and static code reviews are key controls in a company’s control environment and should be considered by Company leadership for inclusion in the company’s SOC 2 control inventory.

If you have additional system development lifecycle control questions or are interested in learning more about your upcoming SOC reports or other needed audit services, reach out to Rhonda Willert and the team at Linford & Co.