Suporte SARIF para a varredura de código

Sobre o suporte SARIF

O SARIF (Static Analysis Results Interchange Format) é um Padrão do OASIS que define um formato de arquivo de saída. O padrão SARIF é usado para simplificar como as ferramentas de análise estáticas compartilham seus resultados. O Code scanning é compatível com um subconjunto do esquema JSON do SARIF 2.1.0.

Para fazer o upload de um arquivo SARIF a partir de um mecanismo de análise de código estático de terceiros, você deverá garantir que os arquivos carregados usem a versão SARIF 2.1.0. GitHub analisará o arquivo SARIF e mostrará alertas utilizando os resultados no seu repositório como parte da experiência de code scanning. Para saber mais, confira Fazer o upload de arquivo SARIF para o GitHub. Para obter mais informações sobre o esquema JSON SARIF 2.1.0, confira sarif-schema-2.1.0.json.

Se você estiver usando o GitHub Actions com o Fluxo de trabalho de análise do CodeQL ou usando o CodeQL CLI, os resultados code scanning usarão automaticamente o subconjunto suportado do SARIF 2.1.0. Para obter mais informações, confira Como definir a configuração avançada para verificação de código ou Usando a varredura de código com seu sistema de CI existente.

GitHub usa propriedades no arquivo SARIF para exibir alertas. Por exemplo, a shortDescription e a fullDescription são exibidas na parte superior de um alerta da code scanning. O location permite que o GitHub mostre as anotações no seu arquivo de código. Para saber mais, confira Sobre alertas de digitalização de códigos.

Se estiver familiarizado com o SARIF e quiser saber mais, confira o repositório SARIF tutorials da Microsoft.

Como fornecer dados para acompanhar os alertas code scanning em todas as execuções

Cada vez que os resultados de uma nova verificação de código são carregados, os resultados são processados e os alertas são adicionados ao repositório. Para evitar alertas duplicados para o mesmo problema, code scanning usa impressões digitais para corresponder aos resultados em várias execuções, para que apareçam apenas uma vez na última execução do ramo selecionado. Isto torna possível combinar alertas com a linha de código correta quando os arquivos são editados. O ruleID de um resultado deve ser o mesmo em toda a análise.

Como relatar caminhos de arquivo consistentes

O caminho do arquivo precisa ser consistente entre as execuções para habilitar a computação de uma impressão digital estável. Se os caminhos de arquivo forem diferentes para o mesmo resultado, sempre que houver uma nova análise, um novo alerta será criado e o antigo será fechado. Isso causará vários alertas para o mesmo resultado.

Como incluir dados para geração de impressão digital

O GitHub usa a propriedade partialFingerprints no padrão OASIS para detectar quando dois resultados são logicamente idênticos. Para obter mais informações, confira a entrada propriedade partialFingerprints na documentação do OASIS.

Os arquivos do SARIF criados pelo Fluxo de trabalho de análise do CodeQL ou usando o CodeQL CLI incluem dados de impressão digital. Se você carregar um arquivo SARIF usando a ação upload-sarif e esses dados estiverem ausentes, o GitHub tentará preencher o campo partialFingerprints usando os arquivos de origem. Para saber mais sobre como carregar resultados, confira Fazer o upload de arquivo SARIF para o GitHub.

Se você carregar um arquivo SARIF sem dados de impressão digital usando o ponto de extremidade de API /code-scanning/sarifs, os alertas da code scanning serão processados e exibidos, mas os usuários poderão ver alertas duplicados. Para evitar ver alertas duplicados, calcule dados de impressão digital e preencha a propriedade partialFingerprints antes de carregar o arquivo SARIF. Você pode achar o script usado pela ação upload-sarif um ponto de partida útil: https://github.com/github/codeql-action/blob/main/src/fingerprints.ts. Para saber mais sobre a API, confira Pontos de extremidade da API REST para varredura de código.

Noções básicas sobre regras e resultados

Os arquivos SARIF dão suporte a regras e resultados. As informações armazenadas nesses elementos são semelhantes, mas têm propósitos diferentes.

As regras são uma matriz de objetos reportingDescriptor que estão incluídos no objeto toolComponent. Nele, são armazenados detalhes das regras que são executadas durante a análise. As informações nesses objetos devem ser alteradas com pouca frequência, geralmente quando você atualiza a ferramenta.
Os resultados são armazenados como uma série de objetos result sob results no objeto run. Cada objeto result contém detalhes de um alerta na base de código. Dentro do objeto results, você pode fazer referência à regra que detectou o alerta.

