Findings Visibility

The findings-visibility input controls how much detail the action exposes in PR comments and inline annotations. This is a security control designed primarily for public repositories, where PR comments are visible to anyone.

Why This Matters

When the action reports a vulnerability – its title, file location, and description – on a public pull request, a threat actor monitoring the repository can read those details and exploit the issue before your team applies a fix.

The findings-visibility input lets you choose the right trade-off between transparency and security for your repository.

The Three Modes

full Mode

This is the default. The PR comment includes a severity breakdown table along with the title, file location, and description of each finding. Inline annotations appear directly on the pull request diff.

Threat model: All PR viewers are trusted. There is no information asymmetry to exploit. This mode is appropriate for private repositories and internal development.

findings-visibility: full

counts Mode

The PR comment shows only a severity breakdown table – for example, “2 critical, 1 high, 3 medium” – without revealing which vulnerabilities were found or where they are located. Inline annotations are suppressed.

Threat model: An attacker monitoring the PR learns that findings exist and their severity distribution, but not what the findings are or where they live in the code. This gives your team an at-a-glance signal for the PR without exposing actionable exploit details.

findings-visibility: counts

private Mode

The PR comment shows only a neutral message such as “Findings detected – see private report” along with a link to the full report on Odin Scan (which requires authentication). Inline annotations are suppressed.

Threat model: An attacker learns only that a scan ran. Even the count of findings is hidden, which prevents inferring that a PR touches security-sensitive code. This is the most restrictive mode.

findings-visibility: private

Annotation Suppression

Inline annotations (core.error and core.warning calls in GitHub Actions) render directly on the pull request diff with the full vulnerability title, file path, and description. On a public repository, they are just as visible as the PR comment itself.

When findings-visibility is set to counts or private, the action suppresses all inline annotations so that disclosure control is consistent across both channels.

Zero-Findings Behavior

The way the action reports zero findings differs by mode:

• full and counts: The PR comment shows “No security findings detected.”
• private: The PR comment shows “Security analysis complete.” – a neutral message that avoids leaking even the absence of findings as a signal.

Channels Not Affected

The findings-visibility setting only controls PR comments and inline annotations. The following channels always contain full finding details, regardless of this setting:

• SARIF / Code Scanning – Results are visible only to users with security permissions on the repository, even on public repos. See SARIF Integration.
• Workflow Artifacts – The full JSON report requires repository write access to download.

These channels are already protected by GitHub’s own permission model, so redaction is unnecessary.

Choosing a Mode

Configuration

- uses: odin-scan/odin-scan-action@v1
  with:
    api-key: ${{ secrets.ODIN_SCAN_API_KEY }}
    findings-visibility: private

See Inputs for the full list of configuration options.