Findings and triage

Dependency scanning checks the packages your repositories depend on against known vulnerabilities and lists every match on the Issues tab of the Dependency scanning page. Use it to see which vulnerable packages you have and where, decide what to fix first, and keep a record of each finding you fix or set aside.

Members, Admins, and Auditors can view issues and their findings. Only Admins can resolve findings, assign owners, start a scan, or turn on AI scanning.

Issues and findings

Each issue on the Issues tab is one vulnerability, identified by its advisory ID, in one package. It’s made up of findings, one for each place the vulnerability occurs: a specific repository, manifest file, and package version. An issue can have many findings, and each one is fixed and resolved on its own.

Every 6 hours, Oneleet scans the target branch of each repository that has Automatic scanning turned on in Code Security. The scan reads the packages declared in the repository’s manifest files and creates a finding for each package version with a known vulnerability. Pushing to the target branch doesn’t start a scan. Pull request checks don’t either, and they never create, resolve, or reopen findings.

Risk and severity

Each issue carries two ratings. CVSS severity is the vulnerability’s public base score, and shows Unknown when no score is published. Risk combines the CVSS score with the vulnerability’s EPSS score, which estimates how likely it is to be exploited in the wild within the next 30 days. When AI scanning is on, its verdicts adjust risk too (see Check exploitability with AI scanning). Risk is set per issue, so every finding of an issue shares its risk level.

Because risk also weighs how likely a vulnerability is to be exploited, an issue’s risk level can differ from its CVSS severity. That likelihood appears as the issue’s EPSS score, or as a CISA KEV tag in its place when the vulnerability is in CISA’s Known Exploited Vulnerabilities (KEV) catalog. Monitor SLAs follow the risk level, not the CVSS severity, and the issue list sorts by risk, highest first, by default.

Review issues

The Issues tab lists issues with open findings. Expand an issue to see its findings, or click its title to open the issue page, which shows the advisory description, affected and patched versions, and references. The issue list doesn’t show a fixed version, and the issue page shows Patched versions only for vulnerabilities with a GitHub advisory.

The Issue status filter starts with Open and In progress selected. An issue is In progress once some of its findings are resolved, and it leaves the default view when all of them are. Select Resolved to see those issues again.

To assign an owner, hover over a finding and click the person icon. Owners are set per finding, and you can filter the list by owner. With the owner filter or the Repository filter on, each issue shows only the findings that match.

If your workspace has the Linear integration, click Create Linear issue on the issue page to open Linear’s new-issue form, filled in with the issue’s details. The button appears while the issue still has unresolved findings.

Fix a vulnerable dependency

To fix a finding, update or remove the package and merge the change, lockfile changes included, into the repository’s target branch. The finding resolves automatically once the next scan of that branch completes. Opening a pull request alone doesn’t change anything on the platform. To check whether a pull request fixes the vulnerability before you merge it, use pull request checks.

A scan resolves a finding as Dependency updated when it no longer matches the vulnerability, and as Dependency removed when the package is gone from that manifest file. The resolved row shows when the scan detected the change. A finding that a scan resolved automatically reopens if a later scan finds the vulnerable version again.

If a scan fails, the previous dependency list and findings stay as they were until a later scan succeeds. To see why a scan failed, click New scan on the Dependency scanning page, then hover over the red icon next to the repository.

If the version you update to is still affected by the same advisory, the scan resolves the old finding and opens a new one for the new version. Because it counts as a new finding, it can send a notification and get its own exploitability assessment from AI scanning. A Not exploitable or Risk accepted resolution on the old version doesn’t carry over, so resolve the new finding too.

Scan without waiting

To pick up a merged fix before the next scheduled scan:

1. On the Dependency scanning page, click New scan.
2. Select the repositories to scan, or click Select all.
3. Click Start scan.

Repositories with Automatic scanning turned off can be scanned this way too, but a repository that’s already being scanned can’t be selected. Scans time out after 30 minutes.

Resolve a finding without a fix

When a finding doesn’t need a fix, or can’t get one yet, resolve it by hand and choose the resolution that describes why.

1. On the Issues tab, expand the issue.
2. Hover over the finding and click the dashed-circle button (Resolve finding).
3. Under Resolve as, choose Not exploitable, Dependency updated, Dependency removed, Risk mitigated, or Risk accepted.

Each finding is resolved separately, so an issue with several findings needs each one resolved, and any finding left open keeps the monitor alerting.

Scans never reopen a finding you resolved by hand, even if the vulnerable version is still there. The resolution is recorded with your name and the time, and your auditor can ask why you chose it, so only resolve a finding you can justify.