Ao comparar arquivos SARIF gerados pela análise de diferentes bases de código com a mesma ferramenta e regras, verá diferenças nos resultados das análises, mas não nas regras.

Como especificar a localização para arquivos de origem

A especificação dos locais do arquivo de origem e linhas de código garante que os alertas de verificação de código sejam exibidos corretamente no arquivo que contém o problema identificado, permitindo a resolução do problema direcionado.

Essa precisão aumenta a eficiência dos processos de revisão e resolução de código, simplificando os fluxos de trabalho de desenvolvimento, permitindo que os desenvolvedores resolvam problemas diretamente no contexto de sua base de código.

O Code scanning também exibirá resultados de verificações em pull requests quando todas as linhas de código identificadas pelo alerta existirem na comparação da pull request.

Para exibição em uma verificação de pull request, um alerta deve atender a todas as seguintes condições:

Todas as linhas de código identificadas pelo alerta existem na comparação da pull request, incluindo a primeira linha do alerta.
O alerta deve existir nas linhas de código adicionadas ou editadas na pull request, e não nas linhas que foram excluídas.

O objeto physicalLocation em um arquivo SARIF enviado identifica as linhas de código de um alerta. Para obter mais informações, confira Objeto physicalLocation.

Como especificar a raiz para arquivos de origem

O Code scanning interpreta os resultados relatados com os caminhos relativos baseados na raiz do repositório analisado. Se um resultado contiver um URI absoluto, ele será convertido em um URI relativo. Em seguida, o URI relativo pode ser correspondido com um arquivo confirmado no repositório.

Você pode fornecer a raiz de origem para conversão de URIs absolutos em relativos de uma das maneiras a seguir.

Entrada checkout_path para a ação github/codeql-action/analyze
Parâmetro checkout_uri para o ponto de extremidade da API de upload de SARIF. Para saber mais, confira Pontos de extremidade da API REST para varredura de código.
Propriedade invocations[0].workingDirectory.uri no objeto run no arquivo SARIF

Se você fornecer uma raiz de origem, qualquer local de um artefato especificado usando um URI absoluto deverá usar o mesmo esquema de URI. Se houver uma incompatibilidade entre o esquema de URI para a raiz de origem e um ou mais URIs absolutos, o upload será rejeitado.

Por exemplo, um arquivo SARIF é carregado usando uma raiz de origem de file:///github/workspace.

# Conversion of absolute URIs to relative URIs for location artifacts

file:///github/workspace/src/main.go -> src/main.go
file:///tmp/go-build/tmp.go          -> file:///tmp/go-build/tmp.go

O arquivo é carregado com êxito, pois ambos os URIs absolutos usam o mesmo esquema de URI que a raiz de origem.

Resolvendo links simbólicos antes de gerar resultados SARIF

Se o URI relativo de um resultado for comparado a um arquivo definido usando um link simbólico, a varredura de código não poderá exibir o resultado. Portanto, você precisa resolver todos os arquivos com links simbólicos e relatar quaisquer resultados nesses arquivos usando o URI resolvido.

Validar seu arquivo SARIF

Você pode marcar um arquivo SARIF compatível com code scanning testando-o com as regras de ingestão de GitHub. Para obter mais informações, acesse o validador de SARIF da Microsoft.

Para cada arquivo SARIF compactado com gzip, o upload do SARIF dá suporte a um tamanho máximo de 10 MB. Todos os uploads acima desse limite são rejeitados. Se o arquivo SARIF for muito grande porque contém muitos resultados, você deverá atualizar a configuração para se concentrar nos resultados das regras ou consultas mais importantes. Para saber mais, confira O arquivo de resultados SARIF é muito grande.

O Code scanning dá suporte ao upload de um número máximo de entradas dos objetos de dados na tabela a seguir. Se um desses objetos exceder o valor máximo, o arquivo SARIF será rejeitado. Para alguns objetos, há também um limite adicional no número de valores que serão exibidos. Sempre que possível, os valores mais importantes são mostrados. Para aproveitar a análise ao máximo quando ela inclui os dados acima dos limites com suporte, tente otimizar a configuração de análise (por exemplo, para a ferramenta CodeQL, identifique e desabilite as consultas mais confusas). Para saber mais, confira Os resultados do SARIF excedem um ou mais limites.

