chore(H2): baseline security gate #43

_{⚑ panel: GPT-OSS 120B · Gemma 4 31B · Devstral 2 123B · Laguna S 2.1 — 2 distinct, 1 confirmed, 1 refuted · web: not used · context: 1 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less)}

Panel debate — how this review was reached

Grounding — context: 1 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less)

Round 1 — independent reviews

GPT-OSS 120B (0 findings, confidence 0.97): The updated regex correctly excludes AWS access key IDs appearing as X‑Amz‑Credential parameters while preserving detection elsewhere, and conforms to the repository's security guidelines.
Gemma 4 31B (1 finding, confidence 1.0): The change correctly addresses a high-volume false positive in the AWS key detection rule using a negative lookbehind, but it introduces drift from the agency's canonical security standards source.
Devstral 2 123B (1 finding, confidence 0.9): The regex pattern update for AWS access key ID detection is flawed and needs correction to properly exclude presigned URLs.
Laguna S 2.1 (0 findings):

Round 2 — cross-examination

Devstral 2 123B#1 Incorrect regex pattern for AWS access key ID detection · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B, Laguna S 2.1
Gemma 4 31B#1 Inconsistent security rule baseline · confirmed: GPT-OSS 120B, Devstral 2 123B, Laguna S 2.1 · refuted: —

Raised but refuted (left out of the review above)

Devstral 2 123B#1 Incorrect regex pattern for AWS access key ID detection — The evidence shows the regex uses a negative lookbehind for the literal string X-Amz-Credential= exactly as described in the change comment. The com

Synthesis — Devstral 2 123B wrote the final review from 1 confirmed finding.

_{Transcript rv-20260818165100-1751f7 — full round outputs, web results, and model reasoning are viewable by anyone with access to this repository via the AI gateway.}

_{Advisory — never a merge gate. Disagree with a finding? Reply on it, or use the finding board under this review. Transcript rv-20260818165100-1751f7.}

### AI review · advisory  **Verdict: 1 thing worth fixing** (1 medium). ⚑ panel: GPT-OSS 120B · Gemma 4 31B · Devstral 2 123B · Laguna S 2.1 — 2 distinct, 1 confirmed, 1 refuted · web: not used · context: 1 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less) <details> <summary>Panel debate — how this review was reached</summary> **Grounding** — context: 1 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less) **Round 1 — independent reviews** - **GPT-OSS 120B** (0 findings, confidence 0.97): The updated regex correctly excludes AWS access key IDs appearing as X‑Amz‑Credential parameters while preserving detection elsewhere, and conforms to the repository's security guidelines. - **Gemma 4 31B** (1 finding, confidence 1.0): The change correctly addresses a high-volume false positive in the AWS key detection rule using a negative lookbehind, but it introduces drift from the agency's canonical security standards source. - **Devstral 2 123B** (1 finding, confidence 0.9): The regex pattern update for AWS access key ID detection is flawed and needs correction to properly exclude presigned URLs. - **Laguna S 2.1** (0 findings): **Round 2 — cross-examination** - `Devstral 2 123B#1` Incorrect regex pattern for AWS access key ID detection · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B, Laguna S 2.1 - `Gemma 4 31B#1` Inconsistent security rule baseline · confirmed: GPT-OSS 120B, Devstral 2 123B, Laguna S 2.1 · refuted: — **Raised but refuted** (left out of the review above) - `Devstral 2 123B#1` Incorrect regex pattern for AWS access key ID detection — The evidence shows the regex uses a negative lookbehind for the literal string `X-Amz-Credential=` exactly as described in the change comment. The com **Synthesis** — Devstral 2 123B wrote the final review from 1 confirmed finding. Transcript `rv-20260818165100-1751f7` — full round outputs, web results, and model reasoning are viewable by anyone with access to this repository via the AI gateway. </details> Advisory — never a merge gate. Disagree with a finding? Reply on it, or use the finding board under this review. Transcript `rv-20260818165100-1751f7`.

.forgejo/semgrep-rules/tti.yml

					
				@ -97,0 +109,4 @@

				    # as the fact that justifies it: `x-amz-credential=` and the URL-encoded

				    # `X-Amz-Credential%3D` are both still flagged (verified against semgrep

				    # 1.172.0). That keeps the evasion surface to the one exact canonical form

				    # while every near-miss still trips the rule. gitleaks remains the primary

.forgejo/semgrep-rules/tti.yml:112 · MEDIUM — Inconsistent security rule baseline
The change updates a security rule in the local .forgejo/semgrep-rules/tti.yml file but does not update the agency-wide canonical source at tti/coding-standards/.forgejo/semgrep-rules/tti.yml. This violates the seeding and audit pattern, meaning the fix won't propagate to other repos during the next audit cycle.

Fix: Apply the same regex change ('(?<!X-Amz-Credential=)AKIA[0-9A-Z]{16}') to the canonical source file in the tti/coding-standards repository.

_{panel tally 4/4 · reply here or use the finding board to agree/disagree}

**`.forgejo/semgrep-rules/tti.yml:112`** · MEDIUM — Inconsistent security rule baseline The change updates a security rule in the local `.forgejo/semgrep-rules/tti.yml` file but does not update the agency-wide canonical source at `tti/coding-standards/.forgejo/semgrep-rules/tti.yml`. This violates the seeding and audit pattern, meaning the fix won't propagate to other repos during the next audit cycle. > **Fix:** Apply the same regex change (`'(?<!X-Amz-Credential=)AKIA[0-9A-Z]{16}'`) to the canonical source file in the `tti/coding-standards` repository. panel tally 4/4 · reply here or use the finding board to agree/disagree

A-Guevara added 1 commit

2026-08-18 18:38:44 +00:00

chore(H2): seed baseline security gate

baseline-security / baseline (push) Has been cancelled

Details

scan / trivy-fs (push) Has been cancelled

Details

8047beea45

A-Guevara added 1 commit

2026-08-18 18:38:44 +00:00

chore(H2): seed vendored gitleaks config

scan / trivy-fs (push) Successful in 1m19s

Details

baseline-security / baseline (push) Failing after 1m43s

Details

scan / trivy-fs (pull_request) Successful in 53s

Details

baseline-security / baseline (pull_request) Failing after 1m13s

Details

ai-review / review (pull_request) Successful in 4m14s

Details

dbabf5bb80

ai-review-bot reviewed

2026-08-18 18:42:54 +00:00

ai-review-bot left a comment

AI review · advisory

Verdict: 1 thing worth fixing (1 high).

_{⚑ panel: GPT-OSS 120B · Gemma 4 31B · Devstral 2 123B · Laguna S 2.1 — 4 distinct (from 5 reviewer findings), 1 confirmed, 3 refuted · web: not used · context: 2 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less)}

Panel debate — how this review was reached

Grounding — context: 2 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less)

Round 1 — independent reviews

