Dispatch
Cloud- A single issue in the repository’s configured issue tracker. This issue is the main dashboard for the workflow and stays up to date as scans run.
- The repository’s Security section in the Upsun Dispatch console, which shows the latest scan result for that repository.
Before you scan
Connect the relevant VCS integration before running a scan:- Set up GitHub for GitHub repositories.
- Set up GitLab for GitLab repositories.
- Browse projects
- Create issues
- Edit issues
- Transition issues
Run an on-demand scan
Start CVE scan from the repository workflow page in the Upsun Dispatch console:- Open Repositories.
- Select the GitHub repository or GitLab project that you want to scan.
- Open Repository > Workflows > CVE scan.
- Select Run scan now.
Turn on daily scans for one repository
An organization owner or admin can enable a daily CVE scan for each repository that needs scheduled scanning. From the repository page:- Open Repositories.
- Select the GitHub repository or GitLab project that you want to scan daily.
- Open Repository > Workflows > CVE scan.
- Turn on Daily scan.
Track scan results in one issue
CVE scan creates or updates one issue for each repository in the repository’s configured tracker. This issue acts as a dashboard for vulnerable dependencies and is updated in place. Each scan rewrites the same issue with the current vulnerable dependencies. Upsun Dispatch does not open a new issue on each scan. If you change the repository’s tracker, the next scan opens a new issue in the newly configured tracker. Use the issue when you want to plan or track remediation work with the rest of your repository work.Review the latest scan in Security
Open the repository’s Security section in the Upsun Dispatch console to review the latest scan result. The Security section can show:- Filters by severity and location.
- Search by package or advisory.
- Locations marked Partly audited or Not audited when Upsun Dispatch cannot fully audit a location.
- Go advisories whose vulnerable functions your code does not call.
- Accepted advisories from repository scan configuration, including rules that have expired or that expire in the next 7 days.
- A link to the tracker issue that CVE scan creates and maintains.
Accept an advisory
Some advisories come back on every scan after your team has already decided about them, for example an advisory with no fixed version in code that your repository never calls. Record that decision in anosv-scanner.toml file. The CVE scan then lists the advisory as accepted, with its rule, and not as a finding.
osv-scanner.toml is the configuration file of osv-scanner. The scan applies it as osv-scanner does: an advisory that osv-scanner ignores is accepted. For every field of the file, see the osv-scanner configuration docs.
Where to put the file
Putosv-scanner.toml in the directory of each project, next to its lockfile (package-lock.json, uv.lock, go.mod, composer.lock, and so on). The file applies to that directory only:
- A file at the repository root covers only the project at the root.
- The scan does not look in parent directories or sub-directories. A project in
web/needs its ownweb/osv-scanner.toml. - Projects in the same directory share one file.
- A workspace member that the scan reads through its parent’s lockfile uses the file in the parent’s directory.
- The scan does not follow a symlinked
osv-scanner.toml, and reports it as invalid.
Accept one advisory
Add an[[IgnoredVulns]] entry for each advisory:
app/osv-scanner.toml
idis the advisory ID. An advisory often has several IDs (CVE, GHSA, GO), and the scan accepts it only when osv-scanner drops every record of it. If the advisory stays a finding after the next scan, add an entry for each of its IDs.ignoreUntilis the end date of the rule. Write it with no quotes.reasonrecords why your team accepts the advisory. The report shows it next to the advisory.
ignoreUntil and reason are optional, but the report adds a warning when one is missing. Without ignoreUntil, the rule never ends.
Give each advisory one entry. osv-scanner reads only the first entry for an ID, even when that entry has expired.
Accept all advisories of a package
Add a[[PackageOverrides]] entry to accept the advisories of a whole package:
app/osv-scanner.toml
vulnerability.ignore = trueaccepts every advisory of the matching packages.ignore = trueremoves the matching packages from the scan.effectiveUntilis the end date, with the same rules asignoreUntil.
osv-scanner.toml.”, with no reason and no end date. A package rule with no name matches every package that its other fields allow. With no other field, it accepts every advisory in that directory.
Do not quote the date
When a file is invalid, the scan accepts nothing from it. It keeps every finding, lists the file under Invalidosv-scanner.toml with osv-scanner’s message, and brings back the advisories that the file accepted before. A TOML syntax error or an unknown key has the same effect. Fix the file, and the next scan applies it again.
When a rule ends
The scan compares the end date with the time it runs:- A date with no time, such as
2027-01-01, ends at midnight at the start of that day, in the scan’s local time. - A date-time with no offset, such as
2027-01-01T12:00:00, is also in the scan’s local time. - A date-time with an offset, such as
2027-01-01T00:00:00Z, is an exact moment.
What the scan shows
The tracker issue and the repository’s Security section show the same information:
Accepted advisories are in no count and do not send a console notification. When a scan has no finding but has accepted advisories, the headline gives their number. An advisory that comes back after its rule ends or after its file becomes invalid counts as a new finding, and sends a console notification when it is critical or high.
When a tracker issue is too long for the tracker, the scan removes the accepted advisories first, then the rules that end soon, then the expired rules. A notice says what is missing and links to the full report in the Security section.