Skip to content

Security tab

Available only in GitFlic Enterprise

The Security page is used to view and process detected vulnerabilities found by project security analyzers. Vulnerabilities on the page can be filtered by type, snapshot, severity level, and other parameters.

Triage mode allows you to select a classification for findings (False positive or Confirmed vulnerability). More details in the article about Triage.

To work with the security page, a role that includes the Просмотр уязвимостей, Управление уязвимостями, Разбор уязвимостей, Проверка разбора уязвимостей permissions is required. This permission is included by default in the standard Developer role.

Uploading reports

Supported report types

The security page supports the following report types:

Report type Description Format Specification
SAST Results of static security analysis of source code SARIF SARIF 2.1.0
DAST Results of dynamic security analysis of the application SARIF SARIF 2.1.0
SCA Results of software composition analysis and used components CycloneDX CycloneDX in JSON or XML format

Reports can be added to the security page automatically from a pipeline or manually.

Uploading from a pipeline

The security analyzer runs in a pipeline job and generates a report in a supported format. After the job is completed, the report is transferred to GitFlic and displayed on the project security page.

The analyzer is configured and run on the resources used by the CI/CD agent. The analyzer and its launch scenario must be selected and configured for the project independently.

More information about preparing reports and connecting analyzers is provided in the SAST, DAST, and SCA articles.

Manual upload

A prepared report can be uploaded without running the analyzer in a pipeline.

To manually upload a report, it is required to:

  1. Open the report management section on the security page.
  2. Go to adding a report.
  3. Upload the prepared file.
  4. Specify the report type.
  5. Select the branch to which the report belongs.
  6. Complete the upload.

During manual upload, the snapshot is linked to the latest commit of the selected working branch.

Manual upload is intended for cases when a security report needs to be added without a CI/CD pipeline.

Up to 30 files can be submitted at once.

Uploading an empty report

A valid empty report also makes sense: it confirms that the corresponding type of analysis was performed, but no vulnerabilities were found in this state. Such a report can affect the current state of already known vulnerabilities, taking into account commit history and the logical branch.

Report snapshots

Reports are grouped into snapshots. A snapshot records analysis results for a specific project state.

For a report generated in a pipeline, the snapshot contains a link to the pipeline in which the report was obtained. On the pipeline page, a link to the commit that defines the repository state at the time of scanning is available.

Thus, the chain of links has the following form:

Снэпшот отчета → конвейер → коммит

Snapshots can be distinguished by the name, which is formed from the creation date and the name of the branch or tag for which the pipeline was started.

During manual upload, the snapshot is created for the latest commit of the selected working branch.

Vulnerability page overview

When a vulnerability is selected in the list, its internal page opens. The page shows not only general information about the finding, but also the selected context — the logical branch or tag within which the user is viewing the vulnerability.

The following information is available for each detected vulnerability: Severity, Branch, Commit, Utility, Scanner, Current snapshot, Status, Class.

The “By branches” tab displays only those vulnerability contexts that simultaneously:

  • belong to branches included in the current LTS settings;
  • have already been created for this vulnerability during report processing.

Contexts are sorted by LTS branch priority. For each context, the branch name and the current investigation state are shown, if it exists. The user can switch the context and view the same vulnerability in another LTS branch.

If the vulnerability did not occur in any of the configured LTS branches, the list will be empty. The context of the actual branch that is not included in the current LTS settings can still be opened by direct navigation from its snapshot or pipeline, but it will not appear in the LTS branch switcher.

Changing the state

If an investigation object has been created for the selected context and the user has the vulnerability management permission, the following states are available on the page:

  • Requires attention;
  • Confirmed;
  • Rejected;
  • Resolved.

Moving to Разрешена requires additional confirmation. This is a terminal (final) state: after it, the same investigation object cannot be moved back to another state.

State change buttons are displayed only for vulnerabilities admitted to investigation.

Comments and discussions

Comments are linked to the vulnerability context. Therefore, discussion of the same detected vulnerability in different LTS branches is kept separately.

The page has two views:

  • “Current branch” — discussions of the selected context;
  • “Other LTS branches” — discussions of the same vulnerability in the other available LTS contexts.

In the current context, a user with the appropriate permissions can:

  • start a new discussion;
  • reply in an existing discussion;
  • mark a discussion as resolved;
  • delete their own comment;
  • delete someone else's comment if they have the extended permission.

The author of the root comment or a user with the appropriate permission can finish the discussion. The “Other LTS branches” tab is intended for viewing. To leave a comment in another branch, it is necessary to select it on the “By branches” tab, after which it will become the current context.

The ability to leave contextual comments does not depend on the presence of an investigation object: it is also possible to discuss a vulnerability for which changing the state is not yet available.

Configuring LTS branches

The setting is located in the project settings in the “Security” section.

LTS branches define the branches by which GitFlic groups vulnerability states. This is useful when reports are run in many feature branches, but the results need to be assigned to a limited set of long-term supported branches.

Order matters: the higher a branch is in the list, the higher its priority.

Working with vulnerabilities in Merge Requests

When working in a Merge Request, it is possible to view not the full list of vulnerabilities of the branches (source and target), but the difference — the security changes introduced by the current Merge Request.

The Security tab includes two types of vulnerabilities:

  • a vulnerability is introduced by the merge request;
  • a vulnerability is resolved by the merge request.

To calculate findings, “Merge pipeline” must be enabled.

The calculation is tied to the state of branches at the time the pipeline is started:

  • the commit of the source branch for which the pipeline is started;
  • the commit of the target branch recorded when the pipeline is started.

If the target branch advances while the pipeline is running, this will not change the already started calculation. To compare with the new state of the target branch, a new merge pipeline must be started.

For one type of analysis, sets of vulnerabilities from the selected snapshots are used:

  • a vulnerability is considered introduced if it exists in the source but is absent from the target branch state that is current for the calculation;
  • a vulnerability is considered resolved if it existed in the common base history, is still present in the target, but is absent from the source.

Boundary cases:

  • If there is no suitable snapshot of the source branch, an empty difference is returned: there is nothing to compare the source branch with.
  • If there is neither a base nor a newer snapshot in target, all source vulnerabilities are considered introduced.
  • An empty but valid report means that the check was performed and no vulnerabilities were found. This differs from the absence of a report.
  • A processing error in at least one artifact makes the calculation of the corresponding analysis type unsuccessful.
  • If a new merge pipeline has no security reports, a new calculation is created only when the target branch has changed relative to the last ready result. If target has not changed, the previous result is preserved.

Automated translation!

This page has been automatically translated. The text may contain inaccuracies.