GPT-OSS 120B (1 finding, confidence 0.93): The changes are generally safe, but editing the seeded baseline workflow file breaches the agency coding standard and should be reverted.
Gemma 4 31B (1 finding, confidence 1.0): The PR introduces a custom gitleaks allowlist and refines a semgrep rule to reduce noise, which are correct in isolation; however, it modifies a seeded workflow file in a way that breaks the agency's
Devstral 2 123B (3 findings, confidence 0.85): The changes introduce security improvements and configuration updates, but there are minor issues with regex patterns and error handling that should be addressed.
Laguna S 2.1 (0 findings):

Grouping — 5 reviewer findings describe 4 distinct defects; reviewers who found the same defect independently count as support.

Round 2 — cross-examination

GPT-OSS 120B#1 Modification of seeded baseline workflow violates agency standard · also raised by: Gemma 4 31B · confirmed: Laguna S 2.1 · refuted: Devstral 2 123B
Devstral 2 123B#1 Regex pattern may allow unintended matches · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B, Laguna S 2.1
Devstral 2 123B#2 Negative lookbehind may not be supported in all regex engines · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B, Laguna S 2.1
Devstral 2 123B#3 Missing error handling for gitleaks command · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B, Laguna S 2.1

Raised but refuted (left out of the review above)

Devstral 2 123B#1 Regex pattern may allow unintended matches — The regex ^WPA[0-9]?-(Enterprise|Personal|PSK)$ only allows an optional single digit after WPA. It will match WPA, WPA2, WPA3 but will not m
Devstral 2 123B#2 Negative lookbehind may not be supported in all regex engines — Semgrep uses a regex engine that supports lookbehinds, including negative lookbehinds. The pattern (?<!X-Amz-Credential=)AKIA[0-9A-Z]{16} is therefo
Devstral 2 123B#3 Missing error handling for gitleaks command — The gitleaks step already checks the command's exit status with if ! ...; then and provides explicit error messages in the block that follows. This

Synthesis — Devstral 2 123B wrote the final review from 1 confirmed finding.

_{Transcript rv-20260818184002-04b14d — full round outputs, web results, and model reasoning are viewable by anyone with access to this repository via the AI gateway.}

_{Advisory — never a merge gate. Disagree with a finding? Reply on it, or use the finding board under this review. Transcript rv-20260818184002-04b14d.}

### AI review · advisory  **Verdict: 1 thing worth fixing** (1 high). ⚑ panel: GPT-OSS 120B · Gemma 4 31B · Devstral 2 123B · Laguna S 2.1 — 4 distinct (from 5 reviewer findings), 1 confirmed, 3 refuted · web: not used · context: 2 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less) <details> <summary>Panel debate — how this review was reached</summary> **Grounding** — context: 2 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less) **Round 1 — independent reviews** - **GPT-OSS 120B** (1 finding, confidence 0.93): The changes are generally safe, but editing the seeded baseline workflow file breaches the agency coding standard and should be reverted. - **Gemma 4 31B** (1 finding, confidence 1.0): The PR introduces a custom gitleaks allowlist and refines a semgrep rule to reduce noise, which are correct in isolation; however, it modifies a seeded workflow file in a way that breaks the agency's - **Devstral 2 123B** (3 findings, confidence 0.85): The changes introduce security improvements and configuration updates, but there are minor issues with regex patterns and error handling that should be addressed. - **Laguna S 2.1** (0 findings): **Grouping** — 5 reviewer findings describe 4 distinct defects; reviewers who found the same defect independently count as support. **Round 2 — cross-examination** - `GPT-OSS 120B#1` Modification of seeded baseline workflow violates agency standard · also raised by: Gemma 4 31B · confirmed: Laguna S 2.1 · refuted: Devstral 2 123B - `Devstral 2 123B#1` Regex pattern may allow unintended matches · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B, Laguna S 2.1 - `Devstral 2 123B#2` Negative lookbehind may not be supported in all regex engines · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B, Laguna S 2.1 - `Devstral 2 123B#3` Missing error handling for gitleaks command · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B, Laguna S 2.1 **Raised but refuted** (left out of the review above) - `Devstral 2 123B#1` Regex pattern may allow unintended matches — The regex `^WPA[0-9]?-(Enterprise|Personal|PSK)$` only allows an optional single digit after `WPA`. It will match `WPA`, `WPA2`, `WPA3` but will not m - `Devstral 2 123B#2` Negative lookbehind may not be supported in all regex engines — Semgrep uses a regex engine that supports lookbehinds, including negative lookbehinds. The pattern `(?<!X-Amz-Credential=)AKIA[0-9A-Z]{16}` is therefo - `Devstral 2 123B#3` Missing error handling for gitleaks command — The gitleaks step already checks the command's exit status with `if ! ...; then` and provides explicit error messages in the block that follows. This **Synthesis** — Devstral 2 123B wrote the final review from 1 confirmed finding. Transcript `rv-20260818184002-04b14d` — full round outputs, web results, and model reasoning are viewable by anyone with access to this repository via the AI gateway. </details> Advisory — never a merge gate. Disagree with a finding? Reply on it, or use the finding board under this review. Transcript `rv-20260818184002-04b14d`.

.forgejo/workflows/baseline.yml

					
				@ -284,2 +284,3 @@

				        run: |

				          if ! "$HOME/.local/bin/gitleaks" detect --no-banner --redact --verbose --exit-code 1; then

				          set -eu

				          # Prefer the SEEDED org config, same precedence rule as the semgrep

.forgejo/workflows/baseline.yml:286 · HIGH — Modification of seeded baseline workflow violates agency standard
The PR directly edits the seeded baseline workflow file, which is against the coding standards. Changes should only be made in the canonical source and then reseeded, not modified in repo copies.

Fix: Revert the changes to .forgejo/workflows/baseline.yml and restore the original single gitleaks invocation line, keeping the seeded workflow unchanged.

Proposed replacement (one-click ⚡ Apply on the findings board at the top of this PR):

if ! "$HOME/.local/bin/gitleaks" detect --no-banner --redact --verbose --exit-code 1; then

_{panel tally 3/4 · reply here or use the finding board to agree/disagree}

**`.forgejo/workflows/baseline.yml:286`** · HIGH — Modification of seeded baseline workflow violates agency standard The PR directly edits the seeded baseline workflow file, which is against the coding standards. Changes should only be made in the canonical source and then reseeded, not modified in repo copies. > **Fix:** Revert the changes to `.forgejo/workflows/baseline.yml` and restore the original single `gitleaks` invocation line, keeping the seeded workflow unchanged. **Proposed replacement** (one-click ⚡ Apply on the findings board at the top of this PR): ``` if ! "$HOME/.local/bin/gitleaks" detect --no-banner --redact --verbose --exit-code 1; then ``` panel tally 3/4 · reply here or use the finding board to agree/disagree

A-Guevara added 1 commit

2026-08-18 19:00:55 +00:00

chore(H2): seed baseline security gate

baseline-security / baseline (push) Failing after 0s

Details

baseline-security / baseline (pull_request) Failing after 0s

Details

scan / trivy-fs (push) Successful in 54s

Details

scan / trivy-fs (pull_request) Successful in 52s

