Vercel now redacts secrets in build logs: treat [REDACTED] as a guardrail, not a boundary

Tech

The moment a build prints DATABASE_URL or an API token, the secret no longer lives only in an environment-variable store. It can spread to a copyable web view, a Log Drain, a support ticket, or a CI archive. Since July 9, Vercel replaces a Sensitive Environment Variable value with REDACTED in deployment build logs when the value is at least 32 characters long. That is useful defense in depth, but reading it as ‘our secrets are now safe’ hides the most important gaps.

Security-boundary diagram for Vercel deployment secrets across classification, injection, build-log redaction, Activity Log evidence, and credential rotation
Automatic redaction is the last safety net. Classification, minimum injection, safe output, exposure detection, and rotation must surround it.

What changed

Vercel's guarantee is deliberately specific: a value marked Sensitive and at least 32 characters long is replaced in build logs. The Build Logs view indicates that masking occurred. The Activity Log records the key, project, and deployment, but not the value. Vercel also masks selected system Environment Variables used for deployment security.

This is not a universal DLP engine for every environment variable, length, or representation. The documented guarantee covers the exact value under those conditions. Do not assume that a short token, a substring, an encoded form, or a newly composed credential will be removed unless your own test proves it.

Sensitive mode is available only for Preview and Production. An existing normal variable must be removed and re-added with Sensitive enabled. Environment-variable changes apply to the next deployment, so reclassification does not retroactively change old deployments.

Redaction does not replace storage, authorization, or rotation

Log masking reduces damage after a value reaches an output path. The earlier question is why the build process could read the secret at all. Runtime-only credentials should not be injected into package installation, static generation, or unrelated build plugins.

A Sensitive value becomes unreadable after creation in Vercel's management surface, but the application still needs to use it at runtime. Masking one console path cannot stop a malicious dependency, compromised plugin, or generated script from sending a value over the network. Display redaction and execution-context isolation are different controls.

Vercel's April 2026 security bulletin disclosed that non-Sensitive environment variables were enumerated and decrypted, and advised customers to rotate those values. The July changelog does not claim that build-log redaction is a direct consequence of that incident. Together, however, the documents reinforce one operational lesson: the label ‘environment variable’ does not automatically assign a secret class. Teams must explicitly classify and rotate credentials.

Model deployment logs as a separate data flow

First, classify variables at the source of truth as public config, internal config, or credential. A value shipped in a client bundle is not secret. Database URLs, signing keys, and provider tokens should be Sensitive in Preview and Production, with an owner and rotation objective.

Second, split injection by phase. Package installation, static builds, server runtime, and one-off migrations rarely need the same credentials. Use separate Preview credentials rather than cloning Production access.

Third, inventory every output path: Vercel Build Logs, GitHub Actions, cache metadata, error trackers, Log Drains, artifacts, and support tickets. GitHub also warns that structured secret values can make correct redaction harder. A mask in one platform is not proof that downstream stores are clean.

Fourth, log safe evidence instead of values. Presence, an eight-character fingerprint, credential version, target environment, and rotation timestamp normally provide enough debugging context. Replace full connection strings with provider, host class, and structured error codes.

Community signal: secret-manager integrations can lose semantics

A Vercel Community report described a Doppler Restricted variable that became readable after an integration synchronized it to Vercel and could not be converted to Sensitive. Vercel replied that support depended on each integration and suggested temporarily de-syncing and re-adding the value.

That thread is not evidence for the current behavior of every integration. It is a useful audience signal: security labels may not survive system boundaries. Verify whether ‘Restricted’ in the source actually becomes ‘Sensitive’ at the destination, who owns drift, and whether rotation preserves the source of truth.

The real operational question is not whether REDACTED appears once. It is whether teams can enforce Sensitive mode while retaining automated synchronization, rotation, and rollback.

Practical checklist

1. Inventory Production and Preview variable keys and classify every credential candidate with an owner.

2. Rotate credentials that are not Sensitive, then remove and re-add them in Sensitive mode after reviewing dependent deployments and rollback.

3. Decide whether the team-wide Environment Variable Policy should enforce Sensitive mode for new Preview and Production values.

4. Search build commands, install scripts, code generation, and telemetry initialization for full process.env or connection-string output.

5. Test short tokens, JSON credentials, PEM values, URL-encoded forms, and prefix/suffix transformations with canary fixtures.

6. Trace the same canary through GitHub Actions, Log Drains, error trackers, artifacts, and support workflows.

7. Standardize a safe logger that emits key, fingerprint, version, and environment only.

8. If exposure is found, revoke and rotate the credential; deleting a log is not remediation.

9. Test whether external secret-manager integrations preserve Sensitive semantics and document any temporary exception with an expiry.

Risks and counterarguments

Automatic masking does reduce the consequences of accidental output, but short, transformed, or downstream copies can remain outside the documented guarantee. Defense in depth is not permission to print credentials.

Teams sometimes argue that debugging requires the full value. Presence, environment, version, fingerprint, and provider error codes are usually enough. Rare break-glass access should have approval, audit, and expiry instead of using ordinary logs.

Finally, Vercel Sensitive mode does not solve local development. The documentation limits it to Preview and Production, while local env files are plaintext. Developer laptops, shell history, agent tool access, and screen sharing need a separate threat model.

Vercel deployment-secret audit checkpoints

✓Inventory Production and Preview variable keys and classify every credential candidate with an owner.

✓Rotate credentials that are not Sensitive, then remove and re-add them in Sensitive mode after reviewing dependent deployments and rollback.

✓Decide whether the team-wide Environment Variable Policy should enforce Sensitive mode for new Preview and Production values.

✓Search build commands, install scripts, code generation, and telemetry initialization for full process.env or connection-string output.

✓Test short tokens, JSON credentials, PEM values, URL-encoded forms, and prefix/suffix transformations with canary fixtures.

✓Trace the same canary through GitHub Actions, Log Drains, error trackers, artifacts, and support workflows.

✓Standardize a safe logger that emits key, fingerprint, version, and environment only.

✓If exposure is found, revoke and rotate the credential; deleting a log is not remediation.

✓Test whether external secret-manager integrations preserve Sensitive semantics and document any temporary exception with an expiry.

Bottom line

REDACTED is a valuable guardrail, not the end of the boundary. Classify secrets, inject them only into the phase that needs them, record safe evidence, verify every output channel, and rotate immediately after exposure. Build-log security is the quality of that whole data flow—not a single masking feature.

Sources

다른 글