Vulnerable dependencies

Check method

Known advisories matched against the project's real lockfile versions.

Possible evidence type

Live observation when the check is compatible and authorized. This description does not mean your platform has been tested.

Access and limitations

Connected repository. Actual results and checks not run appear in your report. A check with no finding does not guarantee the absence of risk.

Concrete scenario

A lockfile resolves a package version listed in a security advisory.

What to inspect

Check the affected version range, usage and fix availability. Advisory presence is not always demonstrated exploitability.

Remediation approach

Upgrade to an appropriate patched version and run compatibility checks without discarding reproducible dependency resolution.

Trace what reaches the deployed application

Source code, dependencies, build workflows and deployment credentials form one supply chain. A vulnerable package reference is not always proof that the vulnerable path is reachable, and a safe manifest does not guarantee that the deployed artifact contains the same versions. Record the package, resolved version, advisory and affected usage before choosing a fix.

1. Compare manifests, lockfiles and the deployed build where available.
2. Review workflow token permissions and how untrusted pull-request code is handled.
3. Separate an exposed credential from a public identifier; rotate confirmed leaked secrets.

Upgrade and verify with controlled changes

Avoid blind major-version upgrades or simply deleting a lockfile. Review compatibility and release notes, rebuild with resolved versions, and run relevant regression checks. Credential rotation must revoke the old secret as well as update the application.

1. Prepare the dependency or workflow change in a reviewable branch.
2. Run the existing tests and build pipeline under appropriately scoped permissions.
3. Verify the vulnerable version or behavior no longer appears in the deployed artifact.

References

OWASP A06