Details

ai-review / review (pull_request) Successful in 4m33s

Details

8755535181

ai-review-bot reviewed

2026-08-18 19:07:25 +00:00

ai-review-bot left a comment

AI review · advisory

Verdict: 4 things worth fixing (1 high · 2 medium · 1 low).

Findings that didn't map to a diff line:

.forgejo/workflows/baseline.yml:314 · LOW — Advisory message points to wrong allowlist file path
The error message for non‑credential findings advises adding an allowlist entry to "security/gitleaks/gitleaks.toml", but the repository’s allowlist file is actually ".forgejo/gitleaks.toml".

Fix: Update the advisory echo to reference the correct allowlist file path.

.forgejo/workflows/baseline.yml:451 · LOW — Inconsistent error message formatting
The error message for workflow YAML parsing does not follow the same format as other error messages in the workflow.

Fix: Standardize the error message format to match other error messages in the workflow.

_{⚑ panel: GPT-OSS 120B · Gemma 4 31B · Devstral 2 123B · Laguna S 2.1 — 7 distinct, 4 confirmed, 1 refuted · web: not used · context: 2 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less)}

Panel debate — how this review was reached

Grounding — context: 2 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less)

Round 1 — independent reviews

GPT-OSS 120B (3 findings, confidence 0.93): The changes introduce a few functional inconsistencies: an unsupported regex in the Semgrep rule, a new gitleaks config that supersedes the existing root config (potentially hiding allowlist entries),
Gemma 4 31B (1 finding, confidence 0.95): The PR implements a security baseline gate with reasonable configurations for gitleaks and semgrep; only a minor inconsistency in configuration file precedence was noted.
Devstral 2 123B (3 findings, confidence 0.85): The changes introduce a baseline security gate with gitleaks and semgrep configurations, along with workflow enhancements. The findings are minor and primarily related to consistency and completeness.
Laguna S 2.1 (0 findings):

Round 2 — cross-examination

GPT-OSS 120B#1 Negative lookbehind may not be supported by Semgrep · confirmed: Devstral 2 123B · refuted: Gemma 4 31B
Gemma 4 31B#1 Fragile gitleaks configuration discovery · confirmed: GPT-OSS 120B · refuted: Devstral 2 123B, Laguna S 2.1
GPT-OSS 120B#2 Root .gitleaks.toml is ignored by the new config selection logic · confirmed: Gemma 4 31B, Devstral 2 123B, Laguna S 2.1 · refuted: —
Devstral 2 123B#1 Incomplete AWS access key ID pattern · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B, Laguna S 2.1
GPT-OSS 120B#3 Advisory message points to wrong allowlist file path · confirmed: Gemma 4 31B, Devstral 2 123B, Laguna S 2.1 · refuted: —
Devstral 2 123B#3 Inconsistent error message formatting · confirmed: — · refuted: Gemma 4 31B, Laguna S 2.1
Devstral 2 123B#2 Inconsistent error message formatting · confirmed: — · refuted: Gemma 4 31B, Laguna S 2.1

Raised but refuted (left out of the review above)

Devstral 2 123B#1 Incomplete AWS access key ID pattern — The semgrep rule now uses a negative look‑behind: pattern-regex: '(?<!X-Amz-Credential=)AKIA[0-9A-Z]{16}', which explicitly excludes the `X-Amz-Cred

Synthesis — Devstral 2 123B wrote the final review from 4 confirmed findings (+2 unconfirmed).

_{Transcript rv-20260818190353-1189ec — full round outputs, web results, and model reasoning are viewable by anyone with access to this repository via the AI gateway.}

_{Advisory — never a merge gate. Disagree with a finding? Reply on it, or use the finding board under this review. Transcript rv-20260818190353-1189ec.}

### AI review · advisory  **Verdict: 4 things worth fixing** (1 high · 2 medium · 1 low). Findings that didn't map to a diff line: **`.forgejo/workflows/baseline.yml:314`** · LOW — Advisory message points to wrong allowlist file path The error message for non‑credential findings advises adding an allowlist entry to "security/gitleaks/gitleaks.toml", but the repository’s allowlist file is actually ".forgejo/gitleaks.toml". > **Fix:** Update the advisory echo to reference the correct allowlist file path. **`.forgejo/workflows/baseline.yml:451`** · LOW — Inconsistent error message formatting The error message for workflow YAML parsing does not follow the same format as other error messages in the workflow. > **Fix:** Standardize the error message format to match other error messages in the workflow. ⚑ panel: GPT-OSS 120B · Gemma 4 31B · Devstral 2 123B · Laguna S 2.1 — 7 distinct, 4 confirmed, 1 refuted · web: not used · context: 2 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less) <details> <summary>Panel debate — how this review was reached</summary> **Grounding** — context: 2 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less) **Round 1 — independent reviews** - **GPT-OSS 120B** (3 findings, confidence 0.93): The changes introduce a few functional inconsistencies: an unsupported regex in the Semgrep rule, a new gitleaks config that supersedes the existing root config (potentially hiding allowlist entries), - **Gemma 4 31B** (1 finding, confidence 0.95): The PR implements a security baseline gate with reasonable configurations for gitleaks and semgrep; only a minor inconsistency in configuration file precedence was noted. - **Devstral 2 123B** (3 findings, confidence 0.85): The changes introduce a baseline security gate with gitleaks and semgrep configurations, along with workflow enhancements. The findings are minor and primarily related to consistency and completeness. - **Laguna S 2.1** (0 findings): **Round 2 — cross-examination** - `GPT-OSS 120B#1` Negative lookbehind may not be supported by Semgrep · confirmed: Devstral 2 123B · refuted: Gemma 4 31B - `Gemma 4 31B#1` Fragile gitleaks configuration discovery · confirmed: GPT-OSS 120B · refuted: Devstral 2 123B, Laguna S 2.1 - `GPT-OSS 120B#2` Root .gitleaks.toml is ignored by the new config selection logic · confirmed: Gemma 4 31B, Devstral 2 123B, Laguna S 2.1 · refuted: — - `Devstral 2 123B#1` Incomplete AWS access key ID pattern · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B, Laguna S 2.1 - `GPT-OSS 120B#3` Advisory message points to wrong allowlist file path · confirmed: Gemma 4 31B, Devstral 2 123B, Laguna S 2.1 · refuted: — - `Devstral 2 123B#3` Inconsistent error message formatting · confirmed: — · refuted: Gemma 4 31B, Laguna S 2.1 - `Devstral 2 123B#2` Inconsistent error message formatting · confirmed: — · refuted: Gemma 4 31B, Laguna S 2.1 **Raised but refuted** (left out of the review above) - `Devstral 2 123B#1` Incomplete AWS access key ID pattern — The semgrep rule now uses a negative look‑behind: `pattern-regex: '(?<!X-Amz-Credential=)AKIA[0-9A-Z]{16}'`, which explicitly excludes the `X-Amz-Cred **Synthesis** — Devstral 2 123B wrote the final review from 4 confirmed findings (+2 unconfirmed). Transcript `rv-20260818190353-1189ec` — full round outputs, web results, and model reasoning are viewable by anyone with access to this repository via the AI gateway. </details> Advisory — never a merge gate. Disagree with a finding? Reply on it, or use the finding board under this review. Transcript `rv-20260818190353-1189ec`.

