Dependency security
Know the package, the version and the reason it matters.
A dependency finding starts with a trustworthy inventory. Code Security reads supported lockfiles and manifests, identifies exact versions where available, and matches them against its advisory data. It brings package identity, vulnerability context and uncertainty into the same review so your team can choose an upgrade with a clear reason.
- 01
Manifest / lockfile
Identify the package and ecosystem.
- 02
Exact version or unresolved input
Keep the distinction visible before matching.
- 03
Advisory and affected range
Read available severity, EPSS and KEV context.
- 04
Application decision
Validate applicability and a suitable change.
01 / Dependency security
Start with the version your build actually resolves
Supported inventories cover npm, yarn, pnpm and Bun; Python; Go; Maven and Gradle; NuGet; Cargo; Composer; RubyGems; and Swift Package Manager. Where a recognised lockfile and manifest sit together, the more exact source takes precedence according to the ecosystem's parser.
Version ranges, variables that cannot be resolved and inherited versions unavailable in the repository are retained as unresolved. Direct and transitive relationships are reported where the source format supports them. This lets a reviewer distinguish a concrete vulnerable version from missing dependency evidence that needs a build-system check.
02 / Dependency security
Add vulnerability intelligence without confusing it with exploitability
Advisory matching uses the platform's vulnerability database, with NVD records, OSV package ranges and available EPSS and known-exploited context. The CLI can fetch and cache that database or use an approved local bundle. A team operating offline needs to track the age and provenance of the bundle it imported.
A matching version identifies a candidate exposure. Applicability can still depend on how the package is built, configured and used. An absent EPSS value is missing information, and a vulnerability match alone does not prove a vulnerable function is reachable in your service.
03 / Dependency security
Review package trust as a separate question
The audit workflow can flag names resembling well-known packages and match a supplied known-malicious package list. Those signals complement advisory matches: a newly suspicious package may have no published CVE, while a legitimate package can contain a known vulnerability.
Name similarity is a review signal and can produce false positives. The scanner does not execute downloaded packages to establish their behaviour. Verify ownership, expected dependency intent and the proposed replacement before changing a build.
Reviewable output
The information behind the next decision.
Review known vulnerabilities, malicious-package indicators and unresolved dependency versions from the repository's own manifests and lockfiles.
| Question | Product evidence | Engineering decision |
|---|---|---|
| Which version is present? | Recognised lockfile or manifest identity | Resolve floating or inherited versions before relying on a match |
| Why is it flagged? | Advisory identifiers and affected ranges | Check applicability, vendor guidance and a suitable upgrade |
| Is it urgent? | Severity and available EPSS / KEV context | Add service exposure and deployment context |
| Is the package unexpected? | Package-name heuristics and configured malicious-list matches | Verify the dependency's purpose and provenance |
Put it to work
Start with one representative repository.
Inventory the repository
Scan the manifests and lockfiles used by your build. Resolve missing versions and inspect which dependency relationships were recovered.
Prioritise the change
Combine advisory evidence with the affected application and an engineer's assessment of actual use. Decide whether to upgrade, replace or record a reviewed disposition.
Verify the resulting build
Update the lockfile, run tests and rescan. Preserve the new inventory and the reason behind remaining exceptions.
magdox deps .
magdox audit .
magdox vulndb status
magdox scan --full .deps reviews known vulnerabilities. audit adds package-name and configured malicious-list checks. scan --full does not silently include every separate command. Advisory freshness follows the selected database snapshot.
Before you start
Scope and practical questions.
Does an SBOM establish complete build contents?
A repository-derived inventory describes recognised source dependencies. It does not automatically include vendored binaries, dynamically downloaded components or every package in a deployed image.
Can dependency review run offline?
Yes, with provisioned licensed components and an approved local advisory bundle. Offline results reflect that bundle's age; exporting a file does not create fresh vulnerability intelligence.
Explore Code Security
Source-code analysis
Local SAST with affected locations, supported flow evidence, severity, confidence and explicit analysis coverage.
Secrets & configuration
Review source, infrastructure definitions and delivery configuration locally, with redacted secret findings and file-level context.
Software, crypto & AI inventory
Build software, cryptographic and AI inventories locally, then find recognised components across the repositories you choose to upload.
Code Security · next step
Evaluate the workflow on your own code.
Use a repository your team understands, review the findings with its engineers and decide how the result fits your delivery process.
14-day self-service trial. Card required; cancel before the trial ends to avoid the first charge.