Code Scanning

Code scanning finds security weaknesses in your own source code, such as injection, unsafe cryptography or unsafe use of the file system, and lists them as findings on the repository Security tab, next to dependency alerts and secret findings. It is available in Gitea Enterprise v27.3.8 and later.

Findings of code scanning come from four sources:

Source	Description
gosec	The static analyzer for Go, run by Gitea over every Go package of the scanned commit.
Semgrep	The semgrep engine, run on the Gitea server with the ruleset you provide. Any language that semgrep rules cover can be scanned.
SARIF import	The SARIF reports that your CI already produces with any tool (CodeQL, Trivy, SonarQube, and so on) are imported instead of running an engine in Gitea.
Security agent	A security scan agent reports the findings it judged to be real.

All sources share the same lifecycle, filters, API and SARIF export, and a source only ever reconciles and closes the findings it reported itself.

Enable code scanning

For the instance

Open Site Administration > Security, section Code scanning:

Setting	Description
Allow code scanning across this instance	The instance-wide switch (default on).
Enable Code Scanning (SARIF import) by Default	Repositories that never saved their own settings follow this switch (default off).
Read SARIF Reports Committed in Repositories by Default	The default of the per-repository switch that reads reports committed to the repository (default off).

For a repository

1. Open Repository > Settings > Security Scan and make sure security scanning is enabled for the branches you want, using Branch Patterns.
2. In the Code scanning section, enable the scanners you want. Each scanner has its own paths, rules and allowlist options.
3. Save. Saving triggers a rescan.

The scanners that run on the commit are scanned on a push to a matching branch and on a regular schedule. The settings page lists every scan run with its commit, status and the number of findings found, added and fixed, and offers Retry for failed runs.

Semgrep

Gitea Enterprise does not ship semgrep rules. An administrator installs semgrep on the Gitea server and supplies a ruleset in Site Administration > Security, section semgrep:

Setting	Description
Run the semgrep engine	Turns the engine on for the instance. A repository can only use the scanner when it is on.
semgrep executable	A name on the PATH of the server, or the path of the executable. Default semgrep.
Ruleset download URL	A tar.gz of rule files, downloaded once per version and kept. {version} stands for the version below. Only its yaml files are used.
Ruleset version	The version of the ruleset, which the cache is keyed by.
Ruleset sha256	The sha256 of the archive. Required: the rules decide what a scan reports, so an archive that does not match is refused.
Allow repositories to add their own rules	Lets a repository add rules of its own, see below.

The page shows the state of the engine: the ruleset in use and the number of rule files, whether semgrep accepts the ruleset (every scan fails until it does), or why the scanner is not offered (the engine is off, no ruleset is available, or the executable cannot be run).

Repository rules

When repository rules are allowed, a repository lists its own semgrep rules in .gitea/sast-ruleset.toml, read from the commit that is scanned:

[semgrep]
rules = [".gitea/rules/semgrep", "tools/no-eval.yaml"]

Entries are yaml files or directories relative to the repository root, up to 200 files of at most 1 MiB each. They are loaded together with the instance ruleset, and their findings have a rule ID that starts with repo.. The rules only match code, they do not run anything. Turn the switch off if repositories must only be checked by the instance ruleset.

SARIF import

A repository that already runs an analyzer in CI can hand the result to Gitea instead of installing anything on the server. Gitea reads SARIF 2.1 documents from two places:

• Uploaded reports. Users with write access to the security unit upload a report in Repository > Settings > Security Scan, Upload a report: choose the branch, an optional commit and the SARIF file. The report of the latest analysis of every branch and tool is kept, and a scan of that branch reconciles its findings with it. Reports can be removed again, and the settings page shows the tool, the number of findings, the size and the uploader. Turn Allow reports to be uploaded off to refuse uploads.
• Committed reports. With Read the SARIF reports committed in the repository on, files whose name ends in .sarif or .sarif.json in the scanned commit are imported as well. Use this when a pipeline commits its reports. The paths option says where the reports are, not where the findings are.

A report may be up to 1 MiB for a committed file and has at most 5000 results; the rest are dropped. When the same result arrives from an upload and from the committed copy, it is one finding. The severity is taken from the rule’s security-severity score when there is one, and from the SARIF level otherwise.

Findings

Select Code scanning on the Security tab. Each finding shows the rule, level, the file and line with the code, the message, the CWE, the confidence, the tool that reported it, and, when the tool provides them, a description, an exploit scenario, a recommendation and a help link. Filters are available for status, severity, branch, rule and file path.

Users with write access to the security unit can dismiss a finding with a reason (a fix has already been started, no bandwidth to fix this, the risk is tolerable, the finding is inaccurate, the code is not used or only used in tests) and reopen it. A finding closes when a later scan does not find it any more.

Ignore file

Put exceptions next to the code so that they are reviewed with it. .gitea/code-scanning-ignore has one entry per line: a path (a file, a directory or a glob such as third_party or **/*.generated.go) the scanners do not report, or the 64-character fingerprint of a finding. Lines starting with # are comments. The file may have 1000 entries and 64 KiB at most. The settings page offers the same Allowed paths and Allowed findings per scanner.

Export and API

Export SARIF on the Security tab, or GET /api/v1/repos/{owner}/{repo}/security/findings/sarif, exports the findings in SARIF so that other tools can consume them. The same API as for other finding types applies (/repos/{owner}/{repo}/security/findings, dismiss and reopen) and needs a token with the security scope.

Agents

On the finding page, Triage with agent asks an agent to judge whether the finding is a real vulnerability (the verdict is Real vulnerability, False positive or Uncertain, with a confidence) and Fix with agent asks an agent to open a pull request that fixes it. Both need an agent with the matching option enabled, and the person asking needs write access to the security unit. Agents can also be started automatically for new findings. See the Agents documentation for the options.