Travis CI Security: Encrypted Variables, Forks and Logs

A Travis CI build has to decrypt your secrets to use them, so the real security questions are which builds receive those secrets, who can read the logs they run in, and how quickly you can rotate them. This guide covers the customer side of using Travis CI on travis-ci.com: encrypted variables in .travis.yml and repository settings, account level variables, the fork pull request settings, build log access and the post job log scan, the HashiCorp Vault integration, SSH keys and Git host permissions, and how to retire a project cleanly. It is written for maintainers of open source and private repositories, DevOps engineers and security reviewers. For controls that apply to any pipeline, see the CI/CD Security Guide.

This is an independent guide from NHI Mgmt Group, based on Travis CI's public documentation as of November 2026. It is not sponsored or reviewed by Travis CI. Product features change, so confirm settings against Travis CI's current documentation.

Key takeaways

Keep fork sharing off unless you need it. Repositories activated after 1 March 2022 default Share encrypted environment variables with forks (PRs) to OFF; check older repositories and keep it off for public projects.
Masking is a safety net, not a guarantee. Travis CI replaces secure values longer than three characters with [secure] in logs, but transformed values, set -x, env and verbose tools can still expose them.
Restrict who reads logs. Turn on Access to logs only for write/push users and leave access to logs older than 365 days off unless there is a reason.
Fetch secrets from your own vault where you can. The HashiCorp Vault integration means only an encrypted Vault token lives in Travis CI, and rotation happens in one place.
Rotate and clean up. Rotate tokens on a schedule, delete logs that leaked anything, and when retiring Travis CI revoke its Git host access and every credential it held.

How identity and access work in Travis CI

Travis CI does not keep a separate permission model for most actions: it relies on your Git host. On travis-ci.com with GitHub, the GitHub Apps integration requests read access to code, metadata and pull requests, and read and write access to administration, checks, commit statuses and deployments. The older OAuth based integration, described as legacy since May 2018, used scopes such as user:email, read:org and repo. Who can push to a repository therefore decides who can change .travis.yml, and that file decides what runs with your secrets.

Actor	How Travis CI recognises them	What they can influence
Repository member with write access	Git host permission	Edit `.travis.yml`, open internal pull requests that receive encrypted variables, see logs when access is limited
Read only user or the public	Git host permission, or anonymous on public repositories	See build logs unless log access is restricted
Fork contributor	External pull request	Trigger builds; receives secrets only if fork sharing settings are ON
Travis CI GitHub App	App installation on the account or organisation	Read code, write statuses and checks on the repositories it is installed on
Automation using the API	Token sent in the `Authorization: token` header	Read repository key pairs, trigger or manage builds, delete logs

Internal and external pull requests

Travis CI builds the merge of a pull request's source branch with its target. The pull request documentation explains why secrets are handled differently: a pull request from a fork (an external pull request) could be changed to print environment variables, and anyone can fork a public repository. By default, encrypted variables and encrypted files are available only to internal pull requests, which only members with write access can open. Encrypted files are never available to fork pull requests.

Admin roles and privileged access

The settings that matter most sit in each repository's Travis CI settings page and in the account settings. Limit who holds admin rights on repositories in the Git host, and review these settings on every repository that holds secrets.

Setting	Documented behaviour	Recommended value
`Share encrypted environment variables with forks (PRs)`	ON: fork to base pull request builds get the base repository's encrypted variables. OFF: such builds fail if they rely on them	OFF, especially for public repositories
`Share SSH keys with forks (PRs)`	Applies to private repositories on travis-ci.com; ON shares custom SSH keys with fork to base pull requests	OFF unless your fork workflow needs private dependencies
`Access to logs only for write/push users`	ON: only users with write or push permission can see job logs, via UI and API	ON for any repository whose builds use secrets
Access to old logs	OFF: logs older than 365 days are unavailable via UI or API	OFF
Environment variable `Display value in build log`	OFF by default; value shows as `[secure]`	Keep OFF for anything sensitive

The fork settings arrived on 1 March 2022. The docs state that repositories activated before that date had encrypted variable sharing set to OFF, while Share SSH keys with forks (PRs) was set to ON for private repositories to avoid breaking builds, so older private repositories deserve a specific review.

Account environment variables

