Security

GitRiver includes tools for code security analysis: automatic secret scanning, importing results from external scanners, dependency license checking, and DORA metrics for process assessment.

Security features are Pro. The user needs an assigned Pro seat for access.

Secret Scanning

What It Is

On every push, GitRiver automatically checks changed files for secrets: AWS API keys, GitHub tokens, private keys, passwords in configs, and other sensitive data.

17 patterns for common secret types are built in.

Configuration

1. Open the repository -> Settings (gear icon) -> Security
2. Enable “Secret scanning”
3. By default, all 17 built-in patterns are used

Custom Patterns

If your company uses internal tokens or keys with a specific format:

1. On the same page Settings -> Security
2. Click “Add pattern”
3. Specify a name and regular expression (regex)

For example, for internal API keys in the format MYCO-xxxx-xxxx:

MYCO-[a-zA-Z0-9]{4}-[a-zA-Z0-9]{4}

Viewing Results

1. Open the repository -> “Security” tab
2. You will see a list of found issues with severity levels
3. For each one - file, line, secret type
4. Actions: dismiss (if false positive) or fix (remove the secret from code)

---

Importing Scan Results (SARIF)

What It Is

If you use external scanners (Semgrep, Trivy, CodeQL, OSV-Scanner), their results can be uploaded to GitRiver in SARIF format. This lets you see all security issues in one place.

Uploading from CI

A typical scenario is to run a scanner in a CI job and upload the result:

jobs:
  security:
    image: returntocorp/semgrep
    steps:
      - run: semgrep scan --sarif --output results.sarif .
      - run: |
          curl -X POST \
            -H "Authorization: Bearer $CI_JOB_TOKEN" \
            -F "file=@results.sarif" \
            $CI_SERVER_URL/api/v1/repos/$CI_REPOSITORY_OWNER/$CI_REPOSITORY_NAME/security/sarif

Uploading via the Interface

1. Open the repository -> “Security” tab
2. Click “Upload SARIF”
3. Select a file

---

Dependency License Checking

What It Is

Checks SPDX licenses of your project’s dependencies. Useful if your company prohibits certain licenses (e.g., GPL in a commercial product).

Configuring Policies

1. Open Settings -> License Policies
2. Create a policy:
   • Mode: allowlist (only specified licenses allowed) or blocklist (specified licenses prohibited)
   • Licenses: select SPDX identifiers (MIT, Apache-2.0, GPL-3.0, etc.)
3. Attach the policy to a repository

Running a Scan

1. Open the repository -> “Security” tab -> “Licenses”
2. Click “Scan”

GitRiver will analyze the project’s lock files (package-lock.json, Cargo.lock, poetry.lock, etc.), determine the licenses of all dependencies (including transitive ones), and display violations.

Generating SBOM

For auditing or delivery to a customer, you can generate a Software Bill of Materials in CycloneDX format.

---

DORA Metrics

What It Is

Four metrics for assessing the maturity of a team’s DevOps processes:

Metric	What It Measures
Deployment Frequency	How often you deploy to production
Lead Time for Changes	How long from commit to deployment
Change Failure Rate	What percentage of deployments cause failures
Mean Time to Recovery	How quickly you recover after a failure

Where to View

Open the repository -> “Analytics” tab (or “DORA”). Metrics are calculated automatically based on CI/CD and deployment data.

---

Audit Log

What It Is

A complete log of all actions in the system: who created a repository, who changed permissions, who deleted a user. Essential for compliance and incident investigation.

Viewing

Administration -> Audit

Filters: by operation type, by user, by date. Event types: creation/deletion of repositories, issues, PRs, releases, permission changes, forks, pushes, and more.

---

IP Restrictions

What It Is

An allowlist or blocklist of IP addresses to restrict access to the instance or group. Useful if GitRiver is accessible from the internet but should only be used from the office or VPN.

Configuration

1. Administration -> IP Restrictions -> “Add rule”
2. Specify:
   • IP address or CIDR - for example, 10.0.0.0/8 or 203.0.113.42
   • Action - allow or deny
   • Description - what the rule is for (office, VPN, CI)

If at least one allow rule exists, access is permitted only from the specified addresses.

IP restrictions can also be configured at the group level: Group Settings -> IP Restrictions.