Security Considerations for SCA Resolver and OSA Scanning
OSA and SCA Resolver analyze a project's third-party dependencies by invoking the native package manager associated with the target language (for example, pip for Python, npm for Node.js, Maven for Java). As part of standard dependency resolution, these package managers may retrieve packages from any repository or URL referenced in a project's manifest files, and some package formats (such as Python source distributions) execute installer scripts during resolution. This is standard behavior of the underlying package managers and is not unique to OSA or SCA Resolver.
This guidance applies to OSA and to SCA Resolver, which run dependency resolution on infrastructure that you control. It does not apply to cloud-based SCA scanning, where dependency resolution occurs within Checkmarx-managed infrastructure.
Because OSA and SCA Resolver resolve dependencies using the same mechanisms a developer's local environment would use, organizations should apply the same security controls to the infrastructure that runs them that they would apply to any environment that installs third-party code. Checkmarx recommends the following:
Run dependency resolution in an isolated environment. Where possible, perform dependency resolution within an isolated CI/CD pipeline job or dedicated execution environment, rather than directly on the CxSAST Manager. Apply appropriate security controls to the environment performing dependency resolution, consistent with the organization's existing software build and dependency-management practices.
Note
For OSA: When OSA dependency resolution is initiated through the CxSAST Web Portal or REST API, package managers may run on the CxSAST Manager host. In this case, some of the controls below may not be practical. These controls are marked "where possible" or "where supported".
Restrict dependency sources. Where possible, configure your package manager tooling and network policies so OSA and SCA Resolver can only resolve dependencies from approved, vendor-maintained registries (e.g., PyPI, npmjs.com, Maven Central) or an internal artifact repository/proxy (e.g., Artifactory, Nexus). Avoid allowing resolution from arbitrary external URLs.
Guard against dependency confusion and typosquatting. When internal or private package names overlap with names available on public registries, ensure package manager configuration enforces correct namespace/scope resolution and prioritizes the intended internal source. Review manifests for unfamiliar package names that closely resemble known internal or popular public packages.
Verify package integrity. Where supported, enforce lockfiles (e.g., package-lock.json, Pipfile.lock, requirements.txt with hashes, Maven checksums) and checksum/signature verification, so that dependency resolution fails closed on tampered or unexpected package content rather than silently installing it.
Isolate the scanning environment. Where possible, run OSA and SCA Resolver scans (particularly for on-prem/self-hosted deployments) in a segmented network zone with no access to internal systems, production credentials, or sensitive data stores. Ephemeral, single-use scan environments further reduce exposure.
Limit credentials available to the scan environment. Where possible, scan hosts should hold only the minimum registry authentication needed to reach approved sources (e.g., a scoped Artifactory/Nexus token) and nothing else (no CI/CD secrets, cloud metadata access, or credentials unrelated to dependency resolution) so a malicious install script has nothing valuable to exfiltrate.
Apply egress controls and monitoring. Where possible, restrict and log outbound network traffic from scan hosts. Alert on connections to unexpected or non-registry destinations, which may indicate a malicious dependency attempting to phone home or execute code.
Apply resource limits to scan execution. Where possible, constrain CPU, memory, disk, and execution time for dependency resolution and install-script execution to reduce exposure to zip bombs, decompression bombs, or scripts designed to exhaust host resources.
Limit who can submit projects for scanning. Only trusted, authenticated users should be able to upload source or trigger OSA or SCA Resolver scans, since a malicious or compromised manifest file (e.g., requirements.txt, package.json, pom.xml) is the primary vector for abuse.
Review manifests before scanning untrusted code. If scanning third-party or externally sourced repositories, review dependency manifests for unfamiliar or suspicious package sources before submitting them for scanning.
Consider hardened package manager configurations. Where supported by your package manager ecosystem, disable or restrict install-time script execution (e.g., build hooks, setup.py) for dependency resolution steps that don't require it.
These controls apply broadly across the package ecosystems that OSA and SCA Resolver support and are recommended as standard practice for any dependency-resolution tooling, not specific to a single language or package manager.