The Scanning Toolbox
Scanning code means different things to different people. Generally, an organization’s approach to security evolves as a software security initiative - and organizational skills mature. It’s important to remember that different security testing methodologies have advantages (or weaknesses) when attempting to identify different classes of vulnerabilities.
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. Frequently, 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 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 very good at identifying common vulnerabilities such as SQL Injection,
Cross-Site Scripting, and Buffer Overflows. They are less useful for issues such as authentication
and privilege escalation.
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 Scanning
Scanning applications with the aforementioned solutions inevitably identifies vulnerabilities. However, there are challenges to using these tools:
- Efficiency and Costs – As noted, some tools SCA can be used early in the development lifecycle to identify vulnerabilities. Others, like DAST, require a near-complete application in a staging environment, very late in the SDLC. The later a vulnerability is identified, the more expensive it is organizationally to remediate that vulnerability.
- False Positives – Scanning technologies are imperfect, of course, 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 takes scarce security resources, and remediating non-exploitable vulnerable components wastes development time.
- 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.
Threat Modeling Offers A Better Approach
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. Instead, potential threats and vulnerabilities should be identified before development begins, using security testing as a validation activity.
Threat modeling exercises examine 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 resources weeks to complete, and conflict with modern development efforts to “go fast”. The result is that threat modeling is used on a small number of applications.
Go Fast. Stay Safe.
A better approach is to “go fast and stay safe”. SD Elements automates threat modeling, automatically translates threats into a consistent set of actionable controls, and provides test cases to confirm that controls were implemented correctly. SD Elements provides thousands of commands and can map to an organization’s secure coding standards to build security activities into the daily development process. It acts as a guide for development and security teams, assigning specific activities through existing workflow tools.
With SD Elements, threat modeling can be performed on every application in minutes instead of weeks. Scanning then becomes a validation exercise, confirming that assigned activities were performed and reducing rework and remediation late in the SDLC. It gives organizations the ability to develop applications quickly and securely.