CIS Controls CIS-16.12

Static and dynamic application security testing can identify exploitable application weaknesses such as injection flaws, unsafe input handling, authentication defects, and other code-level vulnerabilities before or during release, reducing opportunities to exploit public-facing applications.

Where code-level security checks scan application code, configuration, and repositories for hardcoded or otherwise insecurely stored credentials, exposed authentication material can be identified and removed before release, reducing opportunities for adversaries to obtain and abuse valid accounts.

Code-level security checks within the application lifecycle can identify vulnerable, malicious, or unexpected code and software components introduced through software supply-chain compromise. This relationship applies to software and development-chain compromise that can be detected through static, dynamic, dependency, integrity, or release-pipeline analysis.

Static analysis, dependency review, and build-pipeline security checks can identify vulnerable, unexpected, or suspicious third-party dependencies and development artifacts before they are incorporated into or released with enterprise software.

Automated or manual code review, static and dynamic testing, and release-pipeline integrity checks can identify unexpected or malicious modifications introduced into software before the compromised build or update is distributed.

Code-level and build-time security checks can identify unsafe executable or library search paths, missing integrity values, and other application-loading conditions that permit adversaries to hijack execution flow, allowing those weaknesses to be corrected before release.

Static and build-time checks can identify insecure DLL search behavior and verify expected library paths or manifest integrity information, reducing opportunities for malicious DLL side-loading or search-order hijacking in developed applications.

For applications that use inter-process communication, code-level security checks can verify hardened runtime settings, entitlements, and IPC-related security configuration so insecure development settings that permit unauthorized process interaction can be identified before release.

For macOS applications using XPC services, build and code-level checks can verify hardened runtime and entitlement settings and identify insecure configurations that could allow unauthorized interaction with or abuse of XPC services.

Static and dynamic security checks can verify secure implementation of token handling and token-binding or proof-of-possession controls, helping identify application designs that would allow stolen authentication material to be reused without the intended cryptographic or device-bound protections.

Code-level and dynamic security testing can identify insecure application access-token handling and verify token-binding or proof-of-possession protections, reducing the ability to reuse a stolen application token outside its intended security context.

Static and dynamic security testing can verify application controls that validate authentication requests, such as one-time values, timestamps, sequence numbers, digital signatures, or random session keys, helping identify weaknesses that could otherwise be exploited to obtain credential material.

Where development or release pipelines validate code signatures as part of code-level security checks, invalid, missing, or untrusted signatures can be identified before software is released, reducing opportunities to distribute or execute software that misrepresents its authenticity or provenance.

For macOS applications, code-level and build-pipeline checks can verify hardened runtime, signing, and expected application configuration settings, helping identify insecure development conditions that could make application behavior or configuration more susceptible to malicious plist modification.