Account level variables are available to every enabled repository under the account, and are never shared with fork pull requests. A repository level variable with the same name overrides the account level one. Because an account variable reaches every repository, including ones a wider group can push to, keep account variables for low sensitivity values and put credentials at repository level, scoped to the repositories that use them.

Integrations, API tokens and service accounts

Every secret a Travis CI build uses is a non-human credential. Pick the storage option by sensitivity and by whether it differs per branch, as the environment variable documentation suggests.

Option	How it works	Use it for
Encrypted variable in `.travis.yml`	`secure:` values encrypted with the repository's RSA public key; only Travis CI holds the private key	Secrets that are the same on all branches and should travel with the code
Repository settings variable	Stored encrypted, hidden from the `export` line by default; can be limited to a branch	Secrets that differ per branch, such as production deploy keys on the main branch only
Encrypted file	`travis encrypt-file` uses AES-256 and stores the key and IV as secure variables	Key files and config files; decrypt for the shortest time and delete afterwards
HashiCorp Vault integration	An encrypted Vault token in `.travis.yml`; named KV2 secrets are pulled at job start and censored in logs	Organisations that want central rotation and access control

Repository key pairs: Travis CI generates an RSA key pair per repository. Anyone who can read the public key can encrypt values for that repository, but only Travis CI can decrypt them. This means a secure: value proves nothing about who added it; review encrypted values in pull requests like any other change.
Vault token scope: the Vault integration requires a Vault instance reachable from the public network (Travis CI publishes its IP addresses), a KV2 engine and a token encrypted with the Travis CLI. Travis CI recommends limiting the token to the projects the build needs; we also suggest a short token TTL and a dedicated Vault policy per repository.
SSH keys for private dependencies: a deploy key reaches a single repository; a user key reaches every repository the user can access. Travis CI documents both. Where you use a user key, create a dedicated machine user with access to only the dependency repositories. See the SSH Key Management Guide.
Deployment credentials: deploy providers take API keys that should be encrypted values or branch scoped settings variables, limited to the deploy branch. Use the narrowest token the target platform offers.
Travis CI API tokens: requests to the API can carry a token in the Authorization: token header. Treat it as a personal credential, keep it out of repositories, and prefer a dedicated account for automation.
GitHub App installation: install the Travis CI GitHub App on selected repositories rather than all, and review the installation list when projects move. See How to audit GitHub Apps and OAuth Apps in an organisation.

Logging and detection

Build logs are the most common place a CI secret leaks. Travis CI filters secure variables and tokens longer than three characters at runtime and shows [secure] instead, and the docs add that the beta Windows support does not obfuscate secure variables. Travis CI also runs a mandatory post job log scan with Trivy and detect-secrets on the raw log; when it finds a potential secret, the web UI shows log scan: failing on the repository page and dashboard for seven days.

Leak path named in the docs	Prevention
`set -x` or `set -v` in shell scripts	Remove tracing from scripts that handle secrets, or turn it off around those lines
`env` or `printenv`	Never dump the environment in CI; print only named, non secret variables
Echoing secrets or tools that print them on error (for example `php -i`)	Review build scripts and test tools for debug output
`git fetch` or `git push` with a token in the URL	Redirect output to `/dev/null` as the docs show, or use a credential helper
String escaping mistakes and verbose flags	Escape Bash special characters in values and keep verbosity low

What to do when a log scan fails

Review .travis.yml and called scripts for unencrypted secrets or debug output, as the Travis CI docs recommend.
If a real secret is exposed, revoke or rotate it at the issuing service first.
Remove the log with the Remove log button, the Travis CLI or the API's log delete endpoint.
Fix the script that caused the leak and re-run the job to confirm the scan passes.

Metrics to track (our suggestions): repositories with fork sharing ON (target zero for public projects); repositories with secrets where log access is limited to write users (target 100 percent); open log scan warnings and median time to rotate after a confirmed leak; age of each deploy token and Vault token; repositories still using account level variables for credentials.

Hardening baseline

The steps below are NHI Mgmt Group recommendations, built on the vendor settings described above.