To change or undo a resolution, click the resolution label on the resolved finding and choose Unresolve finding, or pick a different option under Change resolution. An unresolved finding is open again, and a later scan resolves it automatically if the vulnerable version is gone.

Check exploitability with AI scanning

AI scanning has an AI agent examine your code to judge whether a finding is actually exploitable in your repository, and to suggest how to fix it. It sends your source code, dependency manifests, and vulnerability details to third-party AI model providers (Anthropic and OpenAI).

AI scanning is off by default. To turn it on:

1. On the Dependency scanning page, click Configure and open the Scanner settings tab.
2. Under AI scanning, click the switch.
3. Click Allow for organization.

Allowing it also turns on AI features for your organization. The switch is unavailable while AI features are turned off for your organization under Settings > AI features.

AI scanning gives an exploitability assessment to findings whose issue has Medium risk or higher and whose vulnerability has a GitHub advisory. It assesses new and reopened findings after each scan, and picks up other open findings that haven’t been assessed, including ones from before you turned AI scanning on, within a day. A finding is assessed again once its latest assessment is a week old. You can’t start an assessment by hand.

Each finding shows the verdict of its latest assessment: likely exploitable, likely not exploitable, or not determined. Unless the verdict is not exploitable, the assessment also lists remediation recommendations, and up to two of them may be marked Recommended. To have a coding agent make the fix, click Copy prompt and give it the copied instructions.

A verdict adjusts the risk that its finding contributes to the issue. An exploitable verdict raises it, and a not exploitable verdict lowers it. The issue takes the highest risk across its findings, so one exploitable finding raises the whole issue, and a not exploitable verdict lowers the issue only when every one of its findings has that verdict.

To act on a verdict, click Resolve as not exploitable on a finding with a not exploitable verdict, or Resolve as risk mitigated or Resolve as risk accepted on a matching recommendation. These record a manual resolution like any other.

Get notified about new findings

The Dependency vulnerability findings notification goes out by email and Slack only for the findings most likely to matter: those in the CISA KEV catalog or at Critical risk, before any AI scanning adjustment. Other new findings don’t send a notification. They appear only in your digest’s counts of open findings per risk level, once you turn on the digest’s Dependency Scanning section. Each finding notifies once, and again only if a scan resolved it automatically and later found it again.

We combine these emails per workspace. After a new finding, we wait until 15 minutes pass without another one, up to 30 minutes in total, then send a single email. It lists up to 10 top findings, with the fixed version when one exists, and links to the Issues tab filtered to the repository.

Admins and Members get the notification if their preference for it is on. In Slack, it also posts to your workspace’s channel, regardless of any member’s preference. Change yours under Settings > My account > Personal notifications, or set the defaults for each role under Settings > Workspace notifications.

Findings monitor

The Dependency scanning findings are resolved monitor treats each finding as an asset and alerts while any finding is open, whatever its risk level. Each finding’s SLA follows its issue’s risk level. Resolving a finding, by hand or through a scan, clears its alert on the monitor’s next scheduled run. You can’t rerun this monitor by hand to clear it sooner.

Stop tracking a repository

To stop tracking a repository, remove it from Code Security. Dependency scanning uses Code Security’s repositories, so this stops scans of the repository. Its findings then drop out of the issue list, the digest, and the monitor, although they’re hidden rather than resolved.

Turning off Automatic scanning isn’t enough. It stops the repository’s scheduled dependency scans and its dependency pull request checks, but its existing findings stay open and keep alerting, and the repository starts failing the Git repositories have dependency scanning enabled and Git repositories have code security scanning enabled monitors. Archiving a repository on your Git provider doesn’t clear its findings either.

What this means for your audit

Open findings don’t have to be resolved right away, as long as they’re inside their SLA window. Fix Medium-risk findings and above within their SLA. Low and informational findings have no SLA by default, so review and document them, and fix them on a slower cadence, such as quarterly.

Limits

Setting findings aside can take more work than you’d like. Dependency scanning has no way to exclude paths, and .oneleetignore files don’t apply to it. There’s also no rule to ignore a vulnerability everywhere, and Code Security’s ignore rules don’t cover dependency findings. To set aside findings in manifests you don’t ship, or a vulnerability that doesn’t affect you, resolve them by hand, one finding at a time.

Dependency scanning won’t report vulnerabilities in your own packages that don’t come from a public registry, such as Cargo workspace or path crates, because they aren’t matched against public advisories. You also can’t export findings from the app.

If any of these limits get in your way, tell us through the Feedback link at the bottom of the app’s sidebar or in your dedicated Slack channel with us.