Source Code Security Review

Application Security Testing

Source code review is one component of a complete application security program. Organizations that need to validate the security of deployed applications, identify vulnerabilities in running software, assess open-source dependency risk, and integrate security testing into their development pipeline require a broader set of testing services. GDF provides the full spectrum of application security testing methodologies, delivered with the forensic documentation standards required when findings must support legal proceedings, regulatory submissions, or executive risk decisions.

Static Application Security Testing (SAST)

Static application security testing analyzes application source code, bytecode, or compiled binaries without executing the application. SAST identifies vulnerabilities in the code itself: injection flaws, authentication weaknesses, insecure cryptographic implementations, hardcoded credentials, and unsafe API usage that will be present in every deployment of the application regardless of its runtime configuration.

GDF's SAST approach combines automated analysis tools with manual review to address the principal limitation of automated SAST: high false-positive rates that reduce the signal-to-noise ratio of findings to the point where development teams stop acting on them. GDF uses industry-standard tools including Semgrep, Checkmarx, Veracode, and Fortify as an initial screening pass to identify candidate findings across large codebases. Every flagged finding is then manually triaged by a GDF analyst to verify exploitability, eliminate false positives, and add the contextual analysis that explains why the finding represents a real security risk rather than a syntactic pattern match.

Manual SAST also identifies vulnerability classes that automated tools cannot detect: complex multi-step vulnerability chains where each individual code pattern is benign in isolation, business logic flaws that require understanding of the application's intended behavior, and intentional malicious logic that is designed to evade automated detection. For software involved in litigation, insurance claims, or regulatory proceedings, manual SAST produces findings with the level of technical detail and documentation rigor needed to withstand adversarial scrutiny.

Dynamic Application Security Testing (DAST)

Dynamic application security testing examines a running application by sending requests to its interfaces and analyzing responses for security vulnerabilities. Where SAST identifies vulnerabilities in code, DAST identifies vulnerabilities in the deployed, running application, including those introduced by configuration, deployment environment, and runtime dependencies that are not visible in source code alone.

GDF's DAST engagements begin with application reconnaissance: mapping every endpoint, parameter, and functionality accessible through the application's interfaces. This mapping ensures that testing coverage is complete and that findings are presented with accurate endpoint context. For web applications, this covers all HTTP methods, authentication-protected endpoints accessible with test credentials, API endpoints documented and undocumented, and file upload and processing functionality. For mobile applications, DAST covers the application's network communications in addition to the interfaces exposed by any server-side components.

Automated DAST scanning using tools such as Burp Suite Pro, OWASP ZAP, and Nuclei provides broad coverage of common vulnerability classes including injection points, authentication bypass vectors, and security header deficiencies. Manual DAST testing by GDF analysts addresses the application's specific functionality: testing business logic flows for race conditions and authorization failures that automated tools cannot identify, testing complex authentication sequences, and following up on automated findings that require manual confirmation or chaining with other findings to achieve meaningful impact.

DAST findings are presented with complete reproduction evidence: the exact HTTP requests and responses that demonstrate the vulnerability, the authentication context required to reach the vulnerable endpoint, and the impact that would result from exploitation. This documentation supports both developer remediation and any legal or regulatory use of the findings.

Interactive Application Security Testing (IAST)

Interactive application security testing instruments the application at runtime to observe security-relevant behavior from inside the execution environment. Unlike DAST, which examines the application's external interfaces, IAST monitors internal code execution paths, data flows, and API calls as the application processes requests. This provides vulnerability detection with the accuracy of static analysis (because the analysis occurs at the code level) and the coverage of dynamic testing (because it only analyzes code that actually executes during the test session).

GDF deploys IAST using agent-based instrumentation frameworks compatible with Java, .NET, Python, Node.js, and Ruby applications. During a test session, the IAST agent records data flows from user-controlled input through the application's processing logic to any sink that could represent a vulnerability: database queries, operating system commands, file system operations, external HTTP calls, and serialization operations. Findings are correlated with the exact source code location and execution path, providing the level of precision needed to prioritize remediation without manual triage.

IAST is particularly effective for identifying vulnerabilities in complex applications where the code paths that handle user input are difficult to trace statically. In multi-tier applications where data passes through multiple services before reaching a vulnerable sink, IAST tracks the data flow across service boundaries, identifying injection vulnerabilities that would require manual analysis of multiple codebases to find through SAST alone.

Software Composition Analysis (SCA)

Modern applications include a significant proportion of open-source and third-party components: libraries, frameworks, SDKs, and container base images that may comprise the majority of the application's executable code. These components introduce both security risk (known vulnerabilities in dependency versions that the organization has not updated) and legal risk (license obligations that the organization may not be meeting). GDF's software composition analysis identifies and assesses both dimensions.

