Skip to content

Harden secret scanning of agent-authored issue context and PR descriptions #1673

Open
#1674
Open
Harden secret scanning of agent-authored issue context and PR descriptions#1673
#1674
Labels
triaged

Description

@shairevivo
shairevivo
opened on Oct 13, 2026

What happens

The code post-script publishes agent-authored text in two places:

  • On a clean no-commit exit, post_noop_comment reads pr_body and posts it
    as "Agent context" on the source GitHub/GitLab issue. It applies
    sanitize_failure_detail, but does not run a general secret scan. The
    sanitizer covers selected token and private-key formats, not every
    credential type.
  • On a normal PR-creation run, the script secret-scans pr_body before
    publishing the PR description, but the command permits inline
    gitleaks:allow suppression.

The script's installer specifies Gitleaks v8.30.1, although an existing
binary on PATH is reused. That version also accepts scanner configuration
from GITLEAKS_CONFIG / GITLEAKS_CONFIG_TOML and defaults its ignore-file
lookup to the current working directory. The post-script runs inside the
extracted repository. A temporary source file avoids automatic discovery
of the repository's .gitleaks.toml, but does not by itself isolate the
environment overrides or ignore lookup. These are policy inputs to verify,
not a claim that a workflow exploit has been reproduced.

This can leave credential-shaped content eligible for publication, or make
the scan's effective policy depend on settings unrelated to public text.
No actual credential disclosure has been observed in this investigation.

What should happen

For these two code-agent publication paths:

  • Agent-authored text is checked before it becomes an issue comment or PR
    description, using the supported scanner and a known effective policy.
  • Inline allow markers and repository-controlled scanner settings cannot
    suppress a credential detection in public text.
  • A secret finding or inability to complete a scan suppresses the optional
    no-op context or uses the existing PR-body fallback. Ordinary safe text
    remains publishable. Existing credential redaction still applies.
  • Scanner diagnostics do not disclose credential values publicly.
  • Tests exercise real scanner behavior and the actual publication paths,
    including safe text, a synthetic detectable credential, an inline allow
    marker, configuration/ignore interactions, and scanner failures.

Scope

scripts/post-code.src.sh, its generated scripts/post-code.sh, and tests
for the two publication paths. GitHub and GitLab issue delivery must retain
the same behavior. Jira-source no-op runs currently return before reading
pr_body; this issue does not add Jira comment delivery.

This issue does not change repository-boundary guidance, result fields,
review dispatch, merge-commit scans, or commit-history scanning policy.

Context

Security observations during PR #1659
were separated from #1656,
which asks for guidance when a fix belongs in another repository.

Related open issue #233
covers PR-body scan-status checklist rendering tests, rather than scanner
policy or no-op publication. #137
covers reviewer detection of sensitive tool output reaching public comments.
Neither owns this production behavior.

Earlier hardening work remains in PR #1659's history at 412106d and
eb14ad8; 07fe09d removes it from that PR's final diff. Those commits
are reference material, not a verified complete fix for this issue.

Activity

  1. github-project-automation
    added this to fullsend-ai Workstreamon Oct 13, 2026

  2. fullsend-ai-triage commented on Oct 13, 2026

    @fullsend-ai-triage
    fullsend-ai-triageBot
    on Oct 13, 2026 – with fullsend-ai-triage

    🤖 Finished Triage · ✅ Success · Started 6:20 PM UTC · Completed 6:22 PM UTC

    Commit: 49c77a6 · View workflow run →

    Runtime: claude · Model: sonnet → claude-sonnet-5-5 · Effort: high · Cost: $0.24

  3. fullsend-ai-triage
    added
    triaged
    on Oct 13, 2026

  4. fullsend-ai-triage commented on Oct 13, 2026

    @fullsend-ai-triage
    fullsend-ai-triageBot
    on Oct 13, 2026 – with fullsend-ai-triage

    Triage found this issue actionable as written. Code review confirms both gaps: the no-op comment path posts the agent's pr_body after redaction only (no scan), and the PR-body scan calls gitleaks directly without isolating config environment variables, the working-directory ignore lookup, or inline allow markers. No existing PR, sub-issue, or duplicate was found, and #233 and #137 cover different behavior, as you noted.

    Suggested approach (for the implementer):

    • Use one shared scan helper for both publication paths. Run it from a neutral temp directory with an explicit config, with GITLEAKS_CONFIG* cleared and allow markers defeated.
    • In the no-op path, drop the 'Agent context' block on a finding or scan error. Keep the PR path's existing commit-body fallback.
    • Keep scanner diagnostics free of credential values. Regenerate scripts/post-code.sh from the .src.sh file.

    Open design question for maintainers (not blocking): how to neutralize inline allow markers. Options are stripping them from the scanned copy or relying on a scanner mode that ignores them. The implementer should check the behavior against the pinned gitleaks version. Because a pre-existing binary on PATH is reused, the helper should also check the version it runs.

    Proposed test cases (real gitleaks, actual publication paths):

    - safe text -> published unchanged (no-op comment and PR body)
- synthetic credential -> no-op context omitted / PR body falls back to commit body
- credential + inline allow marker -> still detected
- GITLEAKS_CONFIG env, repo .gitleaks.toml, cwd .gitleaksignore -> do not suppress detection
- scanner failure (exit > 1 / missing binary) -> fail closed, raw text not published
- logs/comments never contain the credential value
- existing sanitize_failure_detail redaction still applies

    This is categorized as security, so it is outside the default auto-promotion categories and will need a maintainer to dispatch the code agent.

    Next steps:

    • /fs-code — agent creates a PR to implement this issue
    • /fs-code <your instruction> — agent implements with your specific guidance
  5. github-project-automation
    moved this from Todo to In progress in fullsend-ai Workstreamon Oct 13, 2026
  6. shairevivo
    added 17 commits that reference this issue on Oct 18, 2026

    fix(#1673): scan final public text and classify scan failures

    87b772b

    fix(#1673): scan final PR title and description

    0302414

    fix(#1673): report final description scan status

    d765d2c

    fix(#1673): keep scanning within issue scope

    749d264

    fix(#1673): drop PR-title scan claims from code doc

    63c6682

    fix(#1673): isolate public-text secret scans

    fb4cc06

    fix(#1673): scan final public text and classify scan failures

    05c023c

    fix(#1673): scan final PR title and description

    c0a60a3

    fix(#1673): report final description scan status

    921625a

    fix(#1673): keep scanning within issue scope

    65a4767

    fix(#1673): drop PR-title scan claims from code doc

    9828703

    fix(#1673): isolate public-text secret scans

    e6ce3c2

    fix(#1673): scan final public text and classify scan failures

    ab63bae

    fix(#1673): scan final PR title and description

    76d4ea2

    fix(#1673): report final description scan status

    b3cd5ee

    fix(#1673): keep scanning within issue scope

    abca68b

    fix(#1673): verify gitleaks before public-text scans

    b0a5327
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    triaged

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions