Push gene#6
Conversation
Bumps [peter-evans/create-pull-request](https://github.com/peter-evans/create-pull-request) from 6 to 7. - [Release notes](https://github.com/peter-evans/create-pull-request/releases) - [Commits](peter-evans/create-pull-request@v6...v7) --- updated-dependencies: - dependency-name: peter-evans/create-pull-request dependency-version: '7' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [docker/build-push-action](https://github.com/docker/build-push-action) from 5.0.0 to 6.18.0. - [Release notes](https://github.com/docker/build-push-action/releases) - [Commits](docker/build-push-action@0565240...2634353) --- updated-dependencies: - dependency-name: docker/build-push-action dependency-version: 6.18.0 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
…in permissions Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Potential fix for code scanning alert no. 10: Workflow does not contain permissions
…ensitive information Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
…ct-spawner Add Helius multisig verification guide
…ct-spawner-kxmx14 Add CryptoGene agent blueprint, contract scanner, and deployment workflow hardening
…ensitive information Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Potential fix for code scanning alert no. 12: Clear-text logging of sensitive information
…n permissions Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
|
@imfromfuture3000-Android is attempting to deploy a commit to the imfromfuture3000-android's projects Team on Vercel. A member of the Team first needs to authorize it. |
📝 WalkthroughWalkthroughThis PR introduces comprehensive security scanning and monitoring infrastructure, including new GitHub Actions workflows for dependency auditing and CodeQL analysis, updated deployment workflows with contract scanning capabilities, expanded allowlist documentation with new addresses, and new scripts for repository contract address scanning alongside several guidance documents. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ❌ 3❌ Failed checks (2 warnings, 1 inconclusive)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs). Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 8
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
ALLOWLIST_ANALYSIS_REPORT.md (1)
43-55:⚠️ Potential issue | 🟡 MinorComplete metadata for Bot 6–8 before marking deployment-ready.
New bot entries have missing contract and specialty fields, which weakens auditability and incident response documentation.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ALLOWLIST_ANALYSIS_REPORT.md` around lines 43 - 55, The Bot Army table has incomplete entries for Bot 6, Bot 7, and Bot 8 (rows labeled "Bot 6", "Bot 7", "Bot 8") where the Contract Address and Specialty columns are "_(not specified)_"; update those rows to include the actual contract addresses and clearly defined specialties, or if no contract exists provide "N/A" plus a short justification (e.g., off-chain operator) and list a primary contact/identifier for auditability; ensure the final table replaces the placeholder text and preserves the same columns and formatting for Bot 6–8..github/workflows/security-scan.yml (1)
88-109:⚠️ Potential issue | 🟠 MajorAvoid direct auto-pushes to
mainfrom forced audit fixes.
contents: writeplusnpm audit fix --forceandgit pushcan land breaking dependency changes without review. Route fixes through a PR workflow instead.🛠️ Safer pattern (open PR instead of direct push)
- npm-audit: + npm-audit: runs-on: ubuntu-latest permissions: - contents: write + contents: read + pull-requests: write @@ - name: Run npm audit run: | npm audit --audit-level=moderate || true npm audit fix --force || true - - name: Commit fixes - run: | - git config user.name "Security Bot" - git config user.email "security@github.com" - git add package*.json - git diff --staged --quiet || git commit -m "🔒 Auto-fix security vulnerabilities" - git push || true + - name: Create PR with fixes + uses: peter-evans/create-pull-request@v7 + with: + commit-message: "🔒 Auto-fix security vulnerabilities" + title: "🔒 Automated npm audit fixes" + body: "Generated by security workflow." + branch: "bot/npm-audit-fixes"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/security-scan.yml around lines 88 - 109, The workflow currently allows direct forced fixes and pushes to main (permissions: contents: write + npm audit fix --force + git push); change it to create a new branch and open a PR instead: downgrade permissions to contents: read, remove or avoid direct git push to main in the "Commit fixes" step, instead create a uniquely-named branch (e.g., security-fix-<timestamp>), commit staged changes there, push that branch, and call the GitHub CLI or API to open a pull request for review; keep the "Run npm audit" step but avoid using --force without review and ensure the workflow exits non-zero on unexpected failures so fixes cannot be auto-landed to main without a PR.scripts/setup-moralis.js (1)
6-12:⚠️ Potential issue | 🔴 CriticalRemove hardcoded credentials and stop logging secret-bearing URLs.
The current fallback values include key-like secrets, and
Node URLoutput can expose them in logs. This is a release-blocking secret-handling issue.🔐 Proposed fix
-const MORALIS_API_KEY = process.env.MORALIS_API_KEY || 'c4d1d108f46144f1955612d3ac03dcd5'; -const MORALIS_NODE_URL = process.env.MORALIS_NODE_URL || 'https://site2.moralis-nodes.com/eth/c4d1d108f46144f1955612d3ac03dcd5'; +const MORALIS_API_KEY = process.env.MORALIS_API_KEY; +const MORALIS_NODE_URL = process.env.MORALIS_NODE_URL; + +if (!MORALIS_API_KEY || !MORALIS_NODE_URL) { + throw new Error('Missing MORALIS_API_KEY or MORALIS_NODE_URL in environment'); +} + +const redact = (value) => { + if (!value) return '(not set)'; + if (value.length <= 8) return '****'; + return `${value.slice(0, 4)}****${value.slice(-4)}`; +}; console.log('=== MORALIS API SETUP ==='); console.log(''); console.log('API Key:', MORALIS_API_KEY ? `(set, length: ${MORALIS_API_KEY.length})` : '(not set)'); -console.log('Node URL:', MORALIS_NODE_URL); +console.log('Node URL:', redact(MORALIS_NODE_URL));🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@scripts/setup-moralis.js` around lines 6 - 12, Remove the hardcoded secret fallbacks and stop printing secret-bearing values: change MORALIS_API_KEY and MORALIS_NODE_URL to use only process.env (no default literals) and update the console logging so you never output the Node URL or the raw API key; instead log only non-sensitive status (e.g., whether MORALIS_API_KEY is set and its length) and omit or mask MORALIS_NODE_URL. Update the setup code referencing MORALIS_API_KEY and MORALIS_NODE_URL and ensure you fail fast or warn appropriately when required env vars are missing in non-dev environments.
🧹 Nitpick comments (8)
docs/cryptogene_agent_blueprint.md (1)
107-113: Use a safer default in the runtime example.For a production-oriented blueprint,
require_approval: falseis an unsafe baseline for write-capable tools.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/cryptogene_agent_blueprint.md` around lines 107 - 113, Update the runtime example to use a safer default by changing the safety.require_approval setting from false to true and documenting that write-capable tools (e.g., the "deploy" tool listed under tools with permissions: write) require explicit approval; locate the safety block (safety.require_approval) and the tools list (tools -> name: deploy, permissions: write) and set require_approval: true (and optionally add a short comment or note in the blueprint explaining that write permissions require manual approval in production)..env.example (1)
1-5: GroupGROK_API_KEYunder a non-RPC section for clarity.
GROK_API_KEYis a credential, not an endpoint, so placing it under “RPC Endpoints” can cause config drift in setup scripts/docs.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.env.example around lines 1 - 5, Move GROK_API_KEY out of the "RPC Endpoints" block in .env.example and place it under a new or existing "Credentials" (or similar) section; update the file so that RPC entries like SOLANA_RPC, HELIUS_API_KEY, and QUICKNODE_ENDPOINT remain under "RPC Endpoints" while GROK_API_KEY is grouped with other credentials to avoid misclassification by setup scripts and docs..github/workflows/codeql.yml (1)
61-63: Pin action references to commit SHAs in this security workflow.Using moving tags (
@v4) weakens supply-chain guarantees. Prefer immutable SHA pins foruses:steps, especially in security-critical workflows like CodeQL.Also applies to: lines 72 and 101.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/codeql.yml around lines 61 - 63, Pin the moving action refs to immutable commit SHAs: replace uses: actions/checkout@v4 and the other uses entries (e.g., github/codeql-action/init@v2 and github/codeql-action/analyze@v2) with the corresponding repository commit SHAs instead of tags. Find the current trusted commit SHAs from each action's GitHub repo (or the marketplace link), substitute the `@tag` with @<full-commit-sha>, and commit those changes so the workflow uses immutable refs for the CodeQL security steps.contract_scan_results.json (1)
1-6: Consider excluding this generated artifact from version control.
contract_scan_results.jsonis generated byscripts/scan-contracts.jsand contains environment-specific data (e.g.,scanned_from: "/workspace/mpc-agents"). Generated artifacts typically belong in.gitignorerather than being committed, as they can be regenerated on demand and may cause merge conflicts.If the intent is to track scan history, consider committing only a summary or storing results as CI artifacts instead.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@contract_scan_results.json` around lines 1 - 6, Remove the generated artifact contract_scan_results.json from version control and update the repo to ignore it: add contract_scan_results.json (or its directory/pattern) to .gitignore, remove the tracked file with git rm --cached so it remains locally but is not committed, and ensure scripts/scan-contracts.js still writes the file during scans; if you want historical records instead, change CI to persist the output as an artifact or commit a small summary file rather than the full generated JSON..github/workflows/full-deployment.yml (1)
54-57: Deployer key file should be securely cleaned up after use.The deployer private key is written to
deployer-key.json(line 54) but never deleted. While GitHub Actions runners are ephemeral, it's good practice to clean up sensitive files after use. Also, theGITHUB_TOKENenv var on lines 56-57 appears unnecessary for Solana CLI configuration.🔒 Suggested cleanup
- name: Configure Solana run: | solana config set --url ${{ github.event.inputs.environment == 'devnet' && 'https://api.devnet.solana.com' || 'https://api.mainnet-beta.solana.com' }} echo "${{ secrets.SOLANA_DEPLOYER_KEY }}" > deployer-key.json solana config set --keypair deployer-key.json - env: - GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + + # Add cleanup step after deployment + - name: Cleanup sensitive files + if: always() + run: rm -f deployer-key.json🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/full-deployment.yml around lines 54 - 57, The workflow writes a sensitive key to deployer-key.json and leaves it behind and also exports an unnecessary GITHUB_TOKEN; after calling "solana config set --keypair deployer-key.json" ensure you securely remove the file and clear the keypair from Solana config: delete/shred deployer-key.json (e.g., rm -f or shred) immediately after it's no longer needed and optionally reset the solana keypair setting (e.g., solana config set --keypair <empty-or-default>) to avoid lingering config, and remove the GITHUB_TOKEN env entry if it's not required for the solana CLI step.scripts/scan-contracts.js (2)
46-51: Consider usingfor...ofinstead offorEachto satisfy linter.Static analysis flags that
Set.add()returns a value, which is unused in theforEachcallback. While harmless, switching tofor...ofis more idiomatic and avoids the warning.♻️ Suggested refactor
if (Array.isArray(data.allowlist)) { - data.allowlist.forEach((addr) => addresses.add(addr)); + for (const addr of data.allowlist) addresses.add(addr); } if (Array.isArray(data.master_allowlist)) { - data.master_allowlist.forEach((addr) => addresses.add(addr)); + for (const addr of data.master_allowlist) addresses.add(addr); }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@scripts/scan-contracts.js` around lines 46 - 51, The linter flags unused return values from Set.add() inside forEach; replace the forEach callbacks that iterate data.allowlist and data.master_allowlist with for...of loops so you directly call addresses.add(addr) for each addr. Update the blocks that reference data.allowlist and data.master_allowlist (where addresses.add is currently invoked) to use: for (const addr of data.allowlist) { addresses.add(addr); } and similarly for data.master_allowlist to eliminate the unused-return warning.
90-92: Silent error suppression may hide issues during debugging.The empty
catchblock silently ignores all errors. While this is reasonable for binary/unreadable files, consider adding a verbose/debug mode or logging skipped files to aid troubleshooting.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@scripts/scan-contracts.js` around lines 90 - 92, The empty catch in scripts/scan-contracts.js silently swallows errors; modify that catch to either log the skipped file and error (including the file identifier used in the surrounding code, e.g., filePath or filename) or respect a verbose/debug flag (e.g., process.env.VERBOSE) so unreadable/binary files are still skipped but errors are emitted when verbose mode is enabled; ensure you include a clear message and the original error object in the log call rather than leaving the block empty.DAO_CONTROLLER_HELIUS_GUIDE.md (1)
12-15: Consider extracting hardcoded addresses to a shared config.The guide hardcodes addresses that also appear in
DAO_SIGNERS_REPORT.mdand other files. If these addresses change, multiple files need updating. Consider referencing a single source of truth or noting where the canonical addresses are defined.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@DAO_CONTROLLER_HELIUS_GUIDE.md` around lines 12 - 15, Extract the hardcoded addresses in the "DAO controller multisig signers" block (Controller address, Signers list, Multisig account) into a single source of truth (a shared config/constants module or canonical report) and update DAO_CONTROLLER_HELIUS_GUIDE.md to reference or include those values rather than hardcoding them; specifically create/read keys like CONTROLLER_ADDRESS, SIGNER_ADDRESSES, and MULTISIG_ACCOUNT in the shared config and update the guide and any scripts (e.g., the verification script that uses the multisig) to pull from that config, and add a small consistency check or note pointing to the canonical location to prevent drift.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/.github/workflows/dependency-audit.yml:
- Around line 1-14: The workflow named "Dependency Audit & Vulnerability Scan"
is nested incorrectly and won't be discovered by GH Actions; move the YAML so it
lives directly in the repository's workflows directory (remove the extra nested
folder) so GitHub can run it, and verify the file still contains the same name
and concurrency group "dependency-audit" and the on:
push/schedule/workflow_dispatch triggers remain intact.
- Around line 131-132: The "Finish" job step has a YAML parsing error because
the run value contains unescaped characters and a colon; update the step with a
properly quoted or block-style run value so YAML parses correctly — e.g., change
the step identified by name: "Finish" and its run key to use either a
single/double-quoted string or a block scalar (|) for the command so the inner
echo "Artifacts uploaded: $(ls -la artifacts || true)" is treated as a string by
YAML.
- Around line 89-99: The current govulncheck JSON logic assumes a single JSON
object with .vulns/.fixed; govulncheck -json actually produces NDJSON lines
where each message is a top-level object like config, SBOM, progress, osv, or
finding; update the workflow step that reads govulncheck.json to parse NDJSON
(one JSON object per line) and detect any lines with a "finding" object, then
inspect that finding's fields (e.g., finding.osv, finding.fixed_version and any
severity field) to decide failure; replace the faulty jq expressions that
reference .vulns and .fixed with a line-by-line jq selection (e.g., selecting
objects with .finding) and fail if any finding indicates HIGH/CRITICAL severity
or otherwise represents an unaddressed vulnerability.
- Around line 50-54: The current jq check inspects .advisories which is the old
npm-audit format; update the jq expression used in the run block (the command
that parses npm-audit.json) to handle both formats by checking for
.vulnerabilities as well as .advisories and fail if any entry has severity
"high" or "critical" (or if .vulnerabilities contains any entries with those
severities), ensuring the command that reads npm-audit.json will detect
vulnerabilities produced by modern npm (v7+) and legacy outputs.
In @.github/workflows/verify-deployment.yml:
- Around line 7-9: The workflow grants contents: write and currently only checks
github.event.workflow_run.conclusion == 'success'; add an explicit trust check
that the upstream run is from the same repo by verifying
github.event.workflow_run.head_repository.full_name == github.repository before
any write operations or before the job that performs writes; update the relevant
job/step condition(s) (where the check currently uses
github.event.workflow_run.conclusion) to combine both conditions so writes only
proceed when conclusion == 'success' AND head_repository.full_name ==
github.repository.
In `@contract_scan_results.json`:
- Around line 980-1015: The contract scan is matching Go identifiers (e.g.,
getLatestPendingReviewQueryParams, getLatestPendingReviewQueryReview,
GetRepositoryResourceBranchContent, GetRepositoryResourceCommitContent) as
Solana addresses; update scripts/scan-contracts.js to refine the regex or add a
post-filter so it excludes typical Go identifier patterns (e.g., plain
alphanumerics/underscores with mixedCase or PascalCase and file extensions like
.go) and/or require address-specific features (length, hex/base58 charset, or
prefix) before adding an entry; ensure the filter is applied where matches are
collected so entries from pkg/github/*.go are not reported as blockchain
addresses.
In `@docs/cryptogene_agent_blueprint.md`:
- Around line 18-24: Add a language identifier (e.g., `text`) to the fenced code
block containing the ASCII diagram so markdown linting passes; locate the
triple-backtick block that wraps the diagram ("User ──► Orchestrator ──► Planner
──► Tool Router ──► Executors ... Policy Store ◄───────┘") and change the
opening fence from ``` to ```text.
In `@scripts/scan-contracts.js`:
- Around line 33-34: SOLANA_REGEX is too permissive and produces false positives
(e.g., function names in contract_scan_results.json); update the pattern or add
a post-filter: tighten SOLANA_REGEX to more strictly match Solana pubkey quirks
(e.g., require exact 44-char Base58 addresses when appropriate) or add a
validation step after matching that verifies length and character distribution
(e.g., reject matches <44 chars or with improbable character frequency), and
apply this filter where matches are collected (reference SOLANA_REGEX and the
code that writes contract_scan_results.json) so only valid-looking Solana
addresses are emitted.
---
Outside diff comments:
In @.github/workflows/security-scan.yml:
- Around line 88-109: The workflow currently allows direct forced fixes and
pushes to main (permissions: contents: write + npm audit fix --force + git
push); change it to create a new branch and open a PR instead: downgrade
permissions to contents: read, remove or avoid direct git push to main in the
"Commit fixes" step, instead create a uniquely-named branch (e.g.,
security-fix-<timestamp>), commit staged changes there, push that branch, and
call the GitHub CLI or API to open a pull request for review; keep the "Run npm
audit" step but avoid using --force without review and ensure the workflow exits
non-zero on unexpected failures so fixes cannot be auto-landed to main without a
PR.
In `@ALLOWLIST_ANALYSIS_REPORT.md`:
- Around line 43-55: The Bot Army table has incomplete entries for Bot 6, Bot 7,
and Bot 8 (rows labeled "Bot 6", "Bot 7", "Bot 8") where the Contract Address
and Specialty columns are "_(not specified)_"; update those rows to include the
actual contract addresses and clearly defined specialties, or if no contract
exists provide "N/A" plus a short justification (e.g., off-chain operator) and
list a primary contact/identifier for auditability; ensure the final table
replaces the placeholder text and preserves the same columns and formatting for
Bot 6–8.
In `@scripts/setup-moralis.js`:
- Around line 6-12: Remove the hardcoded secret fallbacks and stop printing
secret-bearing values: change MORALIS_API_KEY and MORALIS_NODE_URL to use only
process.env (no default literals) and update the console logging so you never
output the Node URL or the raw API key; instead log only non-sensitive status
(e.g., whether MORALIS_API_KEY is set and its length) and omit or mask
MORALIS_NODE_URL. Update the setup code referencing MORALIS_API_KEY and
MORALIS_NODE_URL and ensure you fail fast or warn appropriately when required
env vars are missing in non-dev environments.
---
Nitpick comments:
In @.env.example:
- Around line 1-5: Move GROK_API_KEY out of the "RPC Endpoints" block in
.env.example and place it under a new or existing "Credentials" (or similar)
section; update the file so that RPC entries like SOLANA_RPC, HELIUS_API_KEY,
and QUICKNODE_ENDPOINT remain under "RPC Endpoints" while GROK_API_KEY is
grouped with other credentials to avoid misclassification by setup scripts and
docs.
In @.github/workflows/codeql.yml:
- Around line 61-63: Pin the moving action refs to immutable commit SHAs:
replace uses: actions/checkout@v4 and the other uses entries (e.g.,
github/codeql-action/init@v2 and github/codeql-action/analyze@v2) with the
corresponding repository commit SHAs instead of tags. Find the current trusted
commit SHAs from each action's GitHub repo (or the marketplace link), substitute
the `@tag` with @<full-commit-sha>, and commit those changes so the workflow uses
immutable refs for the CodeQL security steps.
In @.github/workflows/full-deployment.yml:
- Around line 54-57: The workflow writes a sensitive key to deployer-key.json
and leaves it behind and also exports an unnecessary GITHUB_TOKEN; after calling
"solana config set --keypair deployer-key.json" ensure you securely remove the
file and clear the keypair from Solana config: delete/shred deployer-key.json
(e.g., rm -f or shred) immediately after it's no longer needed and optionally
reset the solana keypair setting (e.g., solana config set --keypair
<empty-or-default>) to avoid lingering config, and remove the GITHUB_TOKEN env
entry if it's not required for the solana CLI step.
In `@contract_scan_results.json`:
- Around line 1-6: Remove the generated artifact contract_scan_results.json from
version control and update the repo to ignore it: add contract_scan_results.json
(or its directory/pattern) to .gitignore, remove the tracked file with git rm
--cached so it remains locally but is not committed, and ensure
scripts/scan-contracts.js still writes the file during scans; if you want
historical records instead, change CI to persist the output as an artifact or
commit a small summary file rather than the full generated JSON.
In `@DAO_CONTROLLER_HELIUS_GUIDE.md`:
- Around line 12-15: Extract the hardcoded addresses in the "DAO controller
multisig signers" block (Controller address, Signers list, Multisig account)
into a single source of truth (a shared config/constants module or canonical
report) and update DAO_CONTROLLER_HELIUS_GUIDE.md to reference or include those
values rather than hardcoding them; specifically create/read keys like
CONTROLLER_ADDRESS, SIGNER_ADDRESSES, and MULTISIG_ACCOUNT in the shared config
and update the guide and any scripts (e.g., the verification script that uses
the multisig) to pull from that config, and add a small consistency check or
note pointing to the canonical location to prevent drift.
In `@docs/cryptogene_agent_blueprint.md`:
- Around line 107-113: Update the runtime example to use a safer default by
changing the safety.require_approval setting from false to true and documenting
that write-capable tools (e.g., the "deploy" tool listed under tools with
permissions: write) require explicit approval; locate the safety block
(safety.require_approval) and the tools list (tools -> name: deploy,
permissions: write) and set require_approval: true (and optionally add a short
comment or note in the blueprint explaining that write permissions require
manual approval in production).
In `@scripts/scan-contracts.js`:
- Around line 46-51: The linter flags unused return values from Set.add() inside
forEach; replace the forEach callbacks that iterate data.allowlist and
data.master_allowlist with for...of loops so you directly call
addresses.add(addr) for each addr. Update the blocks that reference
data.allowlist and data.master_allowlist (where addresses.add is currently
invoked) to use: for (const addr of data.allowlist) { addresses.add(addr); } and
similarly for data.master_allowlist to eliminate the unused-return warning.
- Around line 90-92: The empty catch in scripts/scan-contracts.js silently
swallows errors; modify that catch to either log the skipped file and error
(including the file identifier used in the surrounding code, e.g., filePath or
filename) or respect a verbose/debug flag (e.g., process.env.VERBOSE) so
unreadable/binary files are still skipped but errors are emitted when verbose
mode is enabled; ensure you include a clear message and the original error
object in the log call rather than leaving the block empty.
ℹ️ Review info
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (14)
.env.example.github/workflows/.github/workflows/dependency-audit.yml.github/workflows/codeql.yml.github/workflows/full-deployment.yml.github/workflows/security-scan.yml.github/workflows/verify-deployment.ymlALLOWLIST_ANALYSIS_REPORT.mdCOMPREHENSIVE_ALLOWLIST_UPDATE.jsonDAO_CONTROLLER_HELIUS_GUIDE.mdRUNNING_CONTRACT_UPGRADE_REPORT.mdcontract_scan_results.jsondocs/cryptogene_agent_blueprint.mdscripts/scan-contracts.jsscripts/setup-moralis.js
| name: "Dependency Audit & Vulnerability Scan" | ||
|
|
||
| # Run on push to main (or any branch), and on a daily schedule | ||
| on: | ||
| push: | ||
| branches: | ||
| - '**' | ||
| schedule: | ||
| - cron: '0 2 * * *' # daily at 02:00 UTC | ||
| workflow_dispatch: | ||
|
|
||
| concurrency: | ||
| group: dependency-audit | ||
| cancel-in-progress: true |
There was a problem hiding this comment.
Critical: Workflow file is in wrong directory and won't execute.
The file path .github/workflows/.github/workflows/dependency-audit.yml is nested incorrectly. GitHub Actions only recognizes workflows directly under .github/workflows/. This workflow will never run.
Move the file to .github/workflows/dependency-audit.yml.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/.github/workflows/dependency-audit.yml around lines 1 -
14, The workflow named "Dependency Audit & Vulnerability Scan" is nested
incorrectly and won't be discovered by GH Actions; move the YAML so it lives
directly in the repository's workflows directory (remove the extra nested
folder) so GitHub can run it, and verify the file still contains the same name
and concurrency group "dependency-audit" and the on:
push/schedule/workflow_dispatch triggers remain intact.
| - name: Fail on high/critical npm findings | ||
| if: ${{ hashFiles('**/package-lock.json') != '' }} | ||
| run: | | ||
| jq -e '.advisories as $a | ($a | to_entries | map(.value) | map(select(.severity == "high" or .severity == "critical")) | length) > 0' npm-audit.json \ | ||
| && (echo "High/Critical vulnerabilities found in npm dependencies" && exit 1) || echo "No high/critical npm vulnerabilities" |
There was a problem hiding this comment.
npm audit JSON format may have changed.
The jq command checks for .advisories, but modern npm versions (v7+) use a different JSON structure with .vulnerabilities instead of .advisories. This check may always pass (no vulnerabilities found) even when vulnerabilities exist.
#!/bin/bash
# Check if package.json exists and what npm version format is expected
cat package.json 2>/dev/null | jq '.engines.npm // "not specified"'
# Check npm audit format documentation
echo "Verify npm audit --json output format for the npm version in use"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/.github/workflows/dependency-audit.yml around lines 50 -
54, The current jq check inspects .advisories which is the old npm-audit format;
update the jq expression used in the run block (the command that parses
npm-audit.json) to handle both formats by checking for .vulnerabilities as well
as .advisories and fail if any entry has severity "high" or "critical" (or if
.vulnerabilities contains any entries with those severities), ensuring the
command that reads npm-audit.json will detect vulnerabilities produced by modern
npm (v7+) and legacy outputs.
| - name: Fail on found Go vulnerabilities (HIGH/CRITICAL) | ||
| run: | | ||
| # govulncheck JSON has "vulns" entries; search for severity levels if available | ||
| if jq -e '.vulns | length > 0' govulncheck.json >/dev/null 2>&1; then | ||
| # Try to detect severity mentions; if none, fail so maintainers can review | ||
| if jq -e '.vulns | map(.fixed|length > 0 or true) | length > 0' govulncheck.json >/dev/null 2>&1; then | ||
| echo "Go vulnerabilities detected — please review govulncheck.json artifact." | ||
| exit 1 | ||
| fi | ||
| fi | ||
| echo "No Go vulnerabilities detected (or none reported by govulncheck)." |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
govulncheck JSON output format structure 2025
💡 Result:
govulncheck -format=json emits streaming NDJSON: each line is a JSON object, and each object is a Message with exactly one top-level field set (order not guaranteed). [1], [2]
Top-level “message” shapes (one per line)
{"config": { ... }}
{"SBOM": { ... }}
{"progress": { ... }}
{"osv": { ... }} // an OSV entry object
{"finding": { ... }}[1]
config object
{
"protocol_version": "v1.0.0",
"scanner_name": "govulncheck",
"scanner_version": "…",
"db": "vuln.go.dev",
"db_last_modified": "…RFC3339 time…",
"go_version": "go1.xx.x",
"scan_level": "module|package|symbol",
"scan_mode": "source|binary|convert|query|extract"
}[1]
SBOM object
{
"go_version": "go1.xx.x",
"modules": [{"path":"…","version":"…"}, ...],
"roots": ["package/path/...", ...]
}[1]
progress object
{"time":"…RFC3339 time…","message":"…"}[1]
finding object (refers to an OSV by id)
{
"osv": "GO-YYYY-NNNN",
"fixed_version": "vX.Y.Z",
"trace": [
{
"module": "…", "version": "…",
"package": "…",
"function": "…",
"receiver": "…",
"position": {"filename":"…","offset":0,"line":1,"column":1}
}
]
}[1]
🏁 Script executed:
cat -n .github/workflows/dependency-audit.yml | sed -n '80,110p'Repository: imfromfuture3000-Android/github-mcp-server
Length of output: 156
🏁 Script executed:
find . -name "dependency-audit.yml" -o -name "*dependency*audit*" 2>/dev/null | head -20Repository: imfromfuture3000-Android/github-mcp-server
Length of output: 144
🏁 Script executed:
cat -n ./.github/workflows/.github/workflows/dependency-audit.yml | sed -n '80,110p'Repository: imfromfuture3000-Android/github-mcp-server
Length of output: 1507
The govulncheck JSON parsing logic is fundamentally broken.
govulncheck -json outputs NDJSON (streaming, newline-delimited JSON), not a single JSON object. Each line is a separate message with one top-level field: config, SBOM, progress, osv, or finding. The code incorrectly tries to access .vulns and .fixed fields that do not exist in the actual output structure. Vulnerabilities appear as individual finding objects with osv and fixed_version fields. The current jq expressions will not properly detect vulnerabilities and will always pass the checks.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/.github/workflows/dependency-audit.yml around lines 89 -
99, The current govulncheck JSON logic assumes a single JSON object with
.vulns/.fixed; govulncheck -json actually produces NDJSON lines where each
message is a top-level object like config, SBOM, progress, osv, or finding;
update the workflow step that reads govulncheck.json to parse NDJSON (one JSON
object per line) and detect any lines with a "finding" object, then inspect that
finding's fields (e.g., finding.osv, finding.fixed_version and any severity
field) to decide failure; replace the faulty jq expressions that reference
.vulns and .fixed with a line-by-line jq selection (e.g., selecting objects with
.finding) and fail if any finding indicates HIGH/CRITICAL severity or otherwise
represents an unaddressed vulnerability.
| - name: Finish | ||
| run: echo "Artifacts uploaded: $(ls -la artifacts || true)" |
There was a problem hiding this comment.
YAML syntax error on line 132.
Static analysis indicates a YAML syntax error. The echo command with colons may be causing parsing issues.
🐛 Suggested fix
- name: Finish
- run: echo "Artifacts uploaded: $(ls -la artifacts || true)"
+ run: |
+ echo "Artifacts uploaded:"
+ ls -la artifacts || true📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - name: Finish | |
| run: echo "Artifacts uploaded: $(ls -la artifacts || true)" | |
| - name: Finish | |
| run: | | |
| echo "Artifacts uploaded:" | |
| ls -la artifacts || true |
🧰 Tools
🪛 actionlint (1.7.11)
[error] 132-132: could not parse as YAML: mapping values are not allowed in this context
(syntax-check)
🪛 YAMLlint (1.38.0)
[error] 132-132: syntax error: mapping values are not allowed here
(syntax)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/.github/workflows/dependency-audit.yml around lines 131 -
132, The "Finish" job step has a YAML parsing error because the run value
contains unescaped characters and a colon; update the step with a properly
quoted or block-style run value so YAML parses correctly — e.g., change the step
identified by name: "Finish" and its run key to use either a
single/double-quoted string or a block scalar (|) for the command so the inner
echo "Artifacts uploaded: $(ls -la artifacts || true)" is treated as a string by
YAML.
| permissions: | ||
| contents: write | ||
| actions: read |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Find upstream workflow referenced by verify-deployment =="
rg -n 'name:\s*"?(Full Deployment Pipeline)"?' .github/workflows -g '*.yml' -g '*.yaml'
echo
echo "== Show trigger + permissions blocks for all workflows =="
for f in $(fd -e yml -e yaml .github/workflows); do
echo "----- $f -----"
rg -n '^(name:|on:|permissions:|jobs:)|pull_request|pull_request_target|workflow_run|workflow_dispatch|push:' "$f" -n -C2
done
echo
echo "== Check verify-deployment trust guard conditions =="
rg -n 'github\.event\.workflow_run\.(conclusion|event|head_branch|head_repository)' .github/workflows/verify-deployment.yml -C2 || true
echo
echo "== Show full verify-deployment.yml content =="
cat .github/workflows/verify-deployment.ymlRepository: imfromfuture3000-Android/github-mcp-server
Length of output: 3067
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Show full full-deployment.yml content =="
cat .github/workflows/full-deployment.yml
echo
echo "== Check if verify-deployment checks trusted repository/branch =="
grep -n "head_repository\|head_branch\|repository_owner" .github/workflows/verify-deployment.yml || echo "No explicit repository/branch checks found"Repository: imfromfuture3000-Android/github-mcp-server
Length of output: 6219
Add explicit trust validation for upstream workflow context before write operations.
The workflow has a partial trust guard (github.event.workflow_run.conclusion == 'success') and the upstream "Full Deployment Pipeline" is restricted to the main branch and workflow_dispatch, but verify-deployment.yml lacks explicit validation that the upstream run originated from the same repository. This should be strengthened by checking github.event.workflow_run.head_repository.full_name == github.repository before writing to the repo, especially given the contents: write permission.
Also applies to: 31-31
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/verify-deployment.yml around lines 7 - 9, The workflow
grants contents: write and currently only checks
github.event.workflow_run.conclusion == 'success'; add an explicit trust check
that the upstream run is from the same repo by verifying
github.event.workflow_run.head_repository.full_name == github.repository before
any write operations or before the job that performs writes; update the relevant
job/step condition(s) (where the check currently uses
github.event.workflow_run.conclusion) to combine both conditions so writes only
proceed when conclusion == 'success' AND head_repository.full_name ==
github.repository.
| { | ||
| "address": "getLatestPendingReviewQueryParams", | ||
| "type": "solana", | ||
| "allowlisted": false, | ||
| "files": [ | ||
| "pkg/github/pullrequests_test.go" | ||
| ] | ||
| }, | ||
| { | ||
| "address": "getLatestPendingReviewQueryReview", | ||
| "type": "solana", | ||
| "allowlisted": false, | ||
| "files": [ | ||
| "pkg/github/pullrequests_test.go" | ||
| ] | ||
| }, | ||
| { | ||
| "address": "GetRepositoryResourceBranchContent", | ||
| "type": "solana", | ||
| "allowlisted": false, | ||
| "files": [ | ||
| "pkg/github/repository_resource.go", | ||
| "pkg/github/repository_resource_test.go", | ||
| "pkg/github/tools.go" | ||
| ] | ||
| }, | ||
| { | ||
| "address": "GetRepositoryResourceCommitContent", | ||
| "type": "solana", | ||
| "allowlisted": false, | ||
| "files": [ | ||
| "pkg/github/repository_resource.go", | ||
| "pkg/github/repository_resource_test.go", | ||
| "pkg/github/tools.go" | ||
| ] | ||
| }, |
There was a problem hiding this comment.
False positives: Go function names incorrectly identified as Solana addresses.
These entries are Go function/type names from pkg/github/, not blockchain addresses:
getLatestPendingReviewQueryParamsgetLatestPendingReviewQueryReviewGetRepositoryResourceBranchContentGetRepositoryResourceCommitContent
This confirms the regex issue flagged in scripts/scan-contracts.js. The scan results should be filtered or the regex refined to avoid polluting the report.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@contract_scan_results.json` around lines 980 - 1015, The contract scan is
matching Go identifiers (e.g., getLatestPendingReviewQueryParams,
getLatestPendingReviewQueryReview, GetRepositoryResourceBranchContent,
GetRepositoryResourceCommitContent) as Solana addresses; update
scripts/scan-contracts.js to refine the regex or add a post-filter so it
excludes typical Go identifier patterns (e.g., plain alphanumerics/underscores
with mixedCase or PascalCase and file extensions like .go) and/or require
address-specific features (length, hex/base58 charset, or prefix) before adding
an entry; ensure the filter is applied where matches are collected so entries
from pkg/github/*.go are not reported as blockchain addresses.
| ``` | ||
| User ──► Orchestrator ──► Planner ──► Tool Router ──► Executors | ||
| │ │ │ | ||
| ├────────► Memory ├────────► Evaluator | ||
| │ │ │ | ||
| └────────► Policy Store ◄───────┘ | ||
| ``` |
There was a problem hiding this comment.
Add a language identifier to the fenced code block.
The diagram block should specify a language (e.g., text) to satisfy markdown linting.
✅ Minimal fix
-```
+```text
User ──► Orchestrator ──► Planner ──► Tool Router ──► Executors
│ │ │
├────────► Memory ├────────► Evaluator
│ │ │
└────────► Policy Store ◄───────┘</details>
<!-- suggestion_start -->
<details>
<summary>📝 Committable suggestion</summary>
> ‼️ **IMPORTANT**
> Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
```suggestion
🧰 Tools
🪛 markdownlint-cli2 (0.21.0)
[warning] 18-18: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/cryptogene_agent_blueprint.md` around lines 18 - 24, Add a language
identifier (e.g., `text`) to the fenced code block containing the ASCII diagram
so markdown linting passes; locate the triple-backtick block that wraps the
diagram ("User ──► Orchestrator ──► Planner ──► Tool Router ──► Executors ...
Policy Store ◄───────┘") and change the opening fence from ``` to ```text.
| const SOLANA_REGEX = /\b[1-9A-HJ-NP-Za-km-z]{32,44}\b/g; | ||
| const EVM_REGEX = /\b0x[a-fA-F0-9]{40}\b/g; |
There was a problem hiding this comment.
SOLANA_REGEX produces many false positives.
The regex [1-9A-HJ-NP-Za-km-z]{32,44} matches any base58-like string, not just valid Solana addresses. This explains why contract_scan_results.json contains entries like getLatestPendingReviewQueryParams, GetRepositoryResourceBranchContent, and ListRepositorySecurityAdvisories — these are Go function names that happen to match the pattern.
Consider tightening the pattern or post-filtering results by length and character distribution to reduce noise.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@scripts/scan-contracts.js` around lines 33 - 34, SOLANA_REGEX is too
permissive and produces false positives (e.g., function names in
contract_scan_results.json); update the pattern or add a post-filter: tighten
SOLANA_REGEX to more strictly match Solana pubkey quirks (e.g., require exact
44-char Base58 addresses when appropriate) or add a validation step after
matching that verifies length and character distribution (e.g., reject matches
<44 chars or with improbable character frequency), and apply this filter where
matches are collected (reference SOLANA_REGEX and the code that writes
contract_scan_results.json) so only valid-looking Solana addresses are emitted.
Bumps [@solana/spl-token](https://github.com/solana-labs/solana-program-library) from 0.1.8 to 0.4.14. - [Release notes](https://github.com/solana-labs/solana-program-library/releases) - [Commits](https://github.com/solana-labs/solana-program-library/commits) --- updated-dependencies: - dependency-name: "@solana/spl-token" dependency-version: 0.4.14 dependency-type: direct:development update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [actions/github-script](https://github.com/actions/github-script) from 7 to 8. - [Release notes](https://github.com/actions/github-script/releases) - [Commits](actions/github-script@v7...v8) --- updated-dependencies: - dependency-name: actions/github-script dependency-version: '8' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [@coral-xyz/anchor](https://github.com/coral-xyz/anchor) from 0.30.1 to 0.32.1. - [Release notes](https://github.com/coral-xyz/anchor/releases) - [Changelog](https://github.com/solana-foundation/anchor/blob/master/CHANGELOG.md) - [Commits](solana-foundation/anchor@v0.30.1...v0.32.1) --- updated-dependencies: - dependency-name: "@coral-xyz/anchor" dependency-version: 0.32.1 dependency-type: direct:development update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [docker/metadata-action](https://github.com/docker/metadata-action) from 5.0.0 to 5.10.0. - [Release notes](https://github.com/docker/metadata-action/releases) - [Commits](docker/metadata-action@96383f4...c299e40) --- updated-dependencies: - dependency-name: docker/metadata-action dependency-version: 5.10.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [docker/login-action](https://github.com/docker/login-action) from 3.0.0 to 3.6.0. - [Release notes](https://github.com/docker/login-action/releases) - [Commits](docker/login-action@343f7c4...5e57cd1) --- updated-dependencies: - dependency-name: docker/login-action dependency-version: 3.6.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
…a/spl-token-0.4.14 Bump @solana/spl-token from 0.1.8 to 0.4.14
Potential fix for code scanning alert no. 6: Workflow does not contain permissions
…ker/login-action-3.6.0 Bump docker/login-action from 3.0.0 to 3.6.0
…ker/metadata-action-5.10.0 Bump docker/metadata-action from 5.0.0 to 5.10.0
Bumps [reproducible-containers/buildkit-cache-dance](https://github.com/reproducible-containers/buildkit-cache-dance) from 2.1.4 to 3.3.0. - [Release notes](https://github.com/reproducible-containers/buildkit-cache-dance/releases) - [Commits](reproducible-containers/buildkit-cache-dance@4b2444f...5b81f4d) --- updated-dependencies: - dependency-name: reproducible-containers/buildkit-cache-dance dependency-version: 3.3.0 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
…roducible-containers/buildkit-cache-dance-3.3.0 Bump reproducible-containers/buildkit-cache-dance from 2.1.4 to 3.3.0
…-xyz/anchor-0.32.1 Bump @coral-xyz/anchor from 0.30.1 to 0.32.1
…ions/github-script-8 Bump actions/github-script from 7 to 8
…er-evans/create-pull-request-7 Bump peter-evans/create-pull-request from 6 to 7
…ker/build-push-action-6.18.0 Bump docker/build-push-action from 5.0.0 to 6.18.0
Bumps [docker/setup-buildx-action](https://github.com/docker/setup-buildx-action) from 3.11.1 to 3.12.0. - [Release notes](https://github.com/docker/setup-buildx-action/releases) - [Commits](docker/setup-buildx-action@e468171...8d2750c) --- updated-dependencies: - dependency-name: docker/setup-buildx-action dependency-version: 3.12.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
…cker/setup-buildx-action-3.12.0 Bump docker/setup-buildx-action from 3.11.1 to 3.12.0
Bumps golang from 1.25.4-alpine to 1.25.7-alpine. --- updated-dependencies: - dependency-name: golang dependency-version: 1.25.7-alpine dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
…5.7-alpine build(deps): bump golang from 1.25.4-alpine to 1.25.7-alpine
5d89867
into
imfromfuture3000-Android:main
Merge pull request #6 from WhiteAiBlock/main
Closes:
Summary by CodeRabbit
New Features
Documentation
Chores