The Problem: Every New Tool Expands Your Attack Surface

A mature DevOps practice depends on a broad set of tools — CI/CD servers, artifact repositories, container orchestrators, secret managers, and monitoring stacks — each wired together across the delivery pipeline. That interconnection is a strength, but it creates a compounding security risk. Every new tool you add is a potential entry point for an attacker, and in many organisations these tools are deployed by development or operations teams without direct oversight from security.

A study by threat intelligence firm IntSights examined just how exposed these tools are in practice. Rather than using exploit frameworks or active attack tools, the researchers relied entirely on OSINT (Open Source Intelligence) techniques: searching for predictable hostnames like jenkins.example.com, nexus.example.com, or kibana.example.com across a curated list of organisation domains. No vulnerabilities were exploited; the researchers simply knocked on publicly visible doors.

What the Research Found

The research compiled a list of approximately 26,000 URLs and subdomains by combining known DevOps tool names with the domains of various organisations. Every server that returned a live, valid HTTP response was classified as an open server and subjected to further investigation to assess what security controls — if any — were in place.

The headline finding: roughly 23.6% of tested URLs — approximately 5,967 out of 25,876 — were accessible from the public internet. The level of exposure varied:

• No authentication at all. Some services were fully open. One example cited is an Elasticsearch instance — a distributed search and analytics engine that ships with no authentication enabled by default. Elasticsearch nodes frequently index logs, application events, and security data, making them high-value targets. An open, unauthenticated instance can expose that entire dataset to anyone who finds it.
• Weak or default credentials. Other services did require a login, but relied on weak password policies or factory-default credentials that are publicly documented. Jenkins automation servers were flagged specifically: automated build tools often store or expose credentials in build logs, environment variables, or pipeline scripts, providing attackers with a foothold for lateral movement.
• Application-level authentication only. Many tools were protected only by whatever login screen the application itself provides, with no network-layer controls such as IP allowlisting or VPN requirements.

Why DevOps Tools Are High-Value Targets

DevOps tooling is attractive to attackers for several reasons beyond simple data theft:

• Privileged access to production. A compromised CI/CD server can inject malicious code directly into build artefacts, which are then deployed to production environments. This is a supply-chain attack vector.
• Hardcoded secrets. Build pipelines routinely handle API keys, cloud credentials, and signing certificates. These are often embedded in environment variables or log output that is visible through the tool’s web interface.
• Broad network visibility. Tools like Kubernetes dashboards, Elasticsearch, and monitoring stacks often have broad read access to internal systems, making them useful pivot points once compromised.
• Trusted by internal teams. Traffic from a CI server is often implicitly trusted by firewalls and internal services, meaning that a compromised build agent can move laterally with few obstacles.

How to Reduce the Exposure of Your DevOps Infrastructure

1. Stop Using Predictable Hostnames

The IntSights study was built on the assumption that organisations use obvious naming conventions such as jenkins.company.com or gitlab.company.com. Avoiding these predictable patterns removes your infrastructure from the easiest OSINT scans. This is security through obscurity and should not be your only control, but it reduces passive discovery.

2. Remove Public Internet Exposure Entirely

The strongest mitigation is to ensure DevOps tools are not reachable from the public internet at all. Place them on private networks and require a VPN or Zero Trust Network Access (ZTNA) solution for remote access. Non-default ports add minor friction but should not be treated as a real security control.

3. Enforce Multi-Factor Authentication

Most major DevOps platforms — Jenkins, GitLab, GitHub, Artifactory, and others — support MFA or can be placed behind an identity provider that enforces it. Enabling MFA is one of the most effective mitigations against credential-based attacks, including those that exploit default or weak passwords.

4. Audit and Harden Default Configurations

Many tools ship in an insecure default state — Elasticsearch being a prominent example, though it has added security defaults in more recent major versions. Before any tool reaches a network-connected environment, review its security configuration against a published hardening guide or CIS benchmark. Pay particular attention to:

• Authentication settings (ensure they are enabled and enforced)
• Network binding (listen on localhost or private interfaces, not 0.0.0.0)
• Default usernames and passwords
• Exposed admin APIs or management endpoints

5. Apply Continuous Configuration Monitoring

Even a correctly hardened server can drift back to an insecure state after a software update, a manual change, or a misconfigured deployment script. Continuous monitoring of file integrity and configuration state — using tools purpose-built for this task — gives you early warning when a system deviates from its known-good baseline. This is particularly important for container orchestration tools like Docker and Kubernetes, which have significant configuration complexity.

6. Scan Your Own Perimeter Regularly

Run periodic vulnerability and network scans against your internet-facing infrastructure. This tells you what services are actually visible externally — often revealing tools that were inadvertently exposed during infrastructure changes. Treat the results the same way an attacker would: if you can see it from the internet, so can they.

Security Must Follow the Toolchain

There is a natural focus in DevSecOps on securing what you ship — scanning container images, running SAST/DAST against application code, checking dependencies for known vulnerabilities. That work is important, but the IntSights research is a useful reminder that the infrastructure running your pipeline deserves the same level of scrutiny. A compromised Jenkins server can silently undermine every security gate you have placed downstream of it.

As you grow your DevOps toolchain — adding build servers, integration platforms, testing suites, secrets managers, and monitoring stacks — apply the same hardening, access control, and monitoring disciplines to those tools that you would to any production system. The attack surface grows with every addition; the security programme needs to keep pace.