Release delayed by security finding: how to diagnose and unblock safely

TL;DR — Your release was likely blocked by an automated security scan, a dependency vulnerability, a secrets leak warning, or a failed policy gate in the deployment pipeline. Start with the pipeline/job details in your provider's dashboard, because the most common fix is updating or replacing one vulnerable package version and re-running the release. Reading time: ~6 min

The scenario

It is Tuesday afternoon, the release notes are drafted, QA signed off this morning, and you click the deploy button expecting the usual green check. Instead, the pipeline stops at a step called something like "Security scan", "Policy check", or "Artifact attestation", and the release is marked blocked even though the app itself built successfully. Your team chat starts filling up with screenshots of red badges and terms like CVE (publicly tracked security flaw) and secret exposure. You need to know whether this is a real security problem, a false alarm, or just a rule in the release process that needs a small change.

Symptoms

• Release pipeline shows a failed or blocked step named:
  • Security scan failed
  • Policy evaluation failed
  • Deployment blocked by security gate
  • Artifact failed verification
• Build succeeds, but release/promote step does not start.
• Dependency scan output includes lines like:

Critical vulnerability found in package xyz
CVE-2026-12345 severity: HIGH
Failing build because severity threshold >= high

• Secret scan output includes lines like:

Potential secret detected in commit abc123
AWS_SECRET_ACCESS_KEY detected in config file

• Container/image scan output includes lines like:

Image contains 12 vulnerabilities (2 critical, 4 high)
Base image is end-of-life and no longer receiving security updates

• Signature or provenance (build origin record) checks fail with messages like:

Artifact signature verification failed
No valid attestation found for image

• In the dashboard, the release status may read Blocked, Rejected, Needs approval, or Failed compliance check.

Likely causes

Step-by-step diagnosis

1. Open the failed pipeline in your provider's dashboard.

   • Path: your provider's dashboard → Project/Repository → Pipelines/Actions/Builds → latest failed run.
   • What confirms the problem: one failed step mentions security, policy, scan, signature, or attestation.
   • Jump to: the matching fix section below.

2. Read the first failing security message, not the whole log.

   • In the failed job, scroll to the first red/error line or use the log search box for:

CVE-
secret
signature
attestation
severity threshold

• What confirms the problem:
  • CVE-... or package name/version → go to Vulnerable dependency version.
  • secret detected or a key name → go to Secret or credential was detected.
  • base image or OS package findings → go to Container base image is outdated.
  • blocked by policy or severity threshold → go to Release policy gate is stricter than intended.
  • signature verification failed or no attestation found → go to Artifact signature/provenance verification failed.

1. Check whether the block is in code, in the container image, or only in the release gate.

   • Dashboard path: failed run → Artifacts/Jobs list.
   • What confirms the problem:
     • Build job green, scan job red → likely dependency/image/secret issue.
     • All scans green, deploy job red with policy text → likely release gate or signature issue.
   • Jump to: the relevant fix section.

2. If you have repository access, confirm the exact package or file involved.

   • UI path first: Repository → search for the package name, file path, or secret name shown in the log.
   • CLI option if you use Git locally:

git grep -n "package-name"
git grep -n "AWS_SECRET_ACCESS_KEY\|BEGIN PRIVATE KEY\|api_key"

• What confirms the problem: the same package version or secret-like value appears in your code or config.
• Jump to: the matching fix section.

1. Re-run the pipeline only after changing something.
   • Dashboard path: failed run → Re-run/Retry.
   • What confirms the problem is fixed: the previously failing security/policy step turns green and the release can continue.
   • If it still fails with the same message, return to the same fix section and check whether the change was applied in the branch/tag actually being released.

[Code change] ---- 1. build ----> [CI pipeline]
                                      |
                                      | 2. security scan fails
                                      v
                               [Blocked release]
                                      |
                    3. identify exact finding in logs
                                      v
                              [Apply targeted fix]
                                      |
                                      | 4. re-run pipeline
                                      v
                                [Release proceeds]

Fixes

Vulnerable dependency version triggered the severity threshold

Update the affected package to a fixed version, then rebuild.

• UI path first: Repository → dependency file (package.json, requirements.txt, pom.xml, Gemfile) → edit the version shown in the scan result.
• Common CLI examples:

npm install package-name@latest
pip install --upgrade package-name
poetry update package-name
bundle update package_name

