Jira labels

The complete catalog of labels WASViking writes on Jira issues, the rules the sync follows, and a playbook for organizing boards, automation and reporting by team.

Every issue the Jira integration creates carries a small set of labels that say where the finding came from, what kind of weakness it is and which repository or application it belongs to. The labels exist so that a team can pick up its own work from a board filter, an automation rule or a dashboard without opening the card.

This page is the reference for those labels: the full catalog, the rules the sync follows, and the patterns teams use to organize security work around them.

The grammar

All labels follow one shape:

wasviking
wasviking-<facet>-<value>

• wasviking is on every issue the integration creates.
• <facet> is one of area, category, repo, app or platform.
• <value> is lowercase and hyphenated. It never contains a space, because Jira refuses a label with a space in it.

The namespace is deliberate. Your own labels, such as sprint-42, needs-review or team-payments, never collide with these, and a JQL query can tell the two apart at a glance.

Catalog

The root label

Area labels

The area is the part of the platform that found the weakness, which in most organizations is also the team that fixes it. There are six.

An issue carries exactly one area label. When a finding could belong to two, its origin decides: a vulnerable component found inside a mobile app is wasviking-area-mobile, not wasviking-area-supply-chain, and a secret found in a repository is wasviking-area-code while the same secret observed in an HTTP response is wasviking-area-web.

Category labels

The category is the finding category as WASViking^® reports it in the portal, the API and the CSV export, written with hyphens. There are eighteen.

A category the engine gains later appears as wasviking-category-<value> on its own, so a filter written on the root or area labels keeps working.

Repository label

The repository name is the one the pipeline reported, which is the --app-name given to the Sentinel CLI or the name of the scanned folder. It is folded to the label character set: lowercase, everything outside letters, digits, dots, underscores and hyphens becomes one hyphen, accents are removed, so serviço/api reads wasviking-repo-servico-api. Findings from scans of running applications carry no repository label, because they have no repository.

Application and platform labels

Mobile findings carry these two instead of a repository label.

What one issue looks like

The rules the sync follows

• Your labels are never touched. The sync adds and refreshes its own labels through label operations, never by rewriting the field, so every label your team adds survives every update.
• Only the grammar above is managed. The sync removes a label only when it has the shape wasviking-<facet>-<value> and no longer applies, for example the old repository label after a repository was renamed in the pipeline. A label of yours that merely starts with the name, such as wasviking-reviewed, is not in the grammar and is left alone.
• wasviking is never removed. If someone deletes it from a card, it is back on the next update.
• Labels are refreshed on every push. A push happens when the finding changes, when a scan sees it again, on a manual Push to Jira and on a backfill with Force resync. Issues created before labels existed receive theirs on their next push.
• Labels are a mirror, not a control. Removing an area label in Jira does not change the finding; the label comes back. To route work differently, add your own label or an automation rule rather than editing these.
• The labels field has to be on the screen. If the issue type's create or edit screen does not include Labels, the issue is created without labels and everything else still syncs. Add the field to both screens and run a backfill with Force resync.

Organizing the work by team

The labels are the raw material. What follows is how organizations with several engineering teams usually put them to work.

Start with an ownership matrix

Decide once who owns each area and write it down where the teams can see it. A minimal matrix has three columns: the area label, the owning team, and the escalation contact for anything rated Highest. Repositories refine it: a wasviking-repo- label maps to the team in your service catalog, and mobile platforms map to the Android and iOS teams.

One board per team, driven by a quick filter

Each team's board keeps its own filter, so the team sees security work next to its feature work instead of on a separate security board nobody visits.

One security board with a swimlane per area

For the security team, a single board with swimlanes based on JQL gives the whole picture. One swimlane per area label, ordered by priority, shows at a glance which team is behind.

Route automatically with Jira Automation

Automation rules turn a label into an owner the moment the issue is created, so nobody has to triage by hand.

Keep the ownership in your own field, Team or Component, and let the labels feed it. Renaming or deleting a WASViking label to change ownership does not work, because the sync puts it back.

Dashboards and reporting

Saved filters on the labels give the weekly review its numbers without anyone assembling a spreadsheet.

A two dimensional filter statistics gadget with labels on one axis and status on the other is the single most useful view: every area, every state, one table.

Keep the two namespaces apart

Use your own labels freely for anything the sync does not express: sprint, ownership, review state, customer impact. Leave the wasviking- labels to the sync. If a value does not fit your naming convention, map it with an automation rule to a label or field of your own instead of editing the label on the card.

JQL reference

Labels are matched exactly and are case sensitive in JQL, so type them as they appear here, in lowercase.