Vulnerability scanning
Vulnerability scanning checks each bill of materials against published vulnerabilities, and rechecks what is running as new ones appear. It lets you learn which releases a vulnerability touches before a customer tells you.
Why you would use it
Most vulnerabilities in your releases are published after you shipped them. A release that scanned clean on the day it went out can carry a critical finding a month later, while it still runs at a customer. Scanning once at build time misses that; scanning the release record keeps finding it.
Because every finding is tied to a release, an artifact, and a component, the answer is specific: not "this library is vulnerable" but "v1.5.3's API image carries it, it runs in these environments, and nobody has decided whether it matters yet."
When you don't need it
If your team already scans every running release continuously and records its decisions somewhere your support team can read, Logmarq's scanning repeats that work. You can still keep bills of materials and decisions in Logmarq and leave scanning off.
How it works in Logmarq
- Off until an administrator turns it on. Scanning uses Grype and downloads its vulnerability definitions, about 160 MB, 2 GB unpacked on the data volume, refreshed daily. Turning it on checks there is room, downloads them in the background, and scans every bill already stored.
- Every new bill is scanned. Findings are one per vulnerability and component, most severe first, with the versions that fix them. Each artifact counts its findings nobody has decided and those new since the previous release.
- Scheduled rescans. Once an interval you set, Logmarq scans again the bills of every release reported running in an environment and of the newest release of each maintained line. A finding the previous scan did not have is marked as found on rescan.
- Honest about its definitions. When newer definitions cannot be downloaded, scans carry on with the installed ones, and Logmarq says how old they are and why the update failed. An offline installation can load definitions by hand or from a mirror.
What it will not claim
- A scan is only as current as its definitions. Every scan says when it ran and on which definitions; old definitions are called out, not hidden.
- A finding is not a verdict. Scanners flag far more than is exploitable. Deciding what a finding means is a person's call, recorded as a VEX decision.
- Logmarq does not reimplement a scanner. It runs Grype and keeps its results with the release.
Get started
An administrator turns scanning on under Administration → Vulnerability scanning, and sets the rescan interval on the same page. From the server:
docker exec logmarq logmarq scanning on
docker exec logmarq logmarq scanning rescans 24
Related pages
Bills of materials · VEX: vulnerability decisions · Release lines