.forgejo/semgrep-rules/tti.yml

					
				@ -93,4 +93,22 @@ rules:

				        - "**/*.md"

				        - "**/ops/provenance/**"

.forgejo/semgrep-rules/tti.yml:94 · HIGH — Negative lookbehind may not be supported by Semgrep
The regex pattern uses a negative lookbehind (?<!X-Amz-Credential=), which Semgrep’s regex engine does not support. This can cause the rule to be silently ignored or to fail at runtime.

Fix: Replace the lookbehind with a separate negation rule using pattern-not, which Semgrep supports.

Proposed replacement (one-click ⚡ Apply on the findings board at the top of this PR):

pattern-regex: 'AKIA[0-9A-Z]{16}'
pattern-not: 'X-Amz-Credential=AKIA[0-9A-Z]{16}'

_{panel tally 2/4 · reply here or use the finding board to agree/disagree}

**`.forgejo/semgrep-rules/tti.yml:94`** · HIGH — Negative lookbehind may not be supported by Semgrep The regex pattern uses a negative lookbehind `(?<!X-Amz-Credential=)`, which Semgrep’s regex engine does not support. This can cause the rule to be silently ignored or to fail at runtime. > **Fix:** Replace the lookbehind with a separate negation rule using `pattern-not`, which Semgrep supports. **Proposed replacement** (one-click ⚡ Apply on the findings board at the top of this PR): ``` pattern-regex: 'AKIA[0-9A-Z]{16}' pattern-not: 'X-Amz-Credential=AKIA[0-9A-Z]{16}' ``` panel tally 2/4 · reply here or use the finding board to agree/disagree

.forgejo/workflows/baseline.yml

					
				@ -283,3 +283,3 @@

				      - name: Secrets — gitleaks (tree scan, redacted findings)

				        run: |

				          if ! "$HOME/.local/bin/gitleaks" detect --no-banner --redact --verbose --exit-code 1; then

				          set -eu

.forgejo/workflows/baseline.yml:285 · MEDIUM — Fragile gitleaks configuration discovery
The script checks for .forgejo/gitleaks.toml first, but the standard organizational pattern expects security/gitleaks/gitleaks.toml to be the primary location.

Fix: Swap the order of the file existence checks to prefer security/gitleaks/gitleaks.toml first.

Proposed replacement (one-click ⚡ Apply on the findings board at the top of this PR):

          if [ -f security/gitleaks/gitleaks.toml ]; then
            GL_CFG="security/gitleaks/gitleaks.toml"
          elif [ -f .forgejo/gitleaks.toml ]; then
            GL_CFG=".forgejo/gitleaks.toml"

_{panel tally 2/4 · reply here or use the finding board to agree/disagree}

**`.forgejo/workflows/baseline.yml:285`** · MEDIUM — Fragile gitleaks configuration discovery The script checks for `.forgejo/gitleaks.toml` first, but the standard organizational pattern expects `security/gitleaks/gitleaks.toml` to be the primary location. > **Fix:** Swap the order of the file existence checks to prefer `security/gitleaks/gitleaks.toml` first. **Proposed replacement** (one-click ⚡ Apply on the findings board at the top of this PR): ``` if [ -f security/gitleaks/gitleaks.toml ]; then GL_CFG="security/gitleaks/gitleaks.toml" elif [ -f .forgejo/gitleaks.toml ]; then GL_CFG=".forgejo/gitleaks.toml" ``` panel tally 2/4 · reply here or use the finding board to agree/disagree

.forgejo/workflows/baseline.yml

					
				@ -284,2 +284,3 @@

				        run: |

				          if ! "$HOME/.local/bin/gitleaks" detect --no-banner --redact --verbose --exit-code 1; then

				          set -eu

				          # Prefer the SEEDED org config, same precedence rule as the semgrep

.forgejo/workflows/baseline.yml:286 · MEDIUM — Root .gitleaks.toml is ignored by the new config selection logic
The script now prefers .forgejo/gitleaks.toml over the root .gitleaks.toml, so any allowlist entries in the root file will never be applied.

Fix: Either remove the duplicate root .gitleaks.toml or merge its contents into the selected config file.

Proposed replacement (one-click ⚡ Apply on the findings board at the top of this PR):

# Remove or rename the root .gitleaks.toml to avoid duplication
# Or, after selecting GL_CFG, source the root config as well if it exists:
if [ -f .gitleaks.toml ]; then
  echo "Merging root .gitleaks.toml into $GL_CFG"
  cat .gitleaks.toml >> "$GL_CFG"
fi

_{panel tally 4/4 · reply here or use the finding board to agree/disagree}

**`.forgejo/workflows/baseline.yml:286`** · MEDIUM — Root .gitleaks.toml is ignored by the new config selection logic The script now prefers `.forgejo/gitleaks.toml` over the root `.gitleaks.toml`, so any allowlist entries in the root file will never be applied. > **Fix:** Either remove the duplicate root `.gitleaks.toml` or merge its contents into the selected config file. **Proposed replacement** (one-click ⚡ Apply on the findings board at the top of this PR): ``` # Remove or rename the root .gitleaks.toml to avoid duplication # Or, after selecting GL_CFG, source the root config as well if it exists: if [ -f .gitleaks.toml ]; then echo "Merging root .gitleaks.toml into $GL_CFG" cat .gitleaks.toml >> "$GL_CFG" fi ``` panel tally 4/4 · reply here or use the finding board to agree/disagree

.forgejo/workflows/baseline.yml

					
				@ -286,0 +298,4 @@

				          elif [ -f security/gitleaks/gitleaks.toml ]; then

				            GL_CFG="security/gitleaks/gitleaks.toml"

				          fi

				          if [ -n "$GL_CFG" ]; then

LOW — Inconsistent error message formatting

The error message for undefined names or unparseable files does not follow the same format as other error messages in the workflow.

Fix: Standardize the error message format to match other error messages in the workflow.

Proposed replacement (one-click ⚡ Apply on the findings board at the top of this PR):

echo "FAIL: undefined name or unparseable file above."

_{panel tally 1/4 · reply here or use the finding board to agree/disagree}

**LOW** — Inconsistent error message formatting The error message for undefined names or unparseable files does not follow the same format as other error messages in the workflow. > **Fix:** Standardize the error message format to match other error messages in the workflow. **Proposed replacement** (one-click ⚡ Apply on the findings board at the top of this PR): ``` echo "FAIL: undefined name or unparseable file above." ``` panel tally 1/4 · reply here or use the finding board to agree/disagree

A-Guevara added 1 commit

2026-08-18 19:30:06 +00:00

chore(H2): seed baseline security gate

scan / trivy-fs (push) Successful in 1m14s

Details

baseline-security / baseline (push) Failing after 1m42s