Inventory: list every repository active on Travis CI, its encrypted variables, settings variables, account variables, encrypted files, SSH keys and the external services they unlock.
Settings sweep: set both fork sharing settings to OFF, turn on Access to logs only for write/push users, keep old log access OFF and confirm no sensitive variable has Display value in build log enabled. If a fork based workflow breaks, re-enable sharing only on that private repository, with a recorded reason.
Scope secrets: move credentials from account level to repository level, restrict deploy credentials to the deploy branch and replace user SSH keys with deploy keys or a machine user.
Centralise: where possible move secrets to Vault and keep only an encrypted, narrowly scoped Vault token in Travis CI.
Script hygiene: remove set -x, env and token bearing URLs from build scripts, and add a pre merge review of .travis.yml changes through CODEOWNERS.
Rotate: rotate tokens and secrets on a schedule (we suggest at least every 90 days for deploy credentials) and immediately when maintainers leave. The Travis CI docs remind users to rotate GitHub OAuth tokens in Developer Settings too.

Decision guidance

Public open source project: keep fork sharing off, run builds that need secrets (publishing, deployment) only on the default branch or tags, and accept that fork pull requests run without secrets.
Private repositories with trusted collaborators: the docs suggest running builds that need secrets in private repositories with a reviewed collaborator list; fork sharing can be considered where every fork owner is trusted.
Organisation with a secret platform: use the Vault integration so Travis CI holds one token per repository rather than many long lived secrets.

Retiring Travis CI for a project

When a project moves to another CI service, or stops building, decommission the Travis CI side deliberately so that no credentials outlive it. Note that travis-ci.org was disabled in June 2021, so any references to it in old badges, scripts or documentation point at a service that no longer runs.

Rotate every secret that Travis CI held, at the issuing service, rather than copying the old values to the new system.
Delete repository and account variables, and remove secure: entries and .enc files from the repository once they are no longer used.
Remove deploy keys and machine user keys that Travis CI used from the Git host.
Uninstall the Travis CI GitHub App from the repository or organisation, or revoke the legacy OAuth authorisation, and deactivate the repository in Travis CI.
Revoke Travis CI API tokens and Vault tokens, and remove Travis CI IP addresses from any allowlists, such as on your Vault instance.

Common misconfigurations

Fork sharing ON for a public repository: any fork pull request build can read the base repository's encrypted variables.
Older private repositories with SSH key sharing ON: the 2022 defaults left this ON for private repositories activated earlier.
Public logs for builds that use secrets: with default log settings, anyone with read access, which on public repositories means everyone, can read up to 365 days of job logs.
Credentials as account variables: they reach every enabled repository under the account.
Guessable secrets: the docs warn against secrets related to the repository or branch name; generate them with a password tool.
Leaving credentials behind after migration: old tokens stay valid until revoked, even if Travis CI no longer builds the project.

Framework mapping

Control area	NIST SP 800-53 Rev 5	MITRE ATT&CK risk addressed	OWASP CI/CD Top 10
Fork sharing settings, branch scoped variables	AC-6 Least Privilege, CM-3 Configuration Change Control	T1195.002 Compromise Software Supply Chain	CICD-SEC-4 Poisoned Pipeline Execution
Encrypted variables, Vault integration, rotation	IA-5 Authenticator Management	T1552.001 Credentials In Files	CICD-SEC-6 Insufficient Credential Hygiene
Log access limits, log scan follow up	AU-2 Event Logging, AC-6 Least Privilege	T1552.001 Credentials In Files	CICD-SEC-10 Insufficient Logging and Visibility
GitHub App scope, deploy keys, decommissioning	AC-6 Least Privilege, IA-5 Authenticator Management	T1528 Steal Application Access Token, T1199 Trusted Relationship	CICD-SEC-8 Ungoverned Usage of Third-Party Services

Practitioner checklist

Set Share encrypted environment variables with forks (PRs) to OFF on every repository unless a recorded need exists.
Check Share SSH keys with forks (PRs) on private repositories activated before 1 March 2022.
Turn on Access to logs only for write/push users and keep old log access OFF.
Keep Display value in build log OFF for every sensitive variable.
Move credentials from account level to repository level and restrict deploy secrets to the deploy branch.
Use the Vault integration with a narrowly scoped, short lived token where you run Vault.
Remove set -x, env dumps and token bearing Git URLs from build scripts.
Act on every log scan: failing warning: rotate, remove the log, fix the script.
Install the Travis CI GitHub App on selected repositories only and review the list quarterly.
When retiring Travis CI, rotate all secrets, remove keys and uninstall the App.

Travis CI Security: Protect Encrypted Variables, Fork Builds and Build Logs