Secretz: How a Go Tool Exposed the Dark Side of Travis CI Build Logs

Hook

In 2019, a security researcher discovered that Travis CI's public build logs were a goldmine for attackers—containing AWS keys, database passwords, and API tokens from thousands of open-source projects. The secretz tool automated the harvest.

Context

Continuous Integration platforms revolutionized software development by automating builds and tests, but they also created a massive attack surface. Travis CI, once the dominant CI/CD platform for open-source projects, made build logs public by default. Developers routinely exposed secrets through environment variable misconfiguration, debug output, or accidental echo statements during builds. What should have been ephemeral build artifacts became permanent, searchable records of sensitive credentials.

Manual auditing of CI/CD configurations doesn't scale. A single GitHub organization might have hundreds of repositories, each with dozens or hundreds of builds. Security researchers needed automated tooling to systematically enumerate repositories, fetch build configurations, download logs, and parse them for secrets. The secretz tool emerged from this need—designed specifically to audit the Travis CI attack surface by leveraging their public API to recursively scan organizations and extract potentially sensitive data from build artifacts.

Technical Insight

Secretz implements a worker pool architecture to handle concurrent API requests while respecting rate limits. The core design uses Go's concurrency primitives—goroutines and channels—to orchestrate parallel fetching of repository metadata, build configurations, and log files. The tool maintains configurable delays between requests with jitter to avoid detection and API throttling.

The authentication mechanism stores Travis CI tokens locally and attaches them to every API request. Here's how secretz structures its HTTP client with rate limiting:

// Simplified example of secretz's API client pattern
type TravisClient struct {
    httpClient *http.Client
    token      string
    delay      time.Duration
    lastReq    time.Time
}

func (t *TravisClient) makeRequest(url string) (*http.Response, error) {
    // Enforce minimum delay between requests
    elapsed := time.Since(t.lastReq)
    if elapsed < t.delay {
        time.Sleep(t.delay - elapsed + time.Duration(rand.Intn(1000))*time.Millisecond)
    }
    
    req, _ := http.NewRequest("GET", url, nil)
    req.Header.Add("Travis-API-Version", "3")
    req.Header.Add("Authorization", "token "+t.token)
    
    t.lastReq = time.Now()
    return t.httpClient.Do(req)
}

The tool's recursive enumeration capability is particularly powerful. When pointed at a GitHub organization, secretz first queries Travis CI's API for all organization members, then enumerates repositories for each member, then fetches all builds for each repository. This creates a tree of API calls that can quickly explode into thousands of requests—hence the importance of the rate limiting layer.

Secretz uses json-iterator instead of Go's standard encoding/json for performance gains when parsing large log files and API responses. This is a pragmatic choice since the tool processes potentially gigabytes of JSON data during a comprehensive organization audit. The log parsing itself relies on regex patterns and string matching to identify common secret patterns—AWS keys with their distinctive "AKIA" prefix, private keys with BEGIN/END delimiters, and environment variable assignments that match common credential naming conventions.

The data flow follows this pattern: organization → members → repositories → builds → logs. Each stage filters and narrows the scope. Not every repository uses Travis CI, not every build generates logs, and not every log contains secrets. The tool's efficiency comes from pruning dead branches early while maintaining enough parallelism to make forward progress on productive paths.

One clever architectural decision is the separation of concerns between fetching and parsing. Secretz can optionally save raw build logs to disk, allowing researchers to run custom analysis passes later without re-hitting the Travis CI API. This two-phase approach—harvest then analyze—is common in OSINT tooling where API access might be restricted or rate-limited but local analysis is cheap.

Gotcha

The most significant limitation is temporal. Secretz was built in 2019 when Travis CI's API and security model were fundamentally different. Travis CI has since deprecated v2 of their API, modified authentication mechanisms, and changed how build logs are exposed. The tool may not work at all against modern Travis CI infrastructure without significant modifications. This isn't just a maintenance issue—it's an architectural assumption baked into the codebase.

The tool also requires valid Travis CI credentials, which creates a chicken-and-egg problem. You need API access to audit for secrets, but getting that access requires authentication. This limits secretz to authorized security audits—you can scan your own organization or one where you have permission, but you can't use it for broad reconnaissance against arbitrary targets. Additionally, the tool is Travis-specific. If your organization has migrated to GitHub Actions, CircleCI, GitLab CI, or any other modern CI/CD platform, secretz provides zero value. There's no plugin architecture or abstraction layer that would allow extending it to other platforms without essentially rewriting the entire codebase.

Verdict

Use if: You're conducting authorized security audits of organizations that still actively use legacy Travis CI infrastructure, you have valid API credentials, and you need systematic enumeration of potential secret exposure across many repositories. It's also valuable as a reference implementation if you're building similar OSINT tooling—the rate limiting and worker pool patterns are well-executed examples of how to build respectful API scrapers. Skip if: You're targeting modern CI/CD platforms, need actively maintained tooling with current API support, or want general-purpose secret detection across multiple systems. The narrow focus and age make this more of a historical artifact than a production-ready tool for 2024. Consider truffleHog or gitleaks for contemporary secret scanning needs, or study secretz's source code as inspiration for building your own specialized auditing tools against whatever platform your target uses.