Using SCA Resolver in Checkmarx One

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.

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.