feat(autodoc): add autodoc-executor reusable workflow - #65
Conversation
…audit pipeline Adds a purpose-built reusable workflow that runs Claude Code via AWS Bedrock for the issue_autodoc.yml pipeline in dotCMS/core. Separating this from the general-purpose claude-executor keeps AUTODOC_* secret passthrough and the report artifact upload out of the code-review path. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
🤖 Bedrock Review —
|
![semgrep-dotcms[bot]](https://avatars.githubusercontent.com/u/1005263?s=60&v=4){kind=small}
|
|
||
| - name: Upload report artifact | ||
| if: always() | ||
| uses: actions/upload-artifact@v4 |
There was a problem hiding this comment.
Semgrep identified a blocking 🔴 issue in your code:
GitHub Actions step uses mutable tag v4 instead of pinned commit SHA, allowing supply-chain attack if the action repository is compromised.
More details about this
The GitHub Actions workflow uses actions/upload-artifact@v4, which pins only to the v4 release tag. An attacker who gains control of the GitHub actions/upload-artifact repository could silently retag v4 to point to a malicious commit, and your workflow would automatically pull and execute the compromised version on the next run.
Here's a realistic attack scenario:
- Attacker compromises the maintainer account for the
actions/upload-artifactrepository or their CI/CD system - Attacker force-pushes a malicious version of the upload-artifact action and resets the
v4tag to point at it - Your next workflow run uses
v4again, but now executes the attacker's code with access to yourGITHUB_OUTPUT, filesystem (including/tmp/autodoc-report.md), and any secrets available to this job - The malicious action reads your artifacts and exfiltrates them or injects backdoors into your uploaded reports
This is not theoretical—this exact attack pattern compromised the trivy-action and kics-github-action projects when their maintainers were compromised.
To resolve this comment:
✨ Commit fix suggestion
| uses: actions/upload-artifact@v4 | |
| uses: actions/upload-artifact@65462800fd760344b1a7b4382951275a0abb4808 # v4.6.0 |
View step-by-step instructions
- Replace the mutable version tag in the workflow step with a full 40-character commit SHA for
actions/upload-artifact. - Change
uses: actions/upload-artifact@v4touses: actions/upload-artifact@<full-commit-sha>and keep the version as a comment, for exampleuses: actions/upload-artifact@<full-commit-sha> # v4.x.x. - Get the SHA from the official
actions/upload-artifactrelease you intend to use, and make sure it is exactly 40 hexadecimal characters. Pinning to a commit SHA prevents the action owner from silently changing what code runs behind a tag likev4. - Leave the existing
with:settings unchanged unless you are intentionally upgrading to a different release with different inputs.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by github-actions-mutable-action-tag.
If this is a critical or high severity finding, please also link this issue in the #security channel in Slack.
You can view more details about this finding in the Semgrep AppSec Platform.
| echo "value=$ARGS" >> "$GITHUB_OUTPUT" | ||
|
|
||
| - name: Run Claude (Bedrock) | ||
| uses: anthropics/claude-code-action@v1 |
There was a problem hiding this comment.
Semgrep identified a blocking 🔴 issue in your code:
GitHub Actions step uses mutable tag @v1 instead of a pinned commit SHA, allowing silent code injection attacks if the action repository is compromised.
More details about this
The GitHub Actions step uses anthropics/claude-code-action@v1, which references a mutable tag instead of a pinned commit SHA.
Exploit scenario:
If an attacker compromises the anthropics/claude-code-action repository or gains the ability to move the v1 tag, they can silently inject malicious code into the tag. Here's how:
- Attacker gains access to the
anthropicsrepository and updates thev1tag to point to a new malicious commit - The next time this workflow runs, GitHub retrieves the action at the new tag pointer without any warning to users
- The malicious action executes in your workflow with access to all environment variables, including
AUTODOC_DOTCMS_API_TOKEN_AISEARCH,AUTODOC_DOTCMS_API_TOKEN_DRAFTING,AUTODOC_DOTCMS_BASE_URL, andAUTODOC_DOTCMS_SITE_FOLDER - The attacker's code exfiltrates these secrets or executes arbitrary commands with your AWS credentials (from the
configure-aws-credentialsstep) - Your DotCMS instance is compromised or your AWS environment is used for further attacks
This is a real attack vector—trivy-action and kics-github-action were both compromised this way. Pinning to a specific commit SHA ensures the action code cannot change without explicit review and update.
To resolve this comment:
✨ Commit fix suggestion
| uses: anthropics/claude-code-action@v1 | |
| uses: anthropics/claude-code-action@0123456789abcdef0123456789abcdef01234567 # TODO: replace with the verified 40-character commit SHA for the exact anthropics/claude-code-action release you intend to trust (previously @v1) |
View step-by-step instructions
-
Replace the mutable version tag in the
usesline with a full 40-character commit SHA foranthropics/claude-code-action.
Changeuses: anthropics/claude-code-action@v1touses: anthropics/claude-code-action@<full-commit-sha>. -
Keep the current version as a comment after the SHA so the workflow stays readable, for example
uses: anthropics/claude-code-action@<full-commit-sha> # v1.x.y. -
Get the SHA from the exact release or revision you intend to trust on the action's GitHub repository, and pin to that specific commit instead of a branch or tag. This prevents the referenced code from changing without an explicit update.
Alternatively, if you need to keep using a local action, replace the remote reference with a local path such as uses: ./.github/actions/claude-code-action, which is not affected by tag retargeting.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by github-actions-mutable-action-tag.
If this is a critical or high severity finding, please also link this issue in the #security channel in Slack.
You can view more details about this finding in the Semgrep AppSec Platform.
| uses: actions/checkout@v4 | ||
|
|
||
| - name: Configure AWS credentials (OIDC) | ||
| uses: aws-actions/configure-aws-credentials@v4 |
There was a problem hiding this comment.
Semgrep identified a blocking 🔴 issue in your code:
Action reference uses mutable version tag v4 instead of a pinned commit SHA, allowing silent injection of malicious code into your workflow.
More details about this
The step uses: aws-actions/configure-aws-credentials@v4 references the action using a mutable version tag (v4) instead of a pinned commit SHA. This allows the maintainer of aws-actions/configure-aws-credentials to silently push new code to the v4 tag at any time—including malicious code—without your workflow changing or anyone noticing.
Attack scenario:
- An attacker compromises the GitHub account or credentials of the maintainer of
aws-actions/configure-aws-credentials. - The attacker pushes malicious code to the
aws-actions/configure-aws-credentialsrepository (e.g., code that exfiltrates AWS credentials). - The attacker updates the
v4tag to point to the new malicious commit. - Your next workflow run pulls and executes the malicious code from the updated
v4tag. Since your job has permissions to assume an IAM role (role-to-assume: ${{ inputs.bedrock_role_arn }}), the compromised action gains access to AWS credentials and can abuse those permissions. - The attacker now has AWS access and can read/modify resources in your AWS environment.
This supply-chain attack vector is well-documented—the trivy-action and kics-github-action compromises both exploited mutable version tags in this exact way.
To resolve this comment:
✨ Commit fix suggestion
| uses: aws-actions/configure-aws-credentials@v4 | |
| uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502 # v4 |
View step-by-step instructions
-
Replace the mutable version tag in the
usesline with the full 40-character commit SHA foraws-actions/configure-aws-credentials.
Changeuses: aws-actions/configure-aws-credentials@v4touses: aws-actions/configure-aws-credentials@<full-commit-sha>. -
Keep the current release version in a comment after the SHA so the workflow stays readable, for example
uses: aws-actions/configure-aws-credentials@<full-commit-sha> # v4.x.x. -
Get the correct SHA from the action's release you intend to trust on the action's GitHub releases or tags page, and pin that exact commit instead of the tag name. Pinning to a commit SHA prevents the referenced action from changing without an explicit workflow update.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by github-actions-mutable-action-tag.
If this is a critical or high severity finding, please also link this issue in the #security channel in Slack.
You can view more details about this finding in the Semgrep AppSec Platform.
|
|
||
| steps: | ||
| - name: Checkout repository | ||
| uses: actions/checkout@v4 |
There was a problem hiding this comment.
Semgrep identified a blocking 🔴 issue in your code:
GitHub Actions step uses mutable version tag v4 instead of a pinned commit SHA, allowing maintainers to silently update the action to malicious code.
More details about this
The GitHub Actions step uses: actions/checkout@v4 uses a mutable major version tag instead of pinning to a specific commit SHA. This means the v4 tag can be silently repointed by the maintainers of actions/checkout at any time without any notification to you.
Exploit scenario:
- An attacker compromises the GitHub account of an
actions/checkoutmaintainer or gains access to the repository - The attacker repoints the
v4tag to a malicious commit that they control - When your workflow runs, it pulls the malicious version instead of the expected one
- The malicious code in the compromised action executes in your workflow with access to your repository, secrets, and build environment
- The attacker could steal your
AUTODOC_DOTCMS_API_TOKEN_*secrets, modify your repository content, or use your CI/CD pipeline to attack downstream projects
This is a supply-chain attack vector—similar to the real-world compromises of trivy-action and kics-github-action that occurred by exploiting mutable action references.
To resolve this comment:
✨ Commit fix suggestion
| uses: actions/checkout@v4 | |
| uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608 # v4.2.2 |
View step-by-step instructions
-
Replace the mutable action tag with a full 40-character commit SHA in the
usesline.
Changeuses: actions/checkout@v4touses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608 # v4.2.2. -
Keep the version comment after the SHA so the pinned release is still easy to understand and update later.
Use the formatuses: actions/checkout@<40-char-sha> # v4.2.2. -
If you need a different
actions/checkoutrelease thanv4.2.2, get the commit SHA for that exact release from the action’s GitHub release or tag page, and pin it the same way instead of using@v4or any other tag.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by github-actions-mutable-action-tag.
If this is a critical or high severity finding, please also link this issue in the #security channel in Slack.
You can view more details about this finding in the Semgrep AppSec Platform.
| AUTODOC_DOTCMS_API_TOKEN_AISEARCH: ${{ secrets.AUTODOC_DOTCMS_API_TOKEN_AISEARCH }} | ||
| AUTODOC_DOTCMS_API_TOKEN_DRAFTING: ${{ secrets.AUTODOC_DOTCMS_API_TOKEN_DRAFTING }} | ||
| AUTODOC_DOTCMS_BASE_URL: ${{ secrets.AUTODOC_DOTCMS_BASE_URL }} | ||
| AUTODOC_DOTCMS_SITE_FOLDER: ${{ secrets.AUTODOC_DOTCMS_SITE_FOLDER }} |
There was a problem hiding this comment.
is this really a secret? might make debug and tracing easier if it's just a variable.
2 participants
Summary
autodoc-executor.yml, a purpose-built reusable workflow for the dotCMS documentation audit pipeline (issue_autodoc.ymlindotCMS/core)AUTODOC_*secrets as env vars so Claude can call the dotCMS AI search and workflow APIs during execution/tmp/autodoc-report.md) as an artifact for the calling workflow'sfinalizejob to consumeclaude-executor.ymlto avoid adding autodoc-specific secrets and artifact upload to the general-purpose code-review pathWhy a new executor instead of extending
claude-executorclaude-executor.ymlis general-purpose (code review). Autodoc needs two things it doesn't: (1) pass-through ofAUTODOC_*secrets as env vars to Claude, and (2) upload of the written report as an artifact. Grafting those ontoclaude-executorwould pollute it with pipeline-specific concerns.Dependency
dotCMS/coreissue_autodoc.ymlwill reference this at@v3.5.0— please tag after merge.Test plan
v3.5.0dotCMS/corePR (referencesautodoc-executor.yml@v3.5.0)dotCMS/coreand confirm the Actions run completes: OIDC assumption succeeds, Claude writes report, artifact is uploaded, finalize posts comment🤖 Generated with Claude Code