Labels do Jira

O catálogo completo das labels que a WASViking grava nas issues do Jira, as regras que a sincronização segue e um playbook para organizar boards, automação e relatórios por equipe.

Toda issue criada pela integração com o Jira carrega um pequeno conjunto de labels que dizem de onde o achado veio, que tipo de fraqueza ele é e a qual repositório ou aplicação ele pertence. As labels existem para que uma equipe consiga pegar o seu próprio trabalho a partir de um filtro de board, de uma regra de automação ou de um dashboard, sem abrir o card.

Esta página é a referência dessas labels: o catálogo completo, as regras que a sincronização segue e os padrões que as equipes usam para organizar o trabalho de segurança em torno delas.

A gramática

Todas as labels seguem um único formato:

wasviking
wasviking-<facet>-<value>

• wasviking está em toda issue que a integração cria.
• <facet> é um entre area, category, repo, app ou platform.
• <value> é escrito em minúsculas e com hifens. Nunca contém espaço, porque o Jira recusa uma label que tenha espaço.

O namespace é proposital. As suas próprias labels, como sprint-42, needs-review ou team-payments, nunca colidem com estas, e uma consulta JQL consegue distinguir as duas de relance.

Catálogo

A label raiz

Labels de área

A área é a parte da plataforma que encontrou a fraqueza, que na maioria das organizações também é a equipe que a corrige. São seis.

Uma issue carrega exatamente uma label de área. Quando um achado poderia pertencer a duas, a origem dele decide: um componente vulnerável encontrado dentro de um app móvel é wasviking-area-mobile, não wasviking-area-supply-chain, e um secret encontrado em um repositório é wasviking-area-code, enquanto o mesmo secret observado em uma resposta HTTP é wasviking-area-web.

Labels de categoria

A categoria é a categoria do achado como a WASViking^® a reporta no portal, na API e na exportação CSV, escrita com hifens. São dezoito.

Uma categoria que o motor venha a ganhar depois aparece como wasviking-category-<value> por conta própria, de modo que um filtro escrito sobre a label raiz ou sobre as labels de área continua funcionando.

Label de repositório

O nome do repositório é o que o pipeline reportou, ou seja, o --app-name passado à CLI do Sentinel ou o nome da pasta analisada. Ele é reduzido ao conjunto de caracteres de label: minúsculas, tudo o que não for letra, dígito, ponto, underscore ou hífen vira um único hífen, os acentos são removidos, então serviço/api vira wasviking-repo-servico-api. Achados de scans de aplicações em execução não carregam label de repositório, porque não têm repositório.

Labels de aplicação e de plataforma

Os achados mobile carregam essas duas no lugar de uma label de repositório.

Como fica uma issue

As regras que a sincronização segue

• As suas labels nunca são tocadas. A sincronização adiciona e atualiza as próprias labels por meio de operações de label, nunca reescrevendo o campo, então toda label que a sua equipe adiciona sobrevive a toda atualização.
• Só a gramática acima é gerenciada. A sincronização remove uma label apenas quando ela tem o formato wasviking-<facet>-<value> e deixou de se aplicar, por exemplo a label de repositório antiga depois que um repositório foi renomeado no pipeline. Uma label sua que apenas começa com o nome, como wasviking-reviewed, não está na gramática e é deixada em paz.
• wasviking nunca é removida. Se alguém a apagar de um card, ela volta na próxima atualização.
• As labels são atualizadas a cada push. Um push acontece quando o achado muda, quando um scan o vê de novo, em um Push to Jira manual e em um backfill com Force resync. As issues criadas antes de as labels existirem recebem as suas no próximo push.
• As labels são um espelho, não um controle. Remover uma label de área no Jira não muda o achado; a label volta. Para direcionar o trabalho de outra forma, adicione a sua própria label ou uma regra de automação em vez de editar estas.
• O campo de labels precisa estar na tela. Se a tela de criação ou de edição do tipo de issue não incluir Labels, a issue é criada sem labels e todo o resto continua sincronizando. Adicione o campo às duas telas e execute um backfill com Force resync.

Organizando o trabalho por equipe

As labels são a matéria-prima. O que vem a seguir é como organizações com várias equipes de engenharia costumam colocá-las para trabalhar.

Comece com uma matriz de responsabilidade

Decida de uma vez quem é responsável por cada área e registre isso onde as equipes possam ver. Uma matriz mínima tem três colunas: a label de área, a equipe responsável e o contato de escalonamento para tudo o que for classificado como Highest. Os repositórios refinam a matriz: uma label wasviking-repo- aponta para a equipe no seu catálogo de serviços, e as plataformas mobile apontam para as equipes de Android e de iOS.

Um board por equipe, guiado por um filtro rápido

O board de cada equipe mantém o seu próprio filtro, então a equipe vê o trabalho de segurança ao lado do trabalho de funcionalidades, e não em um board de segurança separado que ninguém visita.

Um board de segurança com uma swimlane por área

Para a equipe de segurança, um único board com swimlanes baseadas em JQL dá a visão completa. Uma swimlane por label de área, ordenada por prioridade, mostra de relance qual equipe está atrasada.

Direcione automaticamente com o Jira Automation

As regras de automação transformam uma label em um responsável no momento em que a issue é criada, então ninguém precisa fazer a triagem manualmente.

Mantenha a responsabilidade em um campo seu, Team ou Component, e deixe as labels alimentá-lo. Renomear ou apagar uma label da WASViking para mudar o responsável não funciona, porque a sincronização a coloca de volta.

Dashboards e relatórios

Filtros salvos sobre as labels dão à revisão semanal os seus números sem que ninguém precise montar uma planilha.

Um gadget de estatísticas de filtro bidimensionais, com as labels em um eixo e o status no outro, é a visão mais útil de todas: todas as áreas, todos os estados, uma única tabela.

Mantenha os dois namespaces separados

Use as suas próprias labels à vontade para tudo o que a sincronização não expressa: sprint, responsabilidade, estado de revisão, impacto no cliente. Deixe as labels wasviking- para a sincronização. Se um valor não se encaixa na sua convenção de nomes, mapeie-o com uma regra de automação para uma label ou um campo seu, em vez de editar a label no card.

Referência de JQL

As labels são comparadas de forma exata e diferenciam maiúsculas de minúsculas no JQL, então digite-as como aparecem aqui, em minúsculas.