GDF's SCA process generates a software bill of materials (SBOM) for the assessed application, identifying every direct and transitive dependency with its exact version. This inventory is checked against multiple vulnerability databases including the National Vulnerability Database (NVD), GitHub Advisory Database, and vendor-specific advisories to identify components with known vulnerabilities. Findings are prioritized by exploitability (is the vulnerable code path reachable in this application's deployment context?) and severity (what is the potential impact if the vulnerability is exploited?), not simply by CVSS score.

For organizations involved in M&A transactions, SCA findings on the target company's software identify dependency-related security liabilities that should be considered in valuation and indemnification negotiations. For organizations subject to supply chain security requirements under NIST SP 800-161, Executive Order 14028, or sector-specific frameworks, GDF's SCA provides the SBOM documentation and vulnerability assessment that these requirements mandate. For software involved in breach litigation, SCA findings establish whether known-vulnerable dependencies were present in the deployed version at the time of the incident.

API Security Testing

APIs are the primary interface through which modern applications exchange data and invoke functionality. They are also the primary attack surface in a majority of application security incidents. GDF's API security testing applies the OWASP API Security Top 10 framework to identify the vulnerability classes most commonly exploited in API-focused attacks: broken object-level authorization, broken authentication, excessive data exposure, lack of resource and rate limiting, broken function-level authorization, mass assignment, security misconfiguration, injection, improper asset management, and insufficient logging and monitoring.

Testing covers REST APIs, GraphQL APIs, SOAP web services, gRPC services, and proprietary API protocols. For each API surface, GDF tests authentication controls (including token handling, key management, and OAuth implementation quality), authorization enforcement (verifying that each endpoint enforces appropriate access controls and does not permit horizontal or vertical privilege escalation), input validation (testing each parameter for injection vulnerabilities), and data exposure (verifying that responses do not include sensitive fields not required by the requesting client).

GraphQL-specific testing includes introspection abuse (verifying whether schema introspection is disabled in production, preventing attackers from enumerating all available types and fields), nested query depth and complexity limits (testing whether the API enforces controls that prevent resource exhaustion through deeply nested queries), and batching attack resistance (testing whether the API prevents abuse of query batching to bypass rate limiting).

Mobile Application Security Testing

Mobile applications present security risks distinct from web applications, arising from the combination of client-side code that can be reverse engineered, device-level data storage, and network communications that may traverse untrusted networks. GDF's mobile security testing covers both iOS and Android applications using the OWASP Mobile Security Testing Guide (MSTG) as the primary framework.

For Android applications, testing covers APK decompilation and static analysis of Java/Kotlin bytecode and native libraries, manifest analysis for over-permissioned components and exposed intent filters, data storage assessment (checking SharedPreferences, SQLite databases, and external storage for sensitive data stored without encryption), and network communication analysis for certificate pinning implementation and TLS configuration. Dynamic testing on a rooted test device covers runtime analysis of the application's behavior, hooking of security-relevant API calls using Frida, and testing of SSL pinning bypass resistance.

For iOS applications, testing covers IPA extraction and static analysis of Swift and Objective-C binaries, plist file analysis for sensitive configuration data, keychain usage assessment, and binary protection verification (stack canaries, PIE, ARC). Dynamic testing on a jailbroken test device covers runtime behavior analysis, class dumping to identify undocumented functionality, and testing of jailbreak detection mechanisms.

DevSecOps Integration and CI/CD Pipeline Security

Effective application security requires integrating security testing into the development lifecycle rather than treating it as a gate applied before deployment. GDF assists organizations in designing and implementing DevSecOps programs that embed SAST, SCA, and secrets scanning into CI/CD pipelines, ensuring that security findings are identified early in the development process when remediation cost is lowest.

CI/CD pipeline security review examines the build and deployment infrastructure for security weaknesses that could allow an adversary to compromise the software supply chain: unauthorized access to the build environment, pipeline configurations that allow injection of malicious code into build artifacts, insecure handling of secrets such as code signing certificates and deployment credentials, and inadequate artifact integrity verification that could allow a tampered build artifact to reach production.

GDF's DevSecOps integration work produces a security testing architecture tailored to the organization's existing toolchain, recommending specific tools and configurations for SAST (Semgrep, CodeQL, or Checkmarx depending on language stack and existing tooling), SCA (Dependabot, Snyk, or OWASP Dependency-Check), secrets scanning (truffleHog, GitGuardian, or GitHub Secret Scanning), and container image scanning (Trivy, Grype). For organizations that also conduct vulnerability assessments of deployed applications, GDF coordinates application security testing findings with our vulnerability assessment services to ensure that CI/CD findings and deployed application findings are tracked in a unified remediation workflow.