Details

scan / trivy-fs (pull_request) Successful in 44s

Details

baseline-security / baseline (pull_request) Failing after 1m5s

Details

ai-review / review (pull_request) Successful in 3m54s

Details

c7fb78392e

ai-review-bot reviewed

2026-08-18 19:33:59 +00:00

ai-review-bot left a comment

AI review · advisory

Verdict: 3 things worth fixing (1 medium · 2 low).

_{⚑ panel: GPT-OSS 120B · Gemma 4 31B · Devstral 2 123B · Laguna S 2.1 — 5 distinct, 3 confirmed, 0 refuted · web: not used · context: 2 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less)}

Panel debate — how this review was reached

Grounding — context: 2 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less)

Round 1 — independent reviews

GPT-OSS 120B (0 findings, confidence 0.92): The changes appear correct and introduce no obvious bugs or security regressions.
Gemma 4 31B (2 findings, confidence 0.95): The PR implements a robust security baseline gate including secret scanning, SAST, and workflow validation; however, there is a minor file handle leak in the Python validation script.
Devstral 2 123B (3 findings, confidence 0.85): The changes introduce a baseline security gate with gitleaks and semgrep configurations, along with workflow enhancements. While the changes are generally well-implemented, there are a few areas that
Laguna S 2.1 (0 findings):

Round 2 — cross-examination

Gemma 4 31B#1 Potential resource leak in Python loop · confirmed: GPT-OSS 120B, Devstral 2 123B, Laguna S 2.1 · refuted: —
Devstral 2 123B#1 Incomplete AWS access key ID pattern · confirmed: — · refuted: Gemma 4 31B, Laguna S 2.1
Devstral 2 123B#3 Potential false positives in expression marker detection · confirmed: — · refuted: Gemma 4 31B, Laguna S 2.1
Gemma 4 31B#2 Inefficient string search in loop · confirmed: Devstral 2 123B · refuted: Laguna S 2.1
Devstral 2 123B#2 Hardcoded runner labels · confirmed: GPT-OSS 120B · refuted: Gemma 4 31B, Laguna S 2.1

Synthesis — Devstral 2 123B wrote the final review from 3 confirmed findings (+2 unconfirmed).

_{Transcript rv-20260818193113-119597 — full round outputs, web results, and model reasoning are viewable by anyone with access to this repository via the AI gateway.}

_{Advisory — never a merge gate. Disagree with a finding? Reply on it, or use the finding board under this review. Transcript rv-20260818193113-119597.}

### AI review · advisory  **Verdict: 3 things worth fixing** (1 medium · 2 low). ⚑ panel: GPT-OSS 120B · Gemma 4 31B · Devstral 2 123B · Laguna S 2.1 — 5 distinct, 3 confirmed, 0 refuted · web: not used · context: 2 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less) <details> <summary>Panel debate — how this review was reached</summary> **Grounding** — context: 2 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less) **Round 1 — independent reviews** - **GPT-OSS 120B** (0 findings, confidence 0.92): The changes appear correct and introduce no obvious bugs or security regressions. - **Gemma 4 31B** (2 findings, confidence 0.95): The PR implements a robust security baseline gate including secret scanning, SAST, and workflow validation; however, there is a minor file handle leak in the Python validation script. - **Devstral 2 123B** (3 findings, confidence 0.85): The changes introduce a baseline security gate with gitleaks and semgrep configurations, along with workflow enhancements. While the changes are generally well-implemented, there are a few areas that - **Laguna S 2.1** (0 findings): **Round 2 — cross-examination** - `Gemma 4 31B#1` Potential resource leak in Python loop · confirmed: GPT-OSS 120B, Devstral 2 123B, Laguna S 2.1 · refuted: — - `Devstral 2 123B#1` Incomplete AWS access key ID pattern · confirmed: — · refuted: Gemma 4 31B, Laguna S 2.1 - `Devstral 2 123B#3` Potential false positives in expression marker detection · confirmed: — · refuted: Gemma 4 31B, Laguna S 2.1 - `Gemma 4 31B#2` Inefficient string search in loop · confirmed: Devstral 2 123B · refuted: Laguna S 2.1 - `Devstral 2 123B#2` Hardcoded runner labels · confirmed: GPT-OSS 120B · refuted: Gemma 4 31B, Laguna S 2.1 **Synthesis** — Devstral 2 123B wrote the final review from 3 confirmed findings (+2 unconfirmed). Transcript `rv-20260818193113-119597` — full round outputs, web results, and model reasoning are viewable by anyone with access to this repository via the AI gateway. </details> Advisory — never a merge gate. Disagree with a finding? Reply on it, or use the finding board under this review. Transcript `rv-20260818193113-119597`.

.forgejo/semgrep-rules/tti.yml

					
				@ -94,3 +94,3 @@

				        - "**/ops/provenance/**"

				        - "**/.security-ignore*"

				    pattern-regex: 'AKIA[0-9A-Z]{16}'

				    # The negative lookbehind drops key ids that appear as the AWS SigV4

MEDIUM — Incomplete AWS access key ID pattern

The regex pattern for AWS access key IDs does not exclude known test/placeholder keys, which can lead to false positives and unnecessary noise in security scans.

Fix: Update the regex pattern to exclude known test/placeholder keys by adding a negative lookahead for common patterns like 'EXAMPLE', 'NOTREAL', or 'TEST'.

Proposed replacement (one-click ⚡ Apply on the findings board at the top of this PR):

pattern-regex: '(?<!EXAMPLE|NOTREAL|TEST)AKIA[0-9A-Z]{16}'

_{panel tally 1/4 · reply here or use the finding board to agree/disagree}

**MEDIUM** — Incomplete AWS access key ID pattern The regex pattern for AWS access key IDs does not exclude known test/placeholder keys, which can lead to false positives and unnecessary noise in security scans. > **Fix:** Update the regex pattern to exclude known test/placeholder keys by adding a negative lookahead for common patterns like 'EXAMPLE', 'NOTREAL', or 'TEST'. **Proposed replacement** (one-click ⚡ Apply on the findings board at the top of this PR): ``` pattern-regex: '(?<!EXAMPLE|NOTREAL|TEST)AKIA[0-9A-Z]{16}' ``` panel tally 1/4 · reply here or use the finding board to agree/disagree

.forgejo/workflows/baseline.yml

					
				@ -286,0 +298,4 @@

				          elif [ -f security/gitleaks/gitleaks.toml ]; then

				            GL_CFG="security/gitleaks/gitleaks.toml"

				          fi

				          if [ -n "$GL_CFG" ]; then

.forgejo/workflows/baseline.yml:301 · LOW — Hardcoded runner labels may become outdated
The list of known runner labels is hardcoded, so it won’t update when new runners are added, leading to incorrect advisory notes.

Fix: Fetch the list dynamically from the Forgejo API or a configuration file.

_{panel tally 2/4 · reply here or use the finding board to agree/disagree}

