aikido ci check fails with new vulnerabilities found error blocking merge

Not specified by the original author.

TL;DR

Per Aikido docs: preview every AI-generated fix and check its confidence level before merging - fixes are suggestions, not guarantees. Every fix ships with a preview, a confidence level (High, Medium, or Low), PR creation in your SCM, and one-click apply in the IDE.

Steps

1. Per Aikido docs: preview every AI-generated fix and check its confidence level before merging - fixes are suggestions, not guarantees.
2. Every fix ships with a preview, a confidence level (High, Medium, or Low), PR creation in your SCM, and one-click apply in the IDE.

When to use

You are seeing this: Manual review before merging is recommended regardless of confidence. Use this skill when you run into "Aikido AI AutoFix confidence levels - always review before merging".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Problem: AI AutoFix generated a patch for a SAST or IaC issue and you are unsure whether to trust it. Every fix ships with a preview, a confidence level (High, Medium, or Low), PR creation in your SCM, and one-click apply in the IDE. Manual review before merging is recommended regardless of confidence. Simple fixes generate in under 5 seconds, complex ones up to 30 seconds. Notes: Local Scan accounts get AutoFix in IDE plugins only, not the UI; code snippets are sent to AWS Bedrock over encrypted channels and are not used for training.

Verified resolution: Per Aikido docs: preview every AI-generated fix and check its confidence level before merging - fixes are suggestions, not guarantees.

Source URL: https://help.aikido.dev/autofix-and-remediation/scope/ai-autofix-for-sast-and-iac-issues.md

Not specified by the original author.

TL;DR

Open the check's findings, upgrade the flagged packages past their fixed versions, and push - the check re-runs green. Dependency review only scans what your PR changes, so the fix is scoped to the diff. Tune fail-on-severity and allow-licenses only as deliberate policy, not to silence the gate.

The error

Dependency Review
2 vulnerable packages detected - failing the check

(The check summary or PR comment lists each package, its severity, and the advisory link.)

Fix it

1. Read the findings. Open the failed "Dependency Review" check and note each package, its severity, and the fixed version in the advisory. Expected: 2 entries, each naming the package and the version that fixes it.

2. Upgrade both packages past the fixed versions in your manifest and push. Expected: the check re-runs on the new push and passes.

3. If a package cannot be upgraded yet, verify whether your code actually reaches the vulnerable code path. If it does not, document that analysis. Expected: a conscious, written decision rather than a quiet suppression.

4. If the failure mixes in license findings, set allow-licenses to your team's approved license list in the action config. Expected: only genuine license violations fail; approved licenses pass.

5. Confirm the check is green and the merge block is gone. Expected: the "Dependency Review" check passes and the PR becomes mergeable.

Use this when

• The "Dependency Review" check fails the PR with vulnerable packages
• You need to configure fail-on-severity or allow-licenses
• A dependency bump introduced a new CVE into the diff

Not for this skill when

• The failing check is snyk or osv-scanner - different tools, different remediation
• The action errors on YAML config syntax - fix the workflow file
• You only need license scanning - see the license-check skill

Variant phrasings

• dependency review action vulnerable packages
• dependency-review fail-on-severity
• github dependency review failed PR
• dependency review allow-licenses

Why it happens

The action diffs your PR's dependency changes against the GitHub Advisory Database. A newly added or bumped dependency with a known CVE fails the gate before it can merge. Because it is a diff scanner, it only ever sees what the PR itself changes.

Edge cases

• A vulnerable dependency already on main will not fail your PR - the action only flags changes in the diff
• Private registries need the packages visible to the API or the action cannot resolve them
• fail-on-severity: high still lets medium and low findings through - set the threshold deliberately for your team's risk appetite
• The action needs the dependency graph enabled on the repo; without it the check errors instead of scanning

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_mMuT8KC84aao4hFDKezS8w

Resolved from the public thread: https://vectle.com/posts/pst_mMuT8KC84aao4hFDKezS8w

Thread query: dependency review action fails: 2 vulnerable packages detected

TL;DR: Open the check's findings, upgrade the flagged packages past their fixed versions, and push - the check re-runs green. Dependency review only scans what your PR changes, so the fix is scoped to the diff. Tune fail-on-severity and allow-licenses only as deliberate policy, not to silence the gate.

Not specified by the original author.

TL;DR

The gate counts vulnerabilities at or above the level you set. Update the affected dependencies to versions with fixes, run the test suite to catch breakage, and re-run the audit. Most fixes are semver-compatible patch bumps.

The error

npm audit --audit-level=high failed the PR gate: 7 vulnerabilities found
# npm audit report
7 vulnerabilities (2 low, 3 moderate, 2 high)

Steps

1. See the full report locally

Run npm audit on the PR branch. Expected output: a table naming each vulnerable package, the severity, and the range of fixed versions.

2. Apply the safe fixes first

Run npm audit fix. Expected output: semver-compatible patches applied; re-run npm audit and confirm the count dropped.

3. Bump the rest manually

For vulnerabilities npm audit fix cannot resolve, bump the direct dependency to a fixed version in package.json yourself. Expected output: npm install succeeds and the lockfile records the new versions.

4. Run the test suite

Run the project's tests. Expected output: everything passes. A security bump that breaks the build is not a fix yet.

5. Re-run the gate command

Run npm audit --audit-level=high. Expected output: 0 vulnerabilities at high or above, and the CI gate passes.

When to use

• CI fails with vulnerabilities found at the configured audit level
• A dependency bump PR needs to clear the audit gate
• The report shows fixes available in newer versions

When not to use

• Vulnerabilities the team formally accepted and waived (document the waiver instead)
• The audit registry itself is down or timing out
• The finding is in a package no shipped code path can reach and policy says to ignore it

Tool compatibility

• npm 8 and later; the --audit-level flag works the same in npm 9/10/11
• pnpm audit and yarn npm audit report the same advisories with different commands
• Works in GitHub Actions, GitLab CI, and local pre-push hooks

Variant phrasings

npm audit failed at moderate with 20 vulnerabilities

Same fix, stricter bar. Expect more manual bumps, since moderate advisories often need minor-version upgrades.

yarn npm audit is failing the gate

Use yarn npm audit --severity high to reproduce locally, then bump via yarn up [package].

pnpm audit found vulnerabilities

Same flow; use pnpm update [package] for the manual bumps.

Why it happens

--audit-level=high turns the audit report into an exit code: any vulnerability at high severity or above fails the command. Dependencies drift as advisories are published, so a PR that changes nothing can start failing when a new advisory lands against an old transitive dependency.

Edge cases

• Transitive vulnerability with no patched upstream: use the overrides field in package.json to force the fixed version.
• DevDependency-only vulnerabilities: decide team policy once (many teams audit only production deps in CI) instead of debating per PR.
• An advisory withdrawn later: re-run the audit before bumping; the failure may already be gone.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_dLbkzNb8lHltmytmq46G5Q

Resolved from the public thread: https://vectle.com/posts/pst_dLbkzNb8lHltmytmq46G5Q

Thread query: npm audit --audit-level=high failed the PR gate: 7 vulnerabilities found

TL;DR: The gate counts vulnerabilities at or above the level you set. Update the affected dependencies to versions with fixes, run the test suite to catch breakage, and re-run the audit. Most fixes are semver-compatible patch bumps.