CAI EMPLOYEES: Applying Dependabot Security Fixes

This KB article shows CAI app developers what to do when Dependabot finds a security vulnerability in one of your app's packages. Dependabot scanning is set up when a repo is created (see CAI EMPLOYEES: Creating a GitHub Repo for Your Replit App, Article ID 172317). Alerts arrive by email and are listed on the repo's Security tab.

New vulnerabilities are published every day. When Dependabot finds one in your app, it emails you, and it often has a fix already drafted.

Prerequisite: you need admin access to the repo in the IT-Center-for-Artificial-Intelligence GitHub organization.

1. Open the alert list: in the repo, click Security (or Security and quality) → click View Dependabot alerts.

2. Each row is one vulnerability in one package. Read the row before acting. Three things matter:

• Severity (Critical / High / Moderate / Low): how bad the flaw is in general.
• Development tag, if present: the package is a build-time tool that never runs in front of your users, so the real-world risk is much lower than the severity label suggests.
• Numbers: the gray number right after each alert's title (like #24) is the alert's own ID number. It does not mean a fix exists. If Dependabot has drafted a fix, the row also shows a pull request number at the far right (like #3). One pull request can fix several alerts at once.

To be sure whether a fix exists, click the alert's title. A box at the top that starts with Bump… and has a green Review security update button means the fix is drafted and ready (go to step 3). If you see any other message, go to step 4.

3. If a fix is drafted: Open the Pull requests tab and click the pull request from dependabot. On the pull request's Conversation tab, scroll to the bottom and click Merge pull request, then Confirm merge.

• Merge one pull request at a time, Critical first, then High, Moderate and Low. Wait a minute or two between merges so Dependabot can update the others.
• Before each merge, check that the box at the bottom says No conflicts with base branch. If it says there are conflicts, type @dependabot rebase in the comment box, click Comment, wait a few minutes, then merge.
• A pull request closed as "superseded" is normal. Dependabot moved its fix into a newer pull request. Merge the newer one.

4. If no fix is drafted yet: open the alert and read the message at the top and the Patched version field near the bottom. Then follow the case that matches:

• "Dependabot is creating a security update": a fix is being drafted. Check the Pull requests tab again in about 15 minutes, then merge it as in step 3.
• Patched version listed, with a green Create Dependabot security update button: click the button. Dependabot drafts the pull request within a few minutes (refresh the page or check the Pull requests tab). Then merge it as in step 3.
• "Dependabot cannot update to the required version": the fix is tangled up with other packages, so Dependabot can't make it automatically. Fix it in Replit instead (step 6) by running npm install and then npm audit fix. Never add --force, because it can install old or incompatible versions that break the app.
• The fix needs a new major version (the first number of the version changes, for example multer 1.x to 2.x): Dependabot usually won't make these. Fix it in Replit (step 6) by running npm install <package>@<version>, using the package name and the patched version from the alert, for example npm install multer@2. Then test the feature that package handles (for multer, file uploads).
• A patch exists, but npm says the fix needs --force or is a "breaking change": don't force it. Leave the alert open. This usually happens with build tools such as Tailwind, which run only when the app is built, not in front of users. If asked about it, the status is: "open, fix requires a major upgrade, low risk (build-time only)."
• Patched version: None: the package's maintainers haven't released a fix yet. There is nothing to install, so leave the alert open. Dependabot will automatically draft the pull request the day a patch ships and email you. If asked about it, the status is: "open, no patched version published yet, monitoring."

5. Get a merged fix to the running app. This depends on where the app is hosted:

Azure-hosted apps

1. Click the repo's Actions tab and watch the newest run. Yellow dot = building; green check = success, and the fix is live in Azure; red X = failed. A failed build never deploys, so the previous version keeps running. Contact Center for AI leadership to investigate. A full run takes about 8 minutes.
2. Open the project in Replit → Git pane → Pull, so your Replit copy matches GitHub. One pull picks up all merges since the last one. Skipping this causes conflicts the next time you push from Replit.

Replit-hosted apps (not migrated to Azure): merging only fixed the repository on GitHub. Until you finish these steps, the live app still runs the vulnerable version. These repos usually show no runs on the Actions tab, which is normal.

1. Open the project in Replit → Git pane → Pull. One pull picks up all merges since the last one.
2. In the Shell, run npm install. Pulling updates the files, but not the packages installed in Replit. npm install makes them match.
3. Clean the lockfile (step 7).
4. Test the app in the Replit preview.
5. In the Git pane, commit (for example, Apply npm security fixes) and push.
6. Republish the Replit deployment.

6. Make fixes in Replit (for the cases in step 4 that Dependabot can't fix). Do this in the app's Replit project even if the app is hosted in Azure. Azure installs exactly the package versions listed in GitHub, so the fix reaches Azure when you push.

1. Open the project in Replit → Git pane → Pull.
2. In the Shell, run the command from step 4.
3. Clean the lockfile (step 7).
4. In the Git pane, check the list of changed files. You should see only package.json and package-lock.json. If other files appear, stop and contact Center for AI leadership before pushing.
5. Test the app (step 8), then commit (for example, Apply npm security fixes) and push.
6. Azure-hosted: watch the Actions tab for the green check. Replit-hosted: republish the Replit deployment.

7. Clean the lockfile. Replit writes its own private download addresses into the app's package-lock.json file whenever it installs packages. Only Replit can reach those addresses, so Dependabot and Azure's builds fail until they're swapped for the public npm address. The packages and versions don't change. (For a fuller explanation, see step 9 of CAI EMPLOYEES: Creating a GitHub Repo for Your Replit App, Article ID 172317.)

1. In the Shell, copy this command, paste it as one line, and press Enter. It prints nothing when it works.

   sed -i -E 's#https?://package-firewall\.replit\.[a-z]+/npm/#https://registry.npmjs.org/#g' package-lock.json

2. Copy and paste this check and press Enter. It should show 0.

   grep -c 'package-firewall' package-lock.json

   If you see a Usage: message or a number other than 0, the command didn't paste correctly. Copy it again from the gray box and paste it as one line.

8. Quick test: open the running app, sign in, and make sure it still works as expected, including any feature tied to the updated package. If an app can't run in the Replit preview (for example, an Azure app whose sign-in settings exist only in Azure), test it on Azure after the green check instead.

9. If something breaks after a merge: every merged pull request page has a Revert button. Clicking it undoes that exact change. For Azure-hosted apps, it redeploys the previous version in one build (about 8 minutes). For Replit-hosted apps, after reverting, Pull in Replit and republish. If the problem came from a change you pushed from Replit (step 6), contact Center for AI leadership.

10. Confirm the alert closed: back on Security → Dependabot alerts, the fixed alerts should move to Closed on their own within a few minutes of the merge or push.