How we keep secrets out of your build logs

Almost nobody leaks a secret on purpose. They leak it the way you'd expect: a build script prints an environment variable while debugging, a dependency dumps its config on startup, an error message helpfully includes the token it failed to authenticate with. The secret was never meant to be visible. It just ended up in the log, and the log ended up somewhere it shouldn't.

Build logs are one of the quietest leak vectors in all of software. They're verbose, they're often shared in bug reports and screenshots, and they capture whatever your build process happened to write to stdout. So Triangle masks secrets in your logs automatically — before the text ever reaches your screen, gets stored, or shows up in a link you paste into a ticket.

Two rules, applied to every log line

The masking runs on every line the build emits, and it works on two complementary rules so that neither has to be perfect on its own.

Rule 1: length

Any value 32 characters or longer that appears in a build log is replaced with [REDACTED]. This is a blunt instrument, and that's the point. Real secrets — API keys, signing tokens, session values, connection strings with embedded passwords — are almost always long, high-entropy strings. Human-readable text rarely is. By masking anything past the length threshold, we catch the secrets we've never seen a shape for, including ones from tools that don't exist yet.

Rule 2: known token shapes

Some credentials are dangerous even when they're shorter than 32 characters, so we mask common token shapes regardless of length. If it looks like a credential, it's treated like one:

• sk-… — the classic API secret-key prefix used across many providers.
• ghp_… — GitHub personal access tokens (and their siblings gho_, ghs_).
• AKIA… — AWS access key IDs, which pair with a long secret we catch on length.
• Bearer tokens, JWT-shaped strings, and other recognizable credential formats.

Between the two rules, the coverage is wide: length catches the unknown, shapes catch the short-but-dangerous. A secret has to be both short and unrecognizable to slip through, and real credentials essentially never are.

What it looks like in practice

Here's a build log where a script prints its environment for debugging — the exact scenario that leaks keys in the wild. Notice what reaches your screen:

$ printenv | grep -i key
STRIPE_SECRET_KEY=[REDACTED]
GITHUB_TOKEN=[REDACTED]
AWS_ACCESS_KEY_ID=[REDACTED]
PUBLIC_SITE_NAME=triangle-demo   # short, harmless: left alone

$ echo "connecting with token sk-live-9a...="
connecting with token [REDACTED]
✓ build ready

The sk- value was masked by shape. The Stripe, GitHub, and AWS values were masked by shape or length or both. The harmless public string — a short, readable name — was left exactly as written, because masking everything would make logs useless. Redaction only earns its keep if it's aggressive about secrets and quiet about everything else.

Assume every log line will eventually be pasted into a bug report. Then make sure the ones with secrets in them can be pasted safely.

Why this is the platform's job, not yours

You could, in theory, be careful. Never print an env var, audit every dependency's logging, scrub output before sharing it. But "be careful forever, across every tool you didn't write" is not a security model — it's a wish. The leak always happens on the one line you didn't expect, from the one library you didn't audit, on the one day you were moving fast.

Masking at the platform layer moves the guarantee to where it belongs: below your code, applied uniformly, with no opt-in required. It runs the same whether the secret came from your build script, a noisy dependency, or a stack trace. You don't configure it and you can't forget it.

To be clear about the boundary — redaction is a safety net, not a license to be reckless. Rotate credentials that you know were exposed before masking existed, keep secrets in environment variables rather than committed files, and treat every token as replaceable. But when something does slip toward a log, we'd rather your screen show [REDACTED] than the key itself. The best security feature is the one you never have to remember to turn on.

Theo Marsh works on Developer Experience at Triangle, where the best security feature is the one you never have to think about.