Skip to main content

Dependencies and SCA

Vulkro inventories the third-party code your Salesforce project pulls in (installed managed packages, JavaScript shipped inside static resources, and the dependency declarations in your project manifest) and matches each entry against the offline CVE bundle and the offline threat-intel catalog that ship with the scanner. Everything runs locally: no component name, version, or hash leaves the machine.

The dependency surface is one of the most under-audited corners of a Salesforce org. A managed package can sit installed for years past its support window, and a vendored JavaScript library tucked inside a static resource never shows up in an Apex scan. The findings below close that gap.

SF-SCA-001: vulnerable managed package​

Triggers when an installed managed package (resolved from the project manifest or the retrieved InstalledPackage metadata) matches a namespace and version range with a known advisory in the offline CVE bundle.

Why it matters: a managed package runs with its own namespace and often with elevated trust. A package version carrying a published advisory means the vulnerable code is already live in the org, regardless of how clean your own Apex is.

How to fix: upgrade the package to a version at or above the fixed version named in the finding. If no fixed version exists yet, record the advisory ID in your risk register and constrain the package's exposure (restrict its profiles and permission sets) until a patched release ships.

SF-SCA-002: end-of-life or unsupported package​

Triggers when an installed package version is past its vendor support window or has been superseded by a release line the vendor no longer backports fixes to. The end-of-life dates are part of the offline threat-intel catalog.

Why it matters: an unsupported package receives no security fixes. Even with no advisory today, the next vulnerability discovered against it will never be patched on your installed line, so the risk only grows.

How to fix: move to a supported version or supported successor package. When the upgrade is blocked by a customization, plan the migration and treat the finding as a standing item until the package is back inside its support window.

SF-SCA-003: vulnerable JavaScript in a static resource​

Triggers when a JavaScript file bundled inside a staticresources archive (or shipped as a standalone .resource) matches a known vulnerable library version. Vulkro fingerprints the library and version from the file content, so a renamed or concatenated bundle is still matched.

Why it matters: a vendored library inside a static resource is invisible to most dependency tooling, which inspects only package manifests. A known-vulnerable copy of a front-end library (for example a templating or DOM-manipulation library with a published XSS or prototype-pollution advisory) ships to every page that loads the resource.

How to fix: replace the bundled library with a patched version, rebuild the static resource, and redeploy. Where the library is no longer needed, remove it from the bundle entirely.

SF-SCA-004: unpinned dependency​

Triggers when a dependency declaration resolves to a floating or open-ended version range rather than an exact version, so the deployed artifact is not reproducible from the manifest alone.

Why it matters: an unpinned range means a future install or rebuild can silently pull a different version than the one you reviewed. That breaks reproducibility and lets a compromised or vulnerable upstream version enter the org without any change to your own source.

How to fix: pin the dependency to an exact version. Re-run the scan after pinning so the resolved version is checked against the CVE bundle.

Offline threat intelligence​

The next three findings draw on the offline threat-intel catalog rather than the CVE bundle. They detect posture problems that are not tied to a single advisory but still expand the attack surface.

SF-THREAT-API-EOL-001: apiVersion below the supported floor​

Triggers when a component's apiVersion is below the configured floor. The floor defaults to the catalog value and can be overridden with the VULKRO_SF_API_VERSION_FLOOR environment variable.

Why it matters: a low apiVersion opts the component out of platform security defaults that newer API versions enforce by default (for example stricter sharing and field-level enforcement behavior). The component keeps running under the older, weaker contract.

How to fix: raise the component's apiVersion to or above the floor and retest. To enforce a stricter floor than the catalog default across a project, set VULKRO_SF_API_VERSION_FLOOR to your target version before running the scan.

# Enforce an organization-wide apiVersion floor of 59.0 for this scan.
VULKRO_SF_API_VERSION_FLOOR=59.0 vulkro-sf sca .

SF-THREAT-CERT-EXPIRED-001 and -002: expired or soon-to-expire self-signed certificates​

SF-THREAT-CERT-EXPIRED-001 triggers when a self-signed certificate in the project metadata is already past its expiry date. SF-THREAT-CERT-EXPIRED-002 triggers when a self-signed certificate is inside the warning window (expiring soon) but has not yet lapsed.

Why it matters: an expired certificate breaks the integration that depends on it (signed callouts, single sign-on, or named-credential authentication), which often pushes teams toward an insecure workaround under time pressure. A soon-to-expire certificate is the same incident waiting to happen on a known clock.

How to fix: rotate the certificate and update every integration that references it before the expiry date. Treat the -002 warning as the lead time to schedule the rotation without an outage.