Dados SARIF	Valores máximos	Limites de truncamento de dados
Execuções por arquivo	20	Nenhum
Resultados por execução	25,000	Somente os 5 mil resultados principais serão incluídos, priorizados por severidade.
Regras por execução	25,000	Nenhum
Extensões de ferramenta por execução	100	Nenhum
Locais de fluxo de threads por resultado	10.000	Somente os mil principais locais de fluxo de threads serão incluídos, usando a priorização.
Local por resultado	1,000	Somente 100 locais serão incluídos.
Marcas por regra	20	Somente dez marcas serão incluídas.
Limite de alerta	1.000.000	Nenhum

Para obter informações sobre outros erros, confira Solução de problemas de uploads SARIF

Carregar mais de um arquivo SARIF para um commit

Você pode fazer o upload de vários arquivos SARIF para o mesmo commit e exibir os dados de cada arquivo como resultado de code scanning. Ao fazer o upload de vários arquivos SARIF para um commit, você deverá indicar uma "categoria" para cada análise. A forma de especificar uma categoria varia de acordo com o método de análise:

Usando a CodeQL CLI diretamente, transmita o argumento --sarif-category para o comando codeql database analyze ao gerar arquivos SARIF. Para saber mais, confira Sobre a CLI do CodeQL.
Usando o GitHub Actions com codeql-action/analyze, a categoria será definida automaticamente com base no nome do fluxo de trabalho e em qualquer variável de matriz (geralmente, language). Substitua isso especificando uma entrada category para a ação, que é útil quando você analisa diferentes seções de um monorrepositório em um fluxo de trabalho individual.
Usando o GitHub Actions para carregar os resultados de outras ferramentas de análise estática, você precisará especificar uma entrada category se carregar mais de um arquivo de resultados para a mesma ferramenta em um fluxo de trabalho. Para saber mais, confira Fazer o upload de arquivo SARIF para o GitHub.
Se não estiver usando nenhuma dessas abordagens, especifique uma runAutomationDetails.id exclusiva em cada arquivo SARIF para upload. Para obter mais informações sobre essa propriedade, consulte Objeto runAutomationDetails.

Se você fizer o upload de um segundo arquivo SARIF para um commit com a mesma categoria e a partir da mesma ferramenta, os resultados anteriores serão substituídos. No entanto, se você tentar fazer o upload de vários arquivos SARIF para a mesma ferramenta e categoria em um único fluxo de trabalho de GitHub Actions, a configuração incorreta será detectada e a execução falhará.

Propriedades compatíveis do arquivo de saída SARIF

Se você usar um mecanismo de análise de código diferente de CodeQL, você poderá revisar as propriedades do SARIF compatíveis para otimizar como seus resultados de análise aparecerão em GitHub.

Note

Você deve fornecer um valor explícito para qualquer propriedade marcada como "required". Não há suporte para cadeias de caracteres vazias em propriedades obrigatórias.

É possível fazer o upload de qualquer arquivo de saída SARIF 2.1.0 válido, no entanto, code scanning usará apenas as seguintes propriedades compatíveis.

Objeto `sarifLog`

Nome	Obrigatória	Descrição
`$schema`		O URI do esquema SARIF JSON para a versão 2.1.0. Por exemplo, `https://json.schemastore.org/sarif-2.1.0.json`.
`version`		O Code scanning só dá suporte ao SARIF versão `2.1.0`.
`runs[]`		Um arquivo SARIF contém uma matriz de uma ou mais execuções. Cada execução representa uma execução única de uma ferramenta de análise. Para obter mais informações sobre uma `run`, confira o objeto `run`.

Objeto `run`

O Code scanning usa o objeto run para filtrar os resultados por ferramenta e fornecer informações sobre a fonte de um resultado. O objeto run contém o objeto tool.driver de componentes da ferramenta, que contém informações sobre a ferramenta que gerou os resultados. Cada run pode ter resultados apenas para uma ferramenta de análise.

Nome	Obrigatória	Descrição
`tool.driver`		Um objeto `toolComponent` que descreve a ferramenta de análise. Para obter mais informações, confira o objeto `toolComponent`.
`tool.extensions[]`		Uma matriz de objetos `toolComponent` que representam plug-ins ou extensões usadas pela ferramenta durante a análise. Para obter mais informações, confira o objeto `toolComponent`.
`invocation.workingDirectory.uri`		Esse campo é usado somente quando `checkout_uri` (somente API de upload do SARIF) ou `checkout_path` (somente GitHub Actions) não são fornecidos. O valor é usado para converter URIs absolutos usados em objetos `physicalLocation` em URIs relativos. Para obter mais informações, confira Como especificar a raiz para arquivos de origem.
`results[]`		Os resultados da ferramenta de análise. O Code scanning exibe os resultados no GitHub. Para obter mais informações, confira o objeto `result`.

