Scanning Your Code for Software Security

Dynamic Analysis Security Testing

Organizations often begin their software security programs with “penetration tests” (pen tests) of their software.

Third-party pen tests satisfy regulatory requirements like PCI-DSS and do not require internal security expertise. The next step is to license a dynamic analysis (DAST) tool and run automated scans against an application.

Dynamic analysis tools test a running application to identify inputs and then feed (or “fuzz”) data to those inputs. Examples include SQL commands, long strings, negative numbers, and data that may not be expected in the field.  Among other vulnerabilities, DAST tools are effective at identifying input validation and memory allocation issues.

Static Analysis Security Testing

Static Application Security Testing (SAST) tools do not need a running application and therefore are used earlier in the SDLC. These tools also require more security expertise to manage and interpret results.

SAST tools work by “modeling” an application to map control and data flows. Rules can be run against the model to identify a wide variety of security issues.

Static analysis tools are quite effective in identifying common vulnerabilities such as SQL Injection, Cross-Site Scripting, and Buffer Overflows. They are rather less useful for issues such as authentication and privilege escalation.

Interactive Analysis Security Testing

Interactive Application Security Testing (IAST) tools use instrumentation to identify security vulnerabilities during normal functional testing.

This fits better with rapid development methodologies like Agile as it integrates security testing into the development process.

Source Composition Analysis

OWASP lists “Using Components with Known Vulnerabilities” in 3rd party and open source components as one of the top 10 issues in web application security.

As open source adoption has increased (and thousands of new vulnerabilities are disclosed each year) the need to identify vulnerable components has become more critical.

Since tools like SAST and DAST are largely incapable of identifying these components or vulnerabilities, organizations have adopted Source Composition Analysis (SCA) tools, which scan code simply to identify open source components. The resulting list of components, or Software Bill of Material (SBoM), can then be mapped to a database of licenses and publicly disclosed security vulnerabilities to flag vulnerable components.

Challenges with vulnerability scanning

There’s no doubt that the methods listed above help DevOps teams in identifying vulnerabilities in their applications. However, there are challenges with using these tools:

• Efficiency and cost of remediation: As noted, some tools can be used early in the development lifecycle to identify vulnerabilities. Others, like DAST, require a near-complete application in a staging environment, for testing. The later a vulnerability is identified, the more expensive it is to remediate that vulnerability.
• Large number of false positives: Scanning technologies are imperfect, and prone to reporting false positives. SAST tools, in particular, are notorious for “noisy” results including many informational issues. SCA tools will report on the presence of a publicly disclosed vulnerability, but not on the exploitability of that issue in the application under test. “Scrubbing” scan results to remove false positives can require significant involvement of scarce security experts. In addition, remediating non-exploitable vulnerable components wastes the time of development teams.
• Incomplete coverage: Because of limitations in time and technology, scanning rarely covers 100% of an application’s codebase or functionality. This means critical configuration issues or unsafe code constructs may not be identified.

Integrate security early in the development process

Vulnerability or security scanning is one of many security activities available to organizations. While scanning is a good exercise, it should not be an organization’s primary security activity.

Security scanners find vulnerabilities after they have been produced which is an inefficient method to build security into software.

Instead, potential threats and vulnerabilities should be identified before development begins, using security testing merely as a validation activity.

Mature organizations focus on prevention; helping developers by building security tasks into their requirements.

For instance, threat modeling examines an application’s technology stack, deployment environment, and architecture to identify likely attack vectors and controls that can be implemented to reduce risk. Traditionally, these exercises take senior security experts weeks to complete, and conflict with agile development efforts. However, automating threat modeling processes can help organizations identify threats faster, and ensure security.