Why your CI/CD alerts are a security risk

The problem nobody talks about

You deploy an app. You add a Slack webhook or a Pushover token to your CI pipeline so you know when builds fail. That token sits in your CI secret store, in your .env file, in a GitHub Actions secret, in your colleague's laptop.

Now think about what that token can do.

What a leaked notification token reveals

Slack webhookCan post to your channel. If it's a bot token, it can read all channel history, list members, and access files. A webhook URL is frequently logged in CI output.

Pushover API tokenCan send notifications. With the user key (which is the same secret), the server has full access to your plaintext messages. Pushover sees everything you send.

ntfy topicAnyone who knows the topic name can read all messages. By default, topics are public and unencrypted. Authentication is optional and server-side.

Telegram bot tokenFull bot API access: read messages, list chats, access files. A leaked bot token is functionally a backdoor into your ops channel.

The deeper problem: the server reads your data

Even without token leaks, every push notification service in the list above receives your alert data in plaintext. The service operator, their infrastructure provider, and anyone who compromises their database can read every alert you've ever sent.

Your CI/CD alerts contain:

Repository names and branch names (internal project structure)
Server hostnames and IP addresses
Error messages with stack traces
Database names and sometimes connection strings
Deploy targets and environment names

This is operational intelligence. You're handing it to a third party in cleartext.

A different model: encrypt before sending

Nerve takes a different approach. The CLI encrypts the signal payload on your machine before it reaches the relay. The relay routes encrypted envelopes. Your phone decrypts locally.

Relay seesEncrypted ciphertext, delivery metadata, timestamps. Not your alert text.

Leaked sender DSNCan send encrypted signals into one pipe. Cannot read history, decrypt old messages, connect as an agent, or execute commands.

Sender vs. AgentSeparate credentials. A CI pipeline only needs a sender DSN. The agent (for signed commands) is a different token with different trust.

The sender isolation principle

In most notification tools, the token that sends can also read. This means a CI secret leak = history leak.

Nerve separates these. A sender DSN is write-only and scoped to one pipe. Even if your GitHub Actions secret leaks tomorrow:

The attacker can post encrypted noise into your pipe (annoying, not dangerous)
They cannot decrypt it (they don't have the recipient key)
They cannot read old messages
They cannot connect as an agent or execute commands
You rotate the DSN from the app and move on

What you should do

Audit your current tokens. How many services can your Slack bot token access? Can your Pushover token read history?
Separate send and read. The system that sends alerts should not have the ability to read them.
Encrypt before transit. If the notification service gets breached, your data should be ciphertext.
Scope tokens narrowly. One token per pipe, per purpose. Not one master key for everything.

Try it

go install github.com/nerve-ink/nerve-cli/cmd/nerve@latest
export NERVE_DSN="nerve://TOKEN:[email protected]"
echo "deploy failed: staging" | nerve send --severity critical

The relay never sees the text "deploy failed: staging". Your phone does.

Your CI/CD alerts are a security risk.