**`.forgejo/workflows/baseline.yml:301`** · LOW — Hardcoded runner labels may become outdated The list of known runner labels is hardcoded, so it won’t update when new runners are added, leading to incorrect advisory notes. > **Fix:** Fetch the list dynamically from the Forgejo API or a configuration file. panel tally 2/4 · reply here or use the finding board to agree/disagree

.forgejo/workflows/baseline.yml

					
				@ -294,2 +317,4 @@

				            echo " * Commit-pinned .security-ignore fingerprints cannot match here (the"

				            echo "   shallow commit changes every push) — fix the content instead."

				            echo " * A finding that is NOT a credential (a protocol name, a fixture"

				            echo "   constant): it belongs in security/gitleaks/gitleaks.toml as an"

MEDIUM — Potential false positives in expression marker detection

The expression marker detection logic may produce false positives by matching legitimate uses of the expression marker pattern in comments or strings.

Fix: Enhance the detection logic to exclude matches within comments or strings to reduce false positives.

_{panel tally 1/4 · reply here or use the finding board to agree/disagree}

**MEDIUM** — Potential false positives in expression marker detection The expression marker detection logic may produce false positives by matching legitimate uses of the expression marker pattern in comments or strings. > **Fix:** Enhance the detection logic to exclude matches within comments or strings to reduce false positives. panel tally 1/4 · reply here or use the finding board to agree/disagree

.forgejo/workflows/baseline.yml

					
				@ -408,18 +435,97 @@ jobs:

				              print("files that do not. Add python3-yaml to the runner image.")

.forgejo/workflows/baseline.yml:435 · MEDIUM — File handles not closed in loop
The code opens files with open(path) but never closes them, which can exhaust file descriptors in large repositories and crash the program.

Fix: Wrap the file operation in a with open(path) as f: context manager to guarantee the file is closed.

Proposed replacement (one-click ⚡ Apply on the findings board at the top of this PR):

              with open(path, encoding="utf-8") as f:
                  for n, line in enumerate(f.read().split("\n"), 1):

_{panel tally 4/4 · reply here or use the finding board to agree/disagree}

**`.forgejo/workflows/baseline.yml:435`** · MEDIUM — File handles not closed in loop The code opens files with `open(path)` but never closes them, which can exhaust file descriptors in large repositories and crash the program. > **Fix:** Wrap the file operation in a `with open(path) as f:` context manager to guarantee the file is closed. **Proposed replacement** (one-click ⚡ Apply on the findings board at the top of this PR): ``` with open(path, encoding="utf-8") as f: for n, line in enumerate(f.read().split("\n"), 1): ``` panel tally 4/4 · reply here or use the finding board to agree/disagree

.forgejo/workflows/baseline.yml

					
				@ -411,0 +442,4 @@

				          # changes -- ops/ci-triage.sh computes the live set from

				          # action_runner.last_online and is the authority.

				          KNOWN_LABELS = {"ubuntu-latest", "ubuntu-24.04", "spark-arm64"}

.forgejo/workflows/baseline.yml:445 · LOW — Inefficient string search for expression markers
The loop uses repeated line.find calls to locate markers, which is slower and less readable than using a regular expression.

Fix: Replace the manual find loop with the re module to identify unterminated markers.

_{panel tally 2/4 · reply here or use the finding board to agree/disagree}

**`.forgejo/workflows/baseline.yml:445`** · LOW — Inefficient string search for expression markers The loop uses repeated `line.find` calls to locate markers, which is slower and less readable than using a regular expression. > **Fix:** Replace the manual `find` loop with the `re` module to identify unterminated markers. panel tally 2/4 · reply here or use the finding board to agree/disagree

A-Guevara added 1 commit

2026-08-18 19:50:35 +00:00

chore(H2): seed vendored gitleaks config

baseline-security / baseline (push) Successful in 2m26s

Details

scan / trivy-fs (push) Successful in 1m28s

Details

baseline-security / baseline (pull_request) Successful in 1m47s

Details

ai-review / review (pull_request) Successful in 3m39s

Details

scan / trivy-fs (pull_request) Successful in 55s

Details

ce4b7d617b

ai-review-bot reviewed

2026-08-18 20:04:55 +00:00

ai-review-bot left a comment

AI review · advisory

Verdict: 3 things worth fixing (2 medium · 1 low).

Findings that didn't map to a diff line:

.forgejo/workflows/baseline.yml:335 · MEDIUM — Possible Workflow Expression Injection in Python script
The Python script in the 'Workflow YAML parses' step uses open(f, encoding="utf-8").read() to process workflow files, but the logic attempting to prevent Forgejo expression markers (${{) through concatenation (EXPR_OPEN = "$" + "{" + "{") only applies to the detection and printing logic, not the actual parsing. While yaml.safe_load is used, if this script were modified to execute or interpolate these values, it would be vulnerable. More critically, the manual check for EXPR_OPEN in expr_defects is meant to find defects, but the logic if line.find(EXPR_CLOSE, i + len(EXPR_OPEN)) == -1 only checks if the marker is closed on the same line. Forgejo lexes these across the RAW file, meaning a marker opened on one line and closed on another is valid, but this script will flag it as a FAIL, causing false positives for multi-line expressions.

Fix: Change the expression defect check to operate on the full file content instead of line-by-line to correctly support multi-line expression markers.

.forgejo/workflows/baseline.yml:408 · MEDIUM — Inconsistent error handling in workflow YAML parsing
The workflow YAML parsing step does not handle the case where the YAML parser is missing, which could lead to silent failures.

Fix: Ensure the YAML parser is installed as part of the workflow setup to prevent silent failures.

_{⚑ panel: GPT-OSS 120B · Gemma 4 31B · Devstral 2 123B · Laguna S 2.1 — 7 distinct, 3 confirmed, 0 refuted · web: not used · context: 2 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less)}

Panel debate — how this review was reached

Grounding — context: 2 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less)

Round 1 — independent reviews

GPT-OSS 120B (0 findings, confidence 0.97): No issues detected in the changed lines; the added security configurations and workflow adjustments appear correct.
Gemma 4 31B (1 finding, confidence 0.9): The PR implements a security baseline gate with gitleaks and semgrep, and adds a Python-based YAML validator to prevent silent workflow failures in Forgejo. The logic for detecting unterminated expres
Devstral 2 123B (4 findings, confidence 0.85): The pull request introduces several security and configuration improvements, but there are inconsistencies and potential issues that need to be addressed.
Laguna S 2.1 (4 findings, confidence 0.85): PR introduces the H2 baseline security gate for tti/tti-ux: a gitleaks allowlist (.forgejo/gitleaks.toml), a semgrep rule refinement (.forgejo/semgrep-rules/tti.yml) for presigned-URL AWS key ids, and

Round 2 — cross-examination

