Do you subject your code to static code analysis and/or static application security testing prior to release?

penetration test

A penetration test, or pentest, is an exercise where a group, usually a third party, attempts to gain access to the target’s network or system. The group could be a dedicated internal group, but is usually a third party specializing in security and penetration testing.  Permission is granted to this group in an attempt to gain elicit access to the system, often without the knowledge of the internal security team, except for management, or higher level engineers.


The purpose of this exercise is to determine if there are weaknesses or vulnerabilities in the system that are not detected by vulnerability scans.  These vulnerabilities may be because of the system design, social engineering weaknesses, business logic weaknesses, or other factors that are not detected through automated methods.

Why are they asking this?

Customers know that there are other types of vulnerabilities besides technical vulnerabilities in the software.  They want to be assured that the organization also understands that and is working to detect and address these weaknesses.  A penetration test shows that your organization is committed to finding these weaknesses. The use of a third party for penetration testing provides for different thoughts and ideas that may help remove the inherent bias that often exists when an organization looks at their own work.

What do they expect?

Customers may ask to review the pentest report from the organization that performed the test.  This generally contains sensitive information and is often not fully shared with customers or potential customers.  Often it is agreed upon that the executive summary with a summary of the findings and no technical details is shared.  If that is not sufficient due to special requirements by the customer, sometimes the customer is invited to review the whole pentest report, under NDA, in the provider’s facility with control over notes taken as not to expose highly sensitive technical information.

static code analysis

Static Code Analysis (SCA) is the process of analyzing the source code to an application without executing the application. The SCA reads in the code and looks for errors and vulnerabilities that exist in the code.  Some examples that the analyzer may look for include:

  • Not initializing variables before use

  • Known unsafe function calls

  • Inconsistent interface between modules and components.

  • Unreachable code or “Dead Code”

  • Failure to follow standard coding practices

  • Syntax violations

Why are they asking this?

Failure to use SCA on your source code can leave vulnerabilities in your application undetected. 

While SCA may not detect every vulnerability, it will help eliminate the common ones and the easy to exploit ones.

What do they expect?

It is expected that you have a robust software development life cycle (SDLC) that includes static code analysis in addition to other measures to ensure that the code is not vulnerable.