Skip to main content
Most dependency scanning tells you what was vulnerable the last time you scanned. A vulnerability disclosed an hour ago does not wait for your next scan, and a CVSS number alone does not tell you whether it can hurt you. The CVE Disclosure page answers both. Findings tell you what to fix; this page proves what was checked.

​
The inventory

Amnify keeps a resolved dependency inventory per repository: the ecosystem, package and installed version, whether you depend on it directly or through another package, and whether only development tooling pulls it in. Whether a dependency is direct or development only comes from your lock files, when they record it, or from the manifest that declares it. Amnify reads the inventory from the manifest and lock files in your repository’s default branch, and the actions your GitHub Actions workflows use, so there is nothing to turn on in GitHub or GitLab. For GitLab tiers and CI, see Dependencies and CVE monitoring. Where a manifest has no lock file beside it, the version range it asks for is checked, and an action referenced by a major tag such as v4 is checked across that whole release line. It is read again on every push to your default branch, at least once a day, and on demand with Check dependencies now in Scan automation. A refresh you start runs in the background, and its results appear on the CVE Disclosure page within a minute or two.

​
Supported ecosystems and files

These files are read wherever they sit in the repository. For JavaScript, Rust, Ruby, PHP, Gradle and Python other than requirements files, a manifest is read for its declared versions only where no lock file of its ecosystem sits in the same directory or a parent: the lock file records exactly what is installed, so it wins. Software bills of materials committed to the repository are read too: SPDX (*.spdx, and *.spdx.json or any other .spdx. format) and CycloneDX (*.cdx.json, *.cdx.xml, bom.json, bom.xml). In Gradle build files, a dependency is read where its version is written out; one built from a variable or a dynamic version such as 1.+ is not. An ecosystem with only a lock file listed is read from that lock file, so commit it. If Amnify cannot read a repository, for example because its access to it was removed, the CVE Disclosure page says why. Until a read succeeds, the hourly check goes on matching the last inventory it read. A temporary problem is retried by itself; anything else is tried again with the daily read, or as soon as you ask.

​
Hourly monitoring

Monitoring is off for a newly connected repository. Turn it on per repository in Scan automation. Once it is on, the inventory is checked hourly against public advisories. Every CVE that matches a version you actually run is recorded the moment it appears, whether or not it is analyzed. Turning monitoring off stops new checks, not the record. The repository stays on the CVE Disclosure page marked Not monitored, with its dependencies, verdicts and history. Analyze now needs monitoring on, and CVEs waiting for analysis show as paused until it is back on. Turn it back on and they are analyzed at the next check, which continues the same history.
Hourly monitoring is free. Analysis is one agent run per CVE, and only for the CVEs your analysis threshold covers.

​
Verdicts

A vulnerability in a package you depend on is not automatically a vulnerability in your application. An agent traces whether the affected code can reach your running app, and every matched CVE carries one of these verdicts. A CVE that cannot affect you today stays on the record with its reason, so the day someone starts calling that function there is a trail. If a finding had already been opened for it, it is resolved with that reason. A finding whose vulnerable version leaves your dependencies is resolved too, without anyone asking, once a read of your repository shows it gone.

​
The page

Pick a repository at the top. The strip shows its dependency count, how many dependencies are affected, and the analysis threshold in force. Below it, two tabs:
  • Dependencies. One row per dependency with at least one matched CVE, most urgent first. Expand a row to see each CVE with its CVSS score, verdict, disclosure and detection dates, how long its finding has been open against your response target, and the upgrade that resolves it. Search by package or CVE, and filter by verdict.
  • History. Every CVE that ever matched the repository, newest first, and what came of it: how long the analysis took, the verdict, and the finding it opened. A match stays here after its dependency is upgraded away.

​
Monitoring settings

The gear in the page header opens settings that apply to every repository in the organization.

​
In a penetration test

A white box penetration test independently confirms that a vulnerable version is actually present before reporting it. See How a pentest runs.