Gemma 4 31B#1 Possible Workflow Expression Injection in Python script · confirmed: Devstral 2 123B · refuted: —
Devstral 2 123B#4 Inconsistent error handling in workflow YAML parsing · confirmed: — · refuted: Gemma 4 31B
Devstral 2 123B#3 Inconsistent error handling in gitleaks step · confirmed: — · refuted: Gemma 4 31B
Laguna S 2.1#1 Allowlist regex suppresses real AWS key ids in X-Amz-Credential= parameter · confirmed: Gemma 4 31B · refuted: Devstral 2 123B
Devstral 2 123B#1 Missing header comment for gitleaks configuration · confirmed: — · refuted: Gemma 4 31B
Devstral 2 123B#2 Inconsistent pattern in semgrep rule · confirmed: — · refuted: Gemma 4 31B
Laguna S 2.1#2 gitleaks --config precedence vs repo-root .gitleaks.toml auto-discovery · confirmed: Gemma 4 31B, Devstral 2 123B · refuted: —

Synthesis — Devstral 2 123B wrote the final review from 3 confirmed findings (+4 unconfirmed).

_{Transcript rv-20260818200235-df4aad — full round outputs, web results, and model reasoning are viewable by anyone with access to this repository via the AI gateway.}

_{Advisory — never a merge gate. Disagree with a finding? Reply on it, or use the finding board under this review. Transcript rv-20260818200235-df4aad.}

### AI review · advisory  **Verdict: 3 things worth fixing** (2 medium · 1 low). Findings that didn't map to a diff line: **`.forgejo/workflows/baseline.yml:335`** · MEDIUM — Possible Workflow Expression Injection in Python script The Python script in the 'Workflow YAML parses' step uses `open(f, encoding="utf-8").read()` to process workflow files, but the logic attempting to prevent Forgejo expression markers (`${{`) through concatenation (`EXPR_OPEN = "$" + "{" + "{"`) only applies to the *detection* and *printing* logic, not the actual parsing. While `yaml.safe_load` is used, if this script were modified to execute or interpolate these values, it would be vulnerable. More critically, the manual check for `EXPR_OPEN` in `expr_defects` is meant to find defects, but the logic `if line.find(EXPR_CLOSE, i + len(EXPR_OPEN)) == -1` only checks if the marker is closed on the *same line*. Forgejo lexes these across the RAW file, meaning a marker opened on one line and closed on another is valid, but this script will flag it as a FAIL, causing false positives for multi-line expressions. > **Fix:** Change the expression defect check to operate on the full file content instead of line-by-line to correctly support multi-line expression markers. **`.forgejo/workflows/baseline.yml:408`** · MEDIUM — Inconsistent error handling in workflow YAML parsing The workflow YAML parsing step does not handle the case where the YAML parser is missing, which could lead to silent failures. > **Fix:** Ensure the YAML parser is installed as part of the workflow setup to prevent silent failures. ⚑ panel: GPT-OSS 120B · Gemma 4 31B · Devstral 2 123B · Laguna S 2.1 — 7 distinct, 3 confirmed, 0 refuted · web: not used · context: 2 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less) <details> <summary>Panel debate — how this review was reached</summary> **Grounding** — context: 2 files · 90 codebase · 14 standards chunks (best-grounded: GPT-OSS 120B; smaller windows saw less) **Round 1 — independent reviews** - **GPT-OSS 120B** (0 findings, confidence 0.97): No issues detected in the changed lines; the added security configurations and workflow adjustments appear correct. - **Gemma 4 31B** (1 finding, confidence 0.9): The PR implements a security baseline gate with gitleaks and semgrep, and adds a Python-based YAML validator to prevent silent workflow failures in Forgejo. The logic for detecting unterminated expres - **Devstral 2 123B** (4 findings, confidence 0.85): The pull request introduces several security and configuration improvements, but there are inconsistencies and potential issues that need to be addressed. - **Laguna S 2.1** (4 findings, confidence 0.85): PR introduces the H2 baseline security gate for tti/tti-ux: a gitleaks allowlist (.forgejo/gitleaks.toml), a semgrep rule refinement (.forgejo/semgrep-rules/tti.yml) for presigned-URL AWS key ids, and **Round 2 — cross-examination** - `Gemma 4 31B#1` Possible Workflow Expression Injection in Python script · confirmed: Devstral 2 123B · refuted: — - `Devstral 2 123B#4` Inconsistent error handling in workflow YAML parsing · confirmed: — · refuted: Gemma 4 31B - `Devstral 2 123B#3` Inconsistent error handling in gitleaks step · confirmed: — · refuted: Gemma 4 31B - `Laguna S 2.1#1` Allowlist regex suppresses real AWS key ids in `X-Amz-Credential=` parameter · confirmed: Gemma 4 31B · refuted: Devstral 2 123B - `Devstral 2 123B#1` Missing header comment for gitleaks configuration · confirmed: — · refuted: Gemma 4 31B - `Devstral 2 123B#2` Inconsistent pattern in semgrep rule · confirmed: — · refuted: Gemma 4 31B - `Laguna S 2.1#2` gitleaks `--config` precedence vs repo-root `.gitleaks.toml` auto-discovery · confirmed: Gemma 4 31B, Devstral 2 123B · refuted: — **Synthesis** — Devstral 2 123B wrote the final review from 3 confirmed findings (+4 unconfirmed). Transcript `rv-20260818200235-df4aad` — full round outputs, web results, and model reasoning are viewable by anyone with access to this repository via the AI gateway. </details> Advisory — never a merge gate. Disagree with a finding? Reply on it, or use the finding board under this review. Transcript `rv-20260818200235-df4aad`.

.forgejo/gitleaks.toml

					
				@ -0,0 +1,67 @@

				# TTI gitleaks configuration for the H2 baseline gate.

MEDIUM — Missing header comment for gitleaks configuration

The gitleaks configuration file lacks a header comment explaining its purpose and usage, which is inconsistent with the repository's standard for configuration files.

Fix: Add a comprehensive header comment explaining the file's purpose, usage, and any relevant context.

Proposed replacement (one-click ⚡ Apply on the findings board at the top of this PR):

# TTI gitleaks configuration for the H2 baseline gate.
#
# This file extends the default gitleaks ruleset with an allowlist specific to the TTI repository.
# It is used by the H2 baseline security gate to scan for secrets in the codebase.
#
# Usage: Place this file in the root of the repository as `.gitleaks.toml`.
# The baseline security gate will automatically use this configuration when scanning for secrets.
#
# Note: This file only adds an allowlist; it does not replace or weaken the default ruleset.
# The `useDefault = true` directive ensures that the default ruleset is applied in addition to the allowlist.

[extend]
useDefault = true

_{panel tally 1/4 · reply here or use the finding board to agree/disagree}

**MEDIUM** — Missing header comment for gitleaks configuration The gitleaks configuration file lacks a header comment explaining its purpose and usage, which is inconsistent with the repository's standard for configuration files. > **Fix:** Add a comprehensive header comment explaining the file's purpose, usage, and any relevant context. **Proposed replacement** (one-click ⚡ Apply on the findings board at the top of this PR): ``` # TTI gitleaks configuration for the H2 baseline gate. # # This file extends the default gitleaks ruleset with an allowlist specific to the TTI repository. # It is used by the H2 baseline security gate to scan for secrets in the codebase. # # Usage: Place this file in the root of the repository as `.gitleaks.toml`. # The baseline security gate will automatically use this configuration when scanning for secrets. # # Note: This file only adds an allowlist; it does not replace or weaken the default ruleset. # The `useDefault = true` directive ensures that the default ruleset is applied in addition to the allowlist. [extend] useDefault = true ``` panel tally 1/4 · reply here or use the finding board to agree/disagree