Objeto `toolComponent`

Nome	Obrigatória	Descrição
`name`		O nome da ferramenta de análise. O Code scanning exibe o nome no GitHub para permitir que você filtre resultados por ferramenta.
`version`		A versão da ferramenta de análise. O Code scanning usa o número da versão para monitorar quando os resultados podem ter mudado devido a uma mudança na versão da ferramenta em vez de uma mudança no código que está sendo analisado. Se o arquivo SARIF incluir o campo `semanticVersion`, `version` não será usado pela code scanning.
`semanticVersion`		A versão da ferramenta de análise, especificada pelo formato Versionamento Semântico 2.0. O Code scanning usa o número da versão para monitorar quando os resultados podem ter mudado devido a uma mudança na versão da ferramenta em vez de uma mudança no código que está sendo analisado. Se o arquivo SARIF incluir o campo `semanticVersion`, `version` não será usado pela code scanning. Para obter mais informações, confira Versionamento Semântico 2.0.0 na documentação do Versionamento Semântico.
`rules[]`		A matriz de objetos `reportingDescriptor` que representa as regras. A ferramenta de análise usa regras para encontrar problemas no código que está sendo analisado. Para obter mais informações, confira o objeto `reportingDescriptor`.

Objeto `reportingDescriptor`

Nele, são armazenados detalhes das regras que são executadas durante a análise. As informações nesses objetos devem ser alteradas com pouca frequência, geralmente quando você atualiza a ferramenta. Para obter mais informações, consulte Noções básicas sobre regras e resultados acima.

Nome	Obrigatória	Descrição
`id`		Um identificador exclusivo para a regra. A `id` é referenciada com base em outras partes do arquivo SARIF e pode ser usada pela code scanning para exibir URLs no GitHub.
`name`		O nome da regra. O Code scanning exibe o nome para permitir que os resultados sejam filtrados pela regra no GitHub. Limitado a 255 caracteres.
`shortDescription.text`		Uma descrição concisa da regra. O Code scanning exibe uma breve descrição no GitHub ao lado dos resultados associados. Limitado a 1024 caracteres.
`fullDescription.text`		Descrição da regra. O Code scanning exibe uma descrição completa no GitHub ao lado dos resultados associados. Limitado a 1024 caracteres.
`defaultConfiguration.level`		Nível de gravidade padrão da regra. O Code scanning usa níveis de gravidade para ajudar você a entender quão crítico é o resultado para uma determinada regra. Por padrão, o `defaultConfiguration.level` está definido como `warning`. No entanto, você pode substituir o nível padrão de uma regra definindo o atributo `level` no objeto `result` associado ao resultado. Para obter mais informações, consulte a documentação do objeto `result`. Os valores válidos para `defaultConfiguration.level` são: `note`, `warning` e `error`.
`help.text`		Documentação da regra usando o formato de texto. O Code scanning exibe essa documentação de ajuda ao lado dos resultados associados.
`help.markdown`		(Recomendado) Documentação da regra usando o formato Markdown. O Code scanning exibe essa documentação de ajuda ao lado dos resultados associados. Quando `help.markdown` está disponível, ele é exibido em vez de `help.text`.
`properties.tags[]`		Uma matriz de cadeias de caracteres. O Code scanning usa `tags` para permitir que você filtre os resultados no GitHub. Por exemplo, é possível filtrar todos os resultados que têm a marca `security`.
`properties.precision`		(Recomendado) Uma cadeia de caracteres que indica a frequência com que os resultados indicados por essa regra são verdadeiros. Por exemplo, se uma regra tem uma alta taxa conhecida de falsos-positivos, a precisão deve ser `low`. O Code scanning ordena os resultados por precisão no GitHub, de modo que os resultados com o `level` mais alto e a `precision` mais alta sejam mostrados primeiro. Pode ser `very-high`, `high`, `medium` ou `low`.
`properties.problem.severity`		(Recomendado) Uma cadeia de caracteres que indica o nível de gravidade de todos os alertas gerados por uma consulta que não é de segurança. Isso, com a propriedade `properties.precision`, determina se os resultados são exibidos por padrão no GitHub, de modo que os resultados com a `problem.severity` mais alta e a `precision` mais alta sejam mostrados primeiro. Pode ser `error`, `warning` ou `recommendation`.
`properties.security-severity`		(Recomendado apenas para regras de segurança) Se você incluir um valor para esse campo, os resultados da regra serão tratados como resultados de segurança. Uma sequência representando uma pontuação que indica o nível de gravidade, um valor entre 0 e 10 para as consultas de segurança (`@tags` inclui `security`). Isso, com a propriedade `properties.precision`, determina se os resultados são exibidos por padrão no GitHub, de modo que os resultados com a `security-severity` mais alta e a `precision` mais alta sejam mostrados primeiro. O Code scanning converte as pontuações numéricas da seguinte maneira: acima de 9 é `critical`, de 7 a 8,9 é `high`, de 4 a 6,9 é `medium` e abaixo de 3,9 é `low`. Um valor de 0 ou qualquer outro valor fora do intervalo determinado é considerado como sem gravidade de segurança.

