Linear Integration

Why It Matters

The people who triage a vulnerability report are almost never the people who fix it. Triage happens in Kit; the fix happens on an engineering board. Without a link between the two, someone copy-pastes the report into Linear by hand — and from that moment the two systems drift. The issue sits in “In Review” while the report says “Validated”, nobody can answer “is this actually fixed?”, and the researcher waits.

Connecting Linear closes that loop. One click on a report creates the issue, and the link between them is a real record Kit maintains — not a URL somebody pasted into a comment.

It also solves the quieter problem: hand-copying tends to paste everything, including the reproduction steps and the researcher’s email, into a workspace whose real audience nobody has audited. Kit’s integration pushes a deliberate stub instead.

What You Need

• Kit account with the VDP Add-on enabled
• A Linear workspace
• A Linear workspace admin to run the connect step — see below
• Module-admin rights in Kit — connecting a tracker is an organization-level decision

Setup

1. Connect your Linear workspace

1. Go to VDP > Settings > Issue tracker
2. Choose Linear from the provider picker
3. Click Connect Linear
4. Sign in to Linear and approve the requested access

Kit asks for read access plus permission to create issues and comments — nothing else. A Linear token is scoped to a single workspace, so one connection means one workspace.

The grant belongs to the person who authorized it. Kit records who that was, because when that person leaves the organization the connection stops working and you need to know whose access to renew.

2. Choose a team

1. On the settings page, click Choose team
2. Pick the team that should receive vulnerability work

Linear creates issues against a team, not a project — Linear’s own Projects span teams and are an optional grouping, so there is nothing to pick there. There is no issue-type step either: Linear has no issue types.

Kit maps report severities onto Linear’s four priorities:

Kit severity	Linear priority
Super critical	Urgent
Critical	Urgent
High	High
Medium	Medium
Low	Low
Informational	Low

Unlike Jira, these priority names are the same across the whole workspace, so there is no per-team mapping to check. If a severity has no mapping, Kit sends no priority at all and the team’s own default applies — it never sends Linear’s “No priority”, which would override that default rather than defer to it. The severity is always written into the issue description regardless.

To control the mapping yourself, set a priority_map override on the connection — there is no screen for it yet.

3. Confirm it works

Click Test connection. Kit makes an authenticated round trip to Linear and reports the result.

Pushing a Report

Open any report. In the right-hand column you will find an Issue tracker card.

1. Click Create issue
2. Read the panel showing what is sent and what stays in Kit
3. Click Create issue

The card shows a spinner while the issue is being created, then the issue identifier, its status, and a link that opens Linear in a new tab.

Any team member who can see the report can do this — it is routine triage, the same permission level as attaching a link. Configuring the connection is the admin-only part.

What Leaves Kit

This is the part worth reading carefully. By default a pushed issue is a stub: enough for an engineer to schedule the work, and no more.

Sent to Linear	Stays in Kit
Report title and its Kit reference	The vulnerability description
Severity and CVSS score	Reproduction steps
Vulnerability type	The affected endpoint
Affected product area	Proof-of-concept files and screenshots
Remediation due date	The researcher’s name, email and payout details
A link back to the report in Kit	Internal notes and the conversation thread

The reasoning is not caution for its own sake. Linear’s effective audience is unknowable from Kit: workspace-wide visibility, integrations holding read scope, exports, and backups that outlive the issue. The fields Kit withholds are the same ones it encrypts at rest, so pushing them would move your most protected data into your least controlled system.

Researcher identity and bounty amounts have no toggle at all. The absence of the option is the guarantee.

Sharing full details anyway

Some teams do want the description in the issue. That requires two independent gates:

1. An admin turns on Allow full vulnerability details in VDP > Settings > Issue tracker
2. The person pushing the report ticks the box for that specific issue

Both default to off. With the program-level setting off, the checkboxes do not even render — and a hand-crafted request cannot bypass them, because Kit re-checks the program setting when it builds the payload.

Linear issue descriptions are Markdown. When report text is included it is placed in a fenced code block, so Linear renders it exactly as the researcher wrote it instead of interpreting it as markup.

Status Comments

With Comment on status changes on, Kit posts a short comment in Linear when a report is validated, resolved, verified or dismissed, or when its severity changes. The comment is one sentence plus a link back to Kit.

That boundary is tighter than the issue body’s, deliberately: these comments fire automatically, with nobody reviewing the text, so there is no “include full details” escape hatch on this path at all. No description, no reproduction steps, no researcher identity, no bounty amounts.

Kit also asks Linear not to subscribe the app to the issues it comments on, so commenting does not pull Kit into your workspace’s notification traffic.

Remediation Status

The card shows the issue’s own status label as your workspace words it (“In Review”, “Ready for QA”), because that is what the engineer sees. Kit maps it internally to one of five states using Linear’s workflow-state types rather than state names — names are per-team free text, types are fixed:

Linear state type	Kit remediation status
Triage, Backlog, Unstarted	Not started
Started	In progress
Completed	Fixed
Canceled, Duplicate	Won’t fix

A duplicate counts as Won’t fix, not Fixed — it was closed without anything being remediated, and counting it as done would overstate your remediation rate.

Status is read on demand, when someone opens the report, and cached briefly so rendering a report never fans out API calls. There are no webhooks yet: Kit polls, Linear does not push.

Kit never resolves a report because Linear says Done. “Done” on an engineering board routinely means “merged, not deployed”, and resolving a report has consequences the person dragging a card cannot be assumed to intend: the researcher is notified, the bounty flow opens, and disclosure timers move. Kit surfaces the finished issue and leaves the decision with a human.

Unlinking and Retries

• Unlink removes the link in Kit only. The issue stays in Linear, where it may already carry an engineer’s comments and a fix branch — Kit is not the system of record over there.
• Retry re-runs a push that failed. It is safe to press twice: Kit generates the issue’s ID itself and sends the same one on every attempt, so a request that timed out after Linear had already created the issue adopts the existing one instead of making a second.
• Disconnecting the integration removes Kit’s copy of the grant and its tracking rows. Every issue you already created stays in Linear.

Troubleshooting

Symptom	Cause	Fix
“Only a Linear workspace admin can connect Kit”	The connect step was run by a regular member	Ask a workspace admin to run it
“Linear access was revoked”	The grant was revoked in Linear, or the authorizing user was deactivated	Reconnect from the settings page; a different admin can re-authorize
“Linear returned no workspace for this connection”	The authorization completed without granting workspace access	Connect again, signed in to the right workspace
“No teams found in this Linear workspace”	The connected account belongs to no visible team	Check that account’s team membership, then try again
No Create issue button appears	No tracker is connected, or the VDP Add-on is not active	Connect one under VDP > Settings > Issue tracker

Quick Checklist

• VDP Add-on active on the account
• Any existing Jira connection disconnected first — one tracker per program
• A Linear workspace admin available to run the connect step
• Workspace connected, and you know who authorized it
• Target team chosen
• Test connection passes
• Decided, deliberately, whether full vulnerability details may be shared