.forgejo/semgrep-rules/tti.yml

					
				@ -93,4 +93,22 @@ rules:

				        - "**/*.md"

.forgejo/semgrep-rules/tti.yml:93 · MEDIUM — Allowlist regex may suppress real AWS key IDs
The regex (?<!X-Amz-Credential=)AKIA[0-9A-Z]{16} only ignores the exact X-Amz-Credential= prefix, but real AWS key IDs could appear elsewhere in presigned URLs or logs, leading to false negatives.

Fix: Remove the lookbehind assertion or expand it to cover all valid AWS credential parameter formats.

_{panel tally 2/4 · reply here or use the finding board to agree/disagree}

**`.forgejo/semgrep-rules/tti.yml:93`** · MEDIUM — Allowlist regex may suppress real AWS key IDs The regex `(?<!X-Amz-Credential=)AKIA[0-9A-Z]{16}` only ignores the exact `X-Amz-Credential=` prefix, but real AWS key IDs could appear elsewhere in presigned URLs or logs, leading to false negatives. > **Fix:** Remove the lookbehind assertion or expand it to cover all valid AWS credential parameter formats. panel tally 2/4 · reply here or use the finding board to agree/disagree

.forgejo/semgrep-rules/tti.yml:93 · MEDIUM — Allowlist regex may suppress real AWS key IDs
The regex (?<!X-Amz-Credential=)AKIA[0-9A-Z]{16} only ignores the exact X-Amz-Credential= prefix, but real AWS key IDs could appear elsewhere in presigned URLs or logs, leading to false negatives.

Fix: Remove the lookbehind assertion or expand it to cover all valid AWS credential parameter formats.

Proposed replacement (one-click ⚡ Apply on the findings board at the top of this PR):

pattern-regex: '(?<!X-Amz-Credential=)AKIA[0-9A-Z]{16}'

_{panel tally 1/4 · reply here or use the finding board to agree/disagree}

**`.forgejo/semgrep-rules/tti.yml:93`** · MEDIUM — Allowlist regex may suppress real AWS key IDs The regex `(?<!X-Amz-Credential=)AKIA[0-9A-Z]{16}` only ignores the exact `X-Amz-Credential=` prefix, but real AWS key IDs could appear elsewhere in presigned URLs or logs, leading to false negatives. > **Fix:** Remove the lookbehind assertion or expand it to cover all valid AWS credential parameter formats. **Proposed replacement** (one-click ⚡ Apply on the findings board at the top of this PR): ``` pattern-regex: '(?<!X-Amz-Credential=)AKIA[0-9A-Z]{16}' ``` panel tally 1/4 · reply here or use the finding board to agree/disagree

.forgejo/workflows/baseline.yml

					
				@ -283,3 +283,3 @@

				      - name: Secrets — gitleaks (tree scan, redacted findings)

				        run: |

				          if ! "$HOME/.local/bin/gitleaks" detect --no-banner --redact --verbose --exit-code 1; then

				          set -eu

MEDIUM — Inconsistent error handling in gitleaks step

The gitleaks step in the baseline workflow does not handle the case where the gitleaks configuration file is missing, which could lead to silent failures.

Fix: Add error handling to check for the presence of the gitleaks configuration file and provide a meaningful error message if it is missing.

Proposed replacement (one-click ⚡ Apply on the findings board at the top of this PR):

if [ ! -f ".forgejo/gitleaks.toml" ]; then
  echo "Error: gitleaks configuration file not found."
  exit 1
fi
if ! "$HOME/.local/bin/gitleaks" detect --no-banner --redact --verbose --exit-code 1; then

_{panel tally 1/4 · reply here or use the finding board to agree/disagree}

**MEDIUM** — Inconsistent error handling in gitleaks step The gitleaks step in the baseline workflow does not handle the case where the gitleaks configuration file is missing, which could lead to silent failures. > **Fix:** Add error handling to check for the presence of the gitleaks configuration file and provide a meaningful error message if it is missing. **Proposed replacement** (one-click ⚡ Apply on the findings board at the top of this PR): ``` if [ ! -f ".forgejo/gitleaks.toml" ]; then echo "Error: gitleaks configuration file not found." exit 1 fi if ! "$HOME/.local/bin/gitleaks" detect --no-banner --redact --verbose --exit-code 1; then ``` panel tally 1/4 · reply here or use the finding board to agree/disagree

.forgejo/workflows/baseline.yml

					
				@ -286,0 +293,4 @@

				          # than skipping the step — a missing allowlist is noise, a skipped

				          # secret scan is a hole.

				          GL_CFG=""

				          if [ -f .forgejo/gitleaks.toml ]; then

.forgejo/workflows/baseline.yml:296 · LOW — Weak fallback to un-audited repo-root gitleaks config
If no seeded config is found, the workflow falls back to auto-discovering a repo-root .gitleaks.toml, which may use weaker rules (e.g., missing allowlists). This could silently weaken security scans.

Fix: Reject any repo-root .gitleaks.toml that lacks [extend] useDefault = true, falling back to the image-baked org config or gitleaks built-ins instead.

_{panel tally 3/4 · reply here or use the finding board to agree/disagree}

**`.forgejo/workflows/baseline.yml:296`** · LOW — Weak fallback to un-audited repo-root gitleaks config If no seeded config is found, the workflow falls back to auto-discovering a repo-root `.gitleaks.toml`, which may use weaker rules (e.g., missing allowlists). This could silently weaken security scans. > **Fix:** Reject any repo-root `.gitleaks.toml` that lacks `[extend] useDefault = true`, falling back to the image-baked org config or gitleaks built-ins instead. panel tally 3/4 · reply here or use the finding board to agree/disagree

baseline-security / baseline (push) Successful in 2m26s

Details

scan / trivy-fs (push) Successful in 1m28s

Details

baseline-security / baseline (pull_request) Successful in 1m47s

Required

Details

ai-review / review (pull_request) Successful in 3m39s

Details

scan / trivy-fs (pull_request) Successful in 55s

Details

This pull request doesn't have enough approvals yet. 0 of 1 approvals granted.

This branch is out-of-date with the base branch

You are not authorized to merge this pull request.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin chore/h2-baseline-security:chore/h2-baseline-security

git switch chore/h2-baseline-security

Sign in to join this conversation.

No reviewers

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

tti/tti-ux!43

				`@ -408,18 +435,97 @@ jobs:`
				`print("files that do not. Add python3-yaml to the runner image.")`

				`@ -0,0 +1,67 @@`
				`# TTI gitleaks configuration for the H2 baseline gate.`

				`@ -93,4 +93,22 @@ rules:`
				`- "*/.md"`

Rows
Columns