• If the vulnerable package is indirect (pulled in by another package), update the parent package or refresh the lock file:

npm update
npm audit fix
pip-compile --upgrade

• Commit and push the change, then re-run the pipeline.

Verify it worked: the security scan no longer shows that CVE-... line and the release job starts.

Secret or credential was detected in code, config, or build output

Remove the secret from the repository and rotate it (replace the credential so the old one cannot be used).

⚠️ If the secret was real and pushed to a shared repository, treat it as exposed. Rotate it before or at the same time as cleanup.

• UI path first: in your cloud/provider dashboard, create a new key or token and disable the old one.
• Move the secret into your provider's environment variable/secret store: Project → Settings → Environment variables or Secrets.
• Replace hardcoded values in code with environment variable reads. Example:

# .env or provider secret store key
API_TOKEN=replace-me

{
  "scripts": {
    "start": "node server.js"
  }
}

# app reads process.env.API_TOKEN instead of a hardcoded token

• If the secret is already committed, remove it from the current code and commit that change. If your agency handles history rewriting, ask them to purge the secret from Git history as well.

Verify it worked: the next scan does not show Potential secret detected, and the old credential is disabled.

Container base image is outdated or has critical vulnerabilities

Change the base image to a supported, patched tag and rebuild the image.

• Open the Dockerfile in the repository and update the FROM line.
• Example:

FROM node:22-bookworm-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
CMD ["npm","start"]

• Avoid floating to very broad tags like latest if your process requires predictable releases. Prefer a current supported major/minor tag approved by your team.
• Rebuild by pushing the change or re-running the image build job.

Verify it worked: the image scan no longer reports the old base image as end-of-life or critical vulnerabilities tied to that base layer.

Release policy gate is stricter than intended

Adjust the rule only if the finding is understood and the change is approved by your team.

⚠️ Lowering a security gate can let a known risk into production. Record who approved the exception and for how long.

• UI path first: CI/CD or deployment settings in your provider's dashboard → Policies/Rules/Protection settings.
• Look for rules such as:

Block release if severity >= high
Require manual approval for critical findings
Fail if any secret scan finding exists

• Safer options than disabling the gate entirely:
  • change >= high to >= critical
  • add a time-limited exception for one CVE
  • require manual approval instead of automatic block
• If your policy is stored in code, update the threshold there. Example generic JSON:

{
  "block_release_on_severity": "critical",
  "require_manual_approval_on_high": true
}

Verify it worked: the pipeline shows the policy step as passed or waiting for approval instead of hard-failing.

Artifact signature/provenance verification failed

Rebuild the release artifact in the trusted pipeline so it is signed or attested correctly, then promote that artifact.

• Dashboard path first: CI/CD → trusted/default pipeline → run a fresh build from the release commit/tag.
• Confirm the deploy job is using the artifact from that build, not a manually uploaded file or an image built elsewhere.
• If your process uses image signing in CI, re-run the signing step after a successful build. Generic CLI example if your team uses Cosign:

cosign verify <image-reference>

• If verification fails because the artifact came from a different repository or branch than policy allows, rebuild from the approved source branch.

Verify it worked: the deploy/promote job no longer shows signature verification failed or no valid attestation found.

Prevention

1. Add a dependency scan earlier in CI so you find issues before release day.

npm audit --audit-level=high
pip-audit

Run it on every pull request, not only on the release branch.

1. Pin and review your base image in code.

FROM python:3.13-slim-bookworm

Add a monthly task to update the base image tag and rebuild.

1. Store secrets only in your provider's secret manager or environment variable settings.

• Dashboard path: Project → Settings → Environment variables/Secrets.
• Add a pre-commit or CI secret scan. Generic example:

gitleaks detect --source .

1. Set policy gates to match business risk, not maximum strictness by default.

• Example policy file:

{
  "block_release_on_severity": "critical",
  "warn_on_severity": "high",
  "require_manual_approval_on_exception": true
}

Review this quarterly with your agency.

1. Keep a short exception process for urgent releases.

• Record: finding ID, affected package/image, compensating control (temporary risk reduction), approver, expiry date.
• This prevents ad-hoc gate disabling when a client is waiting.

1. Verify artifact origin in the same pipeline that builds it.

• Build, scan, sign, and deploy from one trusted workflow instead of mixing manual uploads and separate build systems.
• If your provider supports it, require deploys to come only from the default protected branch and signed artifacts.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.