Objeto `result`

Cada objeto result contém detalhes de um alerta na base de código. Dentro do objeto results, você pode fazer referência à regra que detectou o alerta. Para obter mais informações, consulte Noções básicas sobre regras e resultados acima.

Você pode verificar se as propriedades SARIF têm um tamanho compatível com o upload e se o arquivo é compatível com a verificação de código. Para obter mais informações, confira "Suporte SARIF para a varredura de código".

Nome	Obrigatória	Descrição
`ruleId`		O identificador exclusivo da regra (`reportingDescriptor.id`). Para obter mais informações, confira o objeto `reportingDescriptor`. O Code scanning usa o identificador da regra para filtrar os resultados por regra no GitHub.
`ruleIndex`		O índice da regra associada (objeto `reportingDescriptor`) na matriz `rules` de componentes da ferramenta. Para obter mais informações, confira o objeto `run`. O intervalo permitido para essa propriedade 0 a 2^63 - 1.
`rule`		Uma referência usada para localizar a regra (descritor de relatório) para esse resultado. Para obter mais informações, confira o objeto `reportingDescriptor`.
`level`		A gravidade do resultado. Esse nível sobrepõe a severidade-padrão definida pela regra. O Code scanning usa o nível para filtrar resultados por gravidade no GitHub.
`message.text`		Uma mensagem que descreve o resultado. O Code scanning exibe o texto da mensagem como o título do resultado. Apenas a primeira frase da mensagem será exibida quando o espaço visível for limitado.
`locations[]`		O conjunto de locais em que o resultado foi detectado até, no máximo, dez. Só um local deve ser incluído, a não ser que o problema só possa ser corrigido fazendo uma alteração em cada local especificado. Observação: Pelo menos, um local é necessário para a code scanning exibir um resultado. O Code scanning usará essa propriedade para decidir qual arquivo anotar com o resultado. Apenas o primeiro valor desse array é usado. Todos os outros valores são ignorados.
`partialFingerprints`		Um conjunto de cadeias de caracteres usadas para acompanhar a identidade exclusiva do resultado. O Code scanning usa `partialFingerprints` para identificar com precisão quais resultados são iguais nos commits e branches. O Code scanning tentará usar `partialFingerprints`, se houver. Se você estiver carregando arquivos SARIF de terceiros com a `upload-action`, a ação criará `partialFingerprints` para você quando eles não estiverem incluídos no arquivo SARIF. Para obter mais informações, confira Como fornecer dados para rastrear alertas de exame de código nas execuções. Observação: o Code scanning só usa o `primaryLocationLineHash`.
`codeFlows[].threadFlows[].locations[]`		Uma matriz de objetos `location` para um objeto `threadFlow`, que descreve o progresso de um programa por meio de um thread de execução. Um objeto `codeFlow` descreve um padrão de execução de código usado para detectar um resultado. Se forem fornecidos fluxos de código, code scanning irá expandir os fluxos de código em GitHub para o resultado relevante. Para obter mais informações, confira o objeto `location`.
`relatedLocations[]`		Um conjunto de locais relevantes para este resultado. O Code scanning vinculará a locais relacionados quando forem incorporados à mensagem do resultado. Para obter mais informações, confira o objeto `location`.

Objeto `location`

Um local dentro de um artefato de programação, como, por exemplo, um arquivo no repositório ou um arquivo gerado durante uma criação.

Nome	Obrigatória	Descrição
`location.id`		Um identificador exclusivo que distingue esse local de todos os outros locais em um só objeto de resultado. O intervalo permitido para essa propriedade 0 a 2^63 - 1.
`location.physicalLocation`		Identifica o artefato e a região. Para obter mais informações, confira `physicalLocation`.
`location.message.text`		Uma mensagem relevante à localização.

Objeto `physicalLocation`

Nome	Obrigatória	Descrição
`artifactLocation.uri`		Um URI que indica o local de um artefato, geralmente um arquivo no repositório ou gerado durante um build. Para obter os melhores resultados, recomendamos que esse seja um caminho relativo da raiz do repositório GitHub que está sendo analisado. Por exemplo, `src/main.js`. Para obter mais informações sobre URIs de artefato, confira Como especificar a raiz para arquivos de origem.
`region.startLine`		O número de linha do primeiro caractere na região.
`region.startColumn`		O número da coluna do primeiro caractere na região.
`region.endLine`		O número de linha do último caractere na região.
`region.endColumn`		O número da coluna do caractere após o final da região.

Objeto `runAutomationDetails`

O objeto runAutomationDetails contém informações que especificam a identidade de uma execução.

Nome	Obrigatória	Descrição
`id`		Uma cadeia de caracteres que identifica a categoria da análise e a ID de execução. Use se você quiser fazer upload de vários arquivos SARIF para a mesma ferramenta e commit, mas executado em diferentes idiomas ou diferentes partes do código.

O uso do objeto runAutomationDetails é opcional.

O campo id pode incluir uma categoria de análise e uma ID de execução. Não usamos a parte da ID de execução do campo id, mas a armazenamos.

Use a categoria para distinguir entre múltiplas análises para a mesma ferramenta ou commit, mas executada em diferentes linguagens ou partes diferentes do código. Use o ID de execução para identificar a execução específica da análise, como a data em que a análise foi executada.

id é interpretado como category/run-id. Se a id não contiver nenhuma barra (/), a cadeia de caracteres inteira será a run_id e a category ficará vazia. Caso contrário, a category será tudo na cadeia de caracteres até a última barra, e a run_id será tudo após ela.

`id`	category	`run_id`
my-analysis/tool1/2022-01-02	my-analysis/tool1	02-01-2022
my-analysis/tool1/	my-analysis/tool1	Nenhum
my-analysis for tool1	Nenhum	my-analysis for tool1

A execução com uma id igual a "my-analysis/tool1/2021-02-01" pertence à categoria "my-analysis/tool1".
A execução com uma id igual a "my-analysis/tool1/" pertence à categoria "my-analysis/tool1", mas não é distinta das outras execuções nessa categoria.
A execução cuja id é "my-analysis for tool1" tem um identificador único, mas não pode ser inferida como pertencente a nenhuma categoria.

Para obter mais informações sobre o objeto runAutomationDetails e o campo id, confira o objeto runAutomationDetails na documentação do OASIS.

Observe que o resto dos campos compatíveis são ignorados.

Exemplos de arquivos de saída SARIF

Estes exemplos de arquivos de saída SARIF mostram as propriedades compatíveis e os valores de exemplo.

Exemplo com as propriedades mínimas necessárias

Este arquivo de saída SARIF tem exemplo de valores para mostrar as propriedades mínimas necessárias para que os resultados de code scanning funcionem conforme esperado. Se você remover qualquer propriedade, omitir valores ou usar uma cadeia de caracteres vazia, esses dados não serão exibidos corretamente ou serão sincronizados em GitHub.

{
  "$schema": "https://json.schemastore.org/sarif-2.1.0.json",
  "version": "2.1.0",
  "runs": [
    {
      "tool": {
        "driver": {
          "name": "Tool Name",
          "rules": [
            {
              "id": "R01"
                      ...
              "properties" : {
                 "id" : "java/unsafe-deserialization",
                 "kind" : "path-problem",
                 "name" : "...",
                 "problem.severity" : "error",
                 "security-severity" : "9.8",
               }
            }
          ]
        }
      },
      "results": [
        {
          "ruleId": "R01",
          "message": {
            "text": "Result text. This result does not have a rule associated."
          },
          "locations": [
            {
              "physicalLocation": {
                "artifactLocation": {
                  "uri": "fileURI"
                },
                "region": {
                  "startLine": 2,
                  "startColumn": 7,
                  "endColumn": 10
                }
              }
            }
          ],
          "partialFingerprints": {
            "primaryLocationLineHash": "39fa2ee980eb94b0:1"
          }
        }
      ]
    }
  ]
}

Diretrizes de URI relativo para produtores de SARIF

Este arquivo de saída SARIF tem um exemplo de valores para o campo originalUriBaseIds, mostrando as propriedades mínimas necessárias que um produtor de SARIF deve incluir ao usar referências de URI relativa.