Issues
An Issue is one thing worth your attention, with everything you need to act on it in one place. SubImage produces a lot of raw signal: vulnerabilities, compliance findings, and attack paths. On their own, those are long lists. Issues are the layer on top: related signal is grouped, prioritized, and given a plain explanation of why it matters, so you work a short queue instead of triaging every row by hand.
Issues are built and maintained automatically. They appear after a sync, update as your environment changes, and close themselves when the underlying problem is gone. Your job is to read them, prioritize, route them where work happens, and snooze what you have decided to live with for now.
The Issues page
Open Issues to see your queue. By default it shows Open issues, sorted by priority.
- State tabs: switch between Open, Snoozed, and Closed.
- Search: filter by title.
- Owner: filter to issues assigned to a person.
- Sort: priority is the default; highest first.
Each row shows the priority score, the title, the owners, and whether the issue has action items (concrete fixes you can apply). Click a row to open it.
Priority
Every issue carries a priority score from 0 to 100. The score is not random and it is not CVSS. It is computed from the triage vector (below), so two issues with the same score got there for comparable reasons.
The score maps to a label:
| Score | Label |
|---|---|
| 90-100 | Critical |
| 70-89 | High |
| 50-69 | Medium |
| 0-49 | Low |
Work top-down. A critical issue is something exploitable, exposed, and broad; a low issue is real but not urgent.
The triage vector
The vector is how SubImage explains a priority. It is seven dimensions, each with a value and a one-line rationale. Open an issue and click the info icon on any dimension to read why that value was chosen.
| Dimension | What it answers | Values (low to high) |
|---|---|---|
| Exploitability | Can this actually be exploited? | none, theoretical, known, active |
| Exposure | How reachable is the affected resource? | unknown, internal, reachable, internet_exposed |
| Blast Radius | How far does the damage spread? | single_resource, service, platform, org |
| Business Criticality | How important is what is affected? | unknown, low, medium, high |
| Fixability | How hard is it to remediate? | unknown, hard, moderate, easy |
| Evidence Strength | How confident is the assessment? | weak, medium, strong |
| Environment | Where does the affected resource run? | unknown, non_prod, production |
The priority score is derived from these values, so the vector is both the explanation and the math behind the number.
Override the vector
If SubImage got a dimension wrong (for example, it marked exposure as internet_exposed but that path is actually firewalled), you can correct it. Edit the dimension on the issue, and the priority score recomputes immediately. An override is recorded on the timeline, and the issue is flagged as manually adjusted so a later sync does not silently overwrite your judgment.
Override Business Criticality first. It is the one dimension SubImage cannot infer well on its own, because it depends on what the service means to your business. Setting it on your crown-jewel services sharpens prioritization across the whole queue.
What is inside an issue
- Title, description, rationale: what the issue is and why it was raised.
- Signals: the evidence. Primary signals define the issue; if they all disappear, the issue closes on its own. Supporting signals add context (for example, an attack path that runs through the affected resource) but do not control its lifecycle.
- Action items: concrete remediation steps, when available, such as a package upgrade that fixes the vulnerabilities.
- Owners: the people responsible. Assign them from the issue.
- Timeline: an append-only history of everything that happened to the issue: created, reopened, snoozed, priority changed, vector overridden, routed, and any routing failures.
- Linked issues: related issues, so you can see a problem in its wider context.
How issues are built (triage)
Triage is the automatic step that turns raw signal into issues. It runs after a sync, once the underlying vulnerabilities, findings, and attack paths are up to date. In short:
- Related signal is grouped into a candidate issue (for example, all the vulnerabilities on one service image, or the findings from one rule). New findings either join an existing issue or start a new one, and a rule's findings can span more than one issue when they are genuinely separate pieces of work.
- Each candidate is assessed, assigned a triage vector, and either becomes a new issue, updates an existing one, or is set aside as low-value.
- When the signal behind an issue is fully resolved, the issue closes. If the same problem comes back shortly after, the original issue reopens rather than a duplicate being created.
You do not configure triage. It is the engine behind the queue. What you control is what happens to issues once they exist: prioritize, assign, snooze, and route.
Working with an issue
- Assign owners to make responsibility clear and to filter the queue by person.
- Snooze an issue to silence it for a while. Pick a date or leave it indefinite, and add a reason for the audit trail. Snoozed issues move to the Snoozed tab and come back when the snooze expires.
Related issues are linked for you: when triage finds a connection, it shows up under Linked issues so you can see a problem in its wider context.
Routing
Routing sends issues to where your team actually works: email, a Slack channel, a webhook, or a tracker like Linear or Jira. There are two ways issues get there.
Automatic routes
Set these up in Settings → Issue Routing. A route is a destination plus an optional filter. When an issue is created or updated and matches a route's filter, SubImage delivers it automatically, and records the result on the issue timeline. Routes are independent, so an issue is delivered to every enabled route it matches, not only the first. You can enable or disable any route from the table without deleting it.
To create one, click New route and choose a destination:
- Email: one or more recipients.
- Slack: a channel.
- Webhook: an HTTPS URL.
- Linear: a team. New issues are created there, priority is mapped from the SubImage priority, and closing the SubImage issue moves the Linear issue to Done.
- Jira: a project and issue type.
Slack, Linear, and Jira routes need that integration enabled and configured first under Settings → Integrations. Set up the integration, then point a route at it.
Filters: route only what matters
Without a filter, a route receives every issue. Add a filter so a destination gets only what it should. A filter is a set of conditions combined with all (every condition must match) or any (at least one).
You can filter on:
- Priority Score: with
=,≥, or≤and a number. - Primary Issue Type:
vulnerability,finding, orattack_path. - Any triage vector dimension: pick the allowed values (for example, Exposure is
internet_exposed).
A common setup: send only ≥ 70 (High and Critical) and internet_exposed issues to the on-call Slack channel, and route everything vulnerability-related to a Jira backlog.
Manual routing
On any issue, the Route issue button dispatches it to one of your configured routes on demand. Use this for an issue that does not match an automatic route but still needs a ticket, or to push something to a second destination.
When routing happens
Delivery is asynchronous, so creating issues never waits on Slack or Jira. Each attempt lands on the issue timeline: a successful delivery records the external reference (with a link to the Slack message, Linear issue, or Jira ticket), and failures are recorded too, with the reason, whether it was a configuration error, a rate limit, or a transient failure that will be retried.
Programmatic access
The same queue is available over MCP, so an agent can list and read issues alongside you. The relevant tools are subimageListIssues and subimageGetIssue. See Connect via MCP.