[SECURITY] Remove vulnerabilities from GH workflows

[John McCall (lowlydba)]

Context

See #467 for findings that we need to remediate.

Changes

• 🔒 Replace pull_request_target with pull_request in check-python-code.yaml and check-python-package-versions.yaml - neither workflow requires the elevated permissions that pull_request_target grants, and its use created a path for contributors to execute arbitrary code with AWS IAM credentials

  • An artificial touch to one of the project files triggered these modified jobs as a sanity check

    

• 🔒 Remove the now-redundant same-repo if guards from both workflows

• 🔒 Mask CodeArtifact auth tokens before writing to $GITHUB_OUTPUT in reusable-check-python-package-versions.yaml and publish-python-packages.yaml

• 🔒 Pass sensitive values via env: into consuming steps rather than direct ${{ steps.*.outputs.* }} interpolation in run: scripts

• ♻️Updated blessed GHA providers (github, astral) to current major versions

  • Configure dependabot to keep GHA updated going forward

• 🧑‍🦲 Stubbed out a CODEOWNERS

  • We'll spend more time figuring out more complex ownership paths, but this gets the initial file committed and sets myself & public reviewers for the .github directory to ensure smooth, safe changes to CI/CD for this public repository
  • This is not a required reviewer at this time, or scheduled for a future date to become one

[Copilot]

Pull request overview

Hardens this repository’s GitHub Actions configuration to mitigate workflow-trigger and credential-leak risks identified in issue #467, while also adding basic ownership/automation scaffolding for safer ongoing CI/CD maintenance.

Changes:

• Switch Python PR workflows from pull_request_target to pull_request and remove same-repo guards.
• Mask CodeArtifact-derived credentials/URLs and pass them via env instead of inline interpolation.
• Add Dependabot config for GitHub Actions updates and introduce an initial CODEOWNERS.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
CODEOWNERS	Adds initial ownership for .github changes.
.github/workflows/test-schema.yaml	Updates core GitHub actions used in the Go schema validation workflow.
.github/workflows/reusable-check-python-package-versions.yaml	Updates action versions, switches Python version sourcing, and masks CodeArtifact index URL before output/usage.
.github/workflows/publish-python-packages.yaml	Adds workflow_dispatch and masks CodeArtifact token before output/usage; passes sensitive values via env.
.github/workflows/check-python-package-versions.yaml	Switches trigger to pull_request and removes same-repo guard while calling the reusable workflow.
.github/workflows/check-python-code.yaml	Switches trigger to pull_request, removes same-repo guard, and updates checkout action usage.
.github/dependabot.yml	Adds weekly Dependabot updates for GitHub Actions.

Comments suppressed due to low confidence (1)

.github/workflows/publish-python-packages.yaml:16

• workflow_dispatch defines inputs (e.g., aws_iam_role_name, domain, repository) but the workflow continues to use hard-coded values later (account/region/domain/repo/role). Either wire these inputs into the AWS configure step and CodeArtifact script invocations, or remove the unused inputs to avoid misleading operators.

  workflow_dispatch:
    inputs:
      aws_iam_role_name:
        description: The name of the IAM role to assume for accessing CodeArtifact
        type: string
        required: false
        default: GithubActions_Schema_CodeArtifact_Publish
      domain:

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

[Victor Schappert (vcschapp)]

Thanks for this John. I'll get chance to look at it eventually, but help me with the first bullet:

• 🔒 Replace pull_request_target with pull_request in check-python-code.yaml and check-python-package-versions.yaml - neither workflow requires the elevated permissions that pull_request_target grants

Let's make sure this is true. The reason pull_request_target was chosen is that the workflows are intended to use the repo base commit - it's how they determine the base versions of the packages and whether they have changed. If they instead use the pull_request base commit, it's not clear to me that they'll be able to identify the right versions.

and its use created a path for contributors to execute arbitrary code with AWS IAM credentials

The IAM roles that can be assumed are very defensively scoped; one is read-only, and the only thing the other can do is publish to the Python sub-repo of CodeArtifact.

[John McCall (lowlydba)]

• 🔒 Replace pull_request_target with pull_request in check-python-code.yaml and check-python-package-versions.yaml - neither workflow requires the elevated permissions that pull_request_target grants

Let's make sure this is true. The reason pull_request_target was chosen is that the workflows are intended to use the repo base commit - it's how they determine the base versions of the packages and whether they have changed. If they instead use the pull_request base commit, it's not clear to me that they'll be able to identify the right versions.

Yeah, that can be achieved without using an elevated context that pull_request_target gives. The workflow already bifurcates its work across before/after commits:

schema/.github/workflows/reusable-check-python-package-versions.yaml

Lines 69 to 72 in 39a24f2

	- name: Check out code before change
	uses: actions/checkout@v6
	with:
	ref: ${{ inputs.before_commit }}

schema/.github/workflows/reusable-check-python-package-versions.yaml

Lines 85 to 88 in 39a24f2

	- name: Check out code after change
	uses: actions/checkout@v6
	with:
	ref: ${{ inputs.after_commit }}

There are a few use cases for pull_request_target but (thankfully) it isn't required here!

[Victor Schappert (vcschapp)]

The workflow already bifurcates its work across before/after commits

Right, but the content of the before commit is important. It should reflect the state of the current state of the branch in the official repo, not any state that comes with the PR. Can you confirm that's true?

[John McCall (lowlydba)]

The workflow already bifurcates its work across before/after commits

Right, but the content of the before commit is important. It should reflect the state of the current state of the branch in the official repo, not any state that comes with the PR. Can you confirm that's true?

Yes, this is the core functionality of GitHub's checkout action and in this case is not affected at all by the change in event trigger:

• Check out code before changes: 7162a0de6ea9317102cd28176ee441c9b3850a8c --> [REFACTOR](core) Convert StrippedConstraint to PatternConstraint subclass #466 which was the last merged PR as of writing
• Check out code after changes: 5f8baeea507117856eba0b12708a0007c52de3c4 --> 5f8baee Last commit on this PR

[Adam Lastowka (Rachmanin0xFF)]

LGTM; I'm no workflow wizard but it seems like Vic's concerns were addressed + the workflow updates make sense

[John McCall (lowlydba)]

Victor Schappert (@vcschapp) I've added some specifics about your concerns - can you take another look? Happy to set up some time to review in person if that is helpful.