Support for pnpm-lock.yaml now makes the PNPM lockfile the authoritative dependency source, giving release owners evidence for the exact direct and transitive versions recorded for a project.
What changes for PNPM projects
For projects containing pnpm-lock.yaml, SCA resolves dependencies from that file rather than applying NPM-based resolution. This matters because transitive dependency paths and versions can differ materially between package-management approaches.
The practical result is more defensible vulnerability and license findings for PNPM-managed applications:
- Direct and transitive packages follow the versions recorded by PNPM.
- Security triage is based on the dependency graph teams intend to install.
- License reviews can be tied to a defined lockfile state.
- Release approvals have better evidence when a dependency-related exception is requested.
Projects without pnpm-lock.yaml retain existing NPM resolution behavior. Teams do not need to reconfigure those repositories.
Resolver 2.14.11 expands deployment and artifact coverage
SCA Resolver 2.14.11, released July 22, 2026, adds ARM64 installation files for each supported operating system. This is relevant to organizations standardizing build runners on ARM-based cloud infrastructure or supporting mixed CPU architectures across engineering environments.
The resolver also adds support for extracting these formats:
.whl.tgz.rpm
Additional optional arguments, --include-archive-files and --include-extensionless-archives, allow teams to include custom archive extensions and extensionless archives in extraction. These settings should be governed carefully: broader extraction can improve artifact visibility, but it may also increase scan time and the volume of components requiring review.
The resolver changes also makes PNPM package-manager support available at the tooling layer. Platform teams should align resolver upgrades with the PNPM lockfile scanning policy so developer workstations and CI runners produce consistent results.
More targeted SBOM generation
Resolver 2.14.11 adds packages-only and binary-only arguments for SBOM generation. This gives security, legal, and operations teams a way to produce inventories matched to the question being asked.
For example:
- Use package-focused SBOMs for open-source component and license review.
- Use binary-focused SBOMs when assessing distributed artifacts or operational exposure.
- Define which SBOM type is required for releases, customer requests, and audit evidence.
The SBOM output format has also been corrected to use camelCase rather than PascalCase. Teams that parse SBOM fields in downstream reporting, asset inventory, or compliance workflows should regression-test those integrations before broad rollout.
Governance actions for release and platform owners
The release is not only a scanner upgrade. It changes the quality of dependency evidence available for PNPM repositories and expands the scope of artifacts that can be inspected.
A controlled adoption plan should include:
- Identify repositories using PNPM and confirm
pnpm-lock.yamlis committed and current. - Compare pre-upgrade and post-upgrade findings on a representative set of services.
- Upgrade CI runners and developer tooling where ARM64 or new extraction support is needed.
- Set approved use cases for custom archive extraction options.
- Test SBOM consumers for camelCase field handling and define required SBOM scope by release type.
These controls support repeatable release decisions. They also help auditors distinguish between a finding caused by a genuine component exposure and a finding caused by incomplete dependency resolution.
Standalone SCA scope
These release notes apply to the standalone SCA product. Organizations consuming SCA through Checkmarx One should consult the Checkmarx One release notes to verify when equivalent capabilities are available in that service.
Do not assume feature parity merely because the underlying capability exists in standalone SCA. Release governance, pipeline documentation, and control testing should follow the product deployment actually in use.
How Merito helps
Merito helps enterprise teams implement SCA changes without treating them as a simple agent upgrade. We assess repository and pipeline patterns, validate PNPM lockfile coverage, establish SBOM governance, and test downstream integrations affected by output changes.
We also help define ownership for dependency exceptions, artifact-scanning scope, and audit evidence retention. This gives security and delivery leaders a usable operating model, not just additional scan capability.
Merito is an authorized Checkmarx reseller and services partner. Our Checkmarx SCA team can scope licensing, sizing, and rollout for July 2026, and our enterprise upgrade services help you plan and validate the upgrade with minimal disruption to release schedules.