Everything vulnerable, and when it is due.

One list

There is nothing to set up. The inventory fills from the scanners already running in the workspace, and follows each one shortly after it scans. From the CLI:

tilldev shield vulns                                      # open and accepted, soonest due first
tilldev shield vulns --sla overdue --level critical       # or --sla due-soon, --source dependency, --owner me|none
tilldev shield vulns --exploited                          # CVEs on CISA's known-exploited list, highest EPSS first
tilldev shield vulns show <id>                            # the clock, owner, acceptance, fix pull request and exploit data
tilldev shield vulns owner <id> "Ada Lovelace"            # a name, a user id, or none
tilldev shield vulns accept <id> --reason "Only reachable from the VPN" --days 30
tilldev shield vulns unaccept <id>
tilldev shield vulns fix <id>                             # exits 1 when no lockfile could be changed
tilldev shield vulns stats --days 180
tilldev shield vulns settings set --critical 3 --high 14  # --no-alert-overdue turns the alert off

Where items come from

An item closes as gone when its asset is removed: the target, the app, the connector’s resource or the repository. An item that comes back after it closed opens again with a new clock, and the list counts how often that happened. A scan that couldn’t check something leaves its item as it was, rather than counting it fixed. Each source keeps up to 2,000 items per asset, worst first.

Days to fix

The clock starts when an item opens. It is due soon in the last quarter of its window, and never less than a day before. Change the days for any level, from 1 to 365, under the inventory’s settings; the due date of everything open moves with the change. An owner can be any member of the workspace.

Known exploited and likely to be

An item whose reference or one of its aliases is a CVE carries exploit data from two public sources. If the CVE is in CISA’s Known Exploited Vulnerabilities catalog, the item is marked exploited, with the date it was listed, the date US federal agencies must fix it by, and whether it is known to be used in ransomware. Its EPSS score from FIRST.org is the chance it is exploited in the next 30 days.

The Exploited count covers open and accepted items. Choosing it filters to them and sorts known-exploited items first, then by EPSS score. Exploit data never changes an item’s level or fix-by date. Where the data comes from and how fresh it is: Threat intel.

Accepting a risk

An accepted item stops its clock and leaves the open count. TillDrill and app scan items have no exception of their own, so they are accepted here: with a reason of 10 to 500 characters, for up to 366 days (90 unless set). When it ends, the item is open again. Every other source is accepted where it was found, so the merge gate, the push check or Posture agree with the list; the item says where, and shows who accepted it and why.

Fix pull requests

On a dependency advisory in a TillForge repository, Open a fix pull request reads every lockfile at the tip of the default branch. It works out the smallest version that fixes every advisory on the package, edits each lockfile it can, and opens a pull request on its own branch with the advisories, the files changed, and any it left alone. The dependency check runs on the pull request and scans the change again. Only the official registries are read: the npm registry, PyPI, the Go module proxy and checksum database, and the crates.io index.

A lockfile is left alone when the upgrade would need more than the one package to move: a range a dependent or a manifest pins that the fix falls outside, an override, a patch, a peer, an alias, or a new version whose own dependencies differ. The pull request, and the CLI, give the command to run instead. bun, Gradle and NuGet lockfiles always get the command. While the pull request is open, asking again returns the same one; once it closes, the next request opens a new one.

Overdue alert

When items fall overdue, the workspace’s security alerts hear about them once: email, Slack or the signed webhook set under Playbooks & security alerts. One message names up to 50 items, worst first, and the total. An item that reopens, or whose due date moves later, can alert again. Turn the alert off in the inventory’s settings. The webhook body:

{
  "type": "tillshield.vulns.overdue",
  "delivery_id": "1d0e9f6a-…",
  "overdue": [
    {
      "id": "8c1f…",
      "title": "lodash: prototype pollution",
      "level": "high",
      "source": "dependency",
      "asset": "web",
      "due_at": "2026-10-05T09:12:00.000Z"
    }
  ],
  "total": 1,
  "checked_at": "2026-10-05T09:14:03.000Z",
  "link": "https://tilldev.dev/acme/shield/vulns?status=open&sla=overdue"
}

Time to fix

Over a window of 7 to 365 days, 90 unless set: mean days from opening to fixed, overall, by level and by source; the share fixed by their due date; and how many opened and how many were fixed each week.

Limits

The list reads the latest scan of each repository’s default branch, not other branches. Every change is in the audit log. The API is under /api/v1/shield/vulns in the API reference.