{{ message }}
ci: add Auths cryptographic commit verification (warn-only)#10646
Draft
bordumb wants to merge 6 commits intoaxios:v1.xfrom
Draft
ci: add Auths cryptographic commit verification (warn-only)#10646bordumb wants to merge 6 commits intoaxios:v1.xfrom
bordumb wants to merge 6 commits intoaxios:v1.xfrom
Conversation
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
4 issues found across 4 files
Confidence score: 3/5
- There is a concrete supply-chain risk in
.github/workflows/auths-verify-commits.yml: pinning a third-party action to@v1(mutable) instead of a commit SHA can allow silent behavior changes in commit verification. - The same workflow grants
pull-requests: writeon all triggers, includingpush, which is broader than needed and increases blast radius if a token is misused. examples/security/auths-attack-simulation.mjshas a likely execution regression (HEAD~2..HEAD~1in a two-commit repo) plus platform-specific command assumptions, so verification demos can fail for reasons unrelated to signature logic.- Pay close attention to
.github/workflows/auths-verify-commits.ymlandexamples/security/auths-attack-simulation.mjs- tighten action pinning/permissions and fix brittle revision and platform checks before relying on these flows.
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="examples/security/auths-attack-simulation.mjs">
<violation number="1" location="examples/security/auths-attack-simulation.mjs:36">
P2: POSIX-specific command checks (`which`) and unguarded `ssh-keygen` usage make the example fail on non-POSIX environments for reasons unrelated to Auths.</violation>
<violation number="2" location="examples/security/auths-attack-simulation.mjs:142">
P2: Invalid Git revision range (`HEAD~2..HEAD~1`) for a two-commit repo can cause the legitimate verification step to fail before signature checking.</violation>
</file>
<file name=".github/workflows/auths-verify-commits.yml">
<violation number="1" location=".github/workflows/auths-verify-commits.yml:16">
P2: Job grants `pull-requests: write` on all triggers, including `push`, expanding token privileges beyond what non-PR runs need.</violation>
<violation number="2" location=".github/workflows/auths-verify-commits.yml:25">
P1: Third-party GitHub Action is referenced by mutable tag (`@v1`) instead of immutable commit SHA, weakening workflow integrity and allowing silent behavior changes.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
This was referenced Apr 4, 2026
Contributor
There was a problem hiding this comment.
1 issue found across 3 files (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="examples/security/auths-attack-simulation.mjs">
<violation number="1" location="examples/security/auths-attack-simulation.mjs:126">
P2: Summary status is hardcoded and can report VERIFIED/REJECTED even when runtime verification results differ.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
Contributor
There was a problem hiding this comment.
1 issue found across 3 files (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name=".github/workflows/auths-sign-release.yml">
<violation number="1" location=".github/workflows/auths-sign-release.yml:47">
P2: Third-party GitHub Action is not pinned to an immutable commit SHA. Using `auths-dev/sign@v1` in a job that uses `secrets.AUTHS_CI_TOKEN` allows tag drift or takeover risk; pin to a specific commit SHA for supply-chain safety.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
Contributor
There was a problem hiding this comment.
P2: Third-party GitHub Action is not pinned to an immutable commit SHA. Using auths-dev/sign@v1 in a job that uses secrets.AUTHS_CI_TOKEN allows tag drift or takeover risk; pin to a specific commit SHA for supply-chain safety.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/auths-sign-release.yml, line 47:
<comment>Third-party GitHub Action is not pinned to an immutable commit SHA. Using `auths-dev/sign@v1` in a job that uses `secrets.AUTHS_CI_TOKEN` allows tag drift or takeover risk; pin to a specific commit SHA for supply-chain safety.</comment>
<file context>
@@ -0,0 +1,65 @@
+ run: npm run build
+
+ - name: Sign artifacts with Auths
+ uses: auths-dev/sign@v1
+ with:
+ token: ${{ secrets.AUTHS_CI_TOKEN }}
</file context>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds Auths cryptographic commit verification to the Axios CI pipeline, motivated by the March 31, 2026 supply chain attack against this project.
The problem
The March 31 attack succeeded because there was no cryptographic binding between published npm packages and verified maintainer identity. An attacker compromised a lead maintainer's npm account and used a long-lived access token to publish malicious versions (v1.14.1, v0.30.4) containing a cross-platform RAT. Even though OIDC Trusted Publishing was configured, the publish workflow also passed
NPM_TOKENas an environment variable — npm uses the token when both are present, making OIDC protections ineffective.Neither malicious version appears in the GitHub release tags. The attack existed only in the npm registry.
What this adds
.github/workflows/auths-verify-commits.yml— Runs on PRs and pushes tov1.x. Verifies that commits carry valid Ed25519 signatures from authorized maintainers. Configured in warn-only mode (fail-on-unsigned: false) — reports but does not block..auths/allowed_signers— Placeholder configuration for maintainer public keys, with instructions for activation.examples/security/auths-attack-simulation.mjs— Runnable demonstration of how the March 31 attack vector would be detected by Auths verification.Why this matters
Auths provides Ed25519 signatures bound to KERI-based decentralized identifiers (DIDs). With Auths, every commit carries a signature from the maintainer's cryptographic identity — bound to their device keychain, not a registry account. Stealing npm credentials is insufficient without the signing key.
This complements existing security measures (OIDC Trusted Publishing with
--provenance, zizmor, dependabot) by adding the missing layer of per-commit identity verification.Non-disruptive by design
fail-on-unsigned: falsemeans no impact on existing CITo activate enforcement
brew tap auths-dev/auths-cli && brew install auths(orcargo install auths_cli)auths initauths signers sync --output .auths/allowed_signersfail-on-unsigned: truein the workflow