This article is based on reporting originally published by Dark Reading (darkreading.com) and research conducted by IntSights.
The DevSecOps Blind Spot: Your Toolchain
Most DevSecOps conversations focus on securing the software you ship — static analysis, dependency scanning, penetration testing, and secure coding practices. That focus is warranted, but it misses a critical second layer: securing the infrastructure and toolchain that builds, tests, and deploys that software. Think of it as protecting the factory, not just the product rolling off the line.
Research conducted by threat intelligence firm IntSights found that a significant share of DevOps organizations are leaving this factory dangerously exposed — and attackers don’t need sophisticated techniques to exploit it.
What the IntSights Research Found
IntSights researchers examined nearly 26,000 URLs associated with DevOps tools and servers across a range of organizations. Their methodology was deliberately unsophisticated: they used open-source intelligence (OSINT) tools and public websites to compile the URL list, then simply attempted to connect to each one via a browser — no port scanners, no exploit frameworks, no insider data.
Their findings were stark:
- More than 23% of the tested URLs were accessible from the public internet, with varying levels of exposure.
- Some instances were completely open — no username or password required — leaking company data, user lists, and internal server names.
- Most protected instances relied on nothing more than a simple login page, while only a minority used a cloud access security broker (CASB) or equivalent robust control.
“Given DevOps tools sit in the cloud, they are more vulnerable to reconnaissance by hackers. As opposed to traditional IT tools and servers that are still protected by the company network, a misconfigured DevOps tool will expose its data directly to the Internet, meaning hackers don’t need to use any special hacking tools, just simple scanning tools that are available online.”
— Alon Arvatz, co-founder, IntSights
Why Cloud-Hosted DevOps Tools Are a Larger Attack Surface
Traditional on-premises IT infrastructure sits behind a corporate network perimeter. DevOps tools — CI/CD servers, issue trackers, log aggregators, container registries, artifact repositories — are routinely deployed in cloud environments where that perimeter either doesn’t exist or is easy to misconfigure.
The researchers identified several common, avoidable mistakes that amplify this risk:
- Tool names used as hostnames. Naming a public-facing server
jenkins.example.com,kibana.example.com, orjira.example.comtells an attacker exactly what software to target and what known vulnerabilities to probe. - No multifactor authentication (MFA). Many popular DevOps tools don’t ship with MFA enabled by default, leaving a single compromised password as the only barrier to a full breach.
- Default ports left open. Running services on well-known default ports (e.g., Jenkins on 8080, Kibana on 5601) makes them trivial to find with any public scanning service.
- Unpatched infrastructure. DevOps tools themselves have CVEs. Slow patching cycles leave known exploits open.
The Double-Edged Sword of Infrastructure as Code
DevOps practices like infrastructure as code (IaC) and automation bring genuine security benefits. Paula Thrasher, Director of Digital Services at General Dynamics (a large federal IT integrator), described how IaC lifted infrastructure reuse from roughly 60% to nearly 90%.
“Which basically means 90% of the stuff in our production is a reusable standard, and not a special-snowflake bespoke server. That’s huge, because it just takes down the attack surface.”
— Paula Thrasher, Director of Digital Services, General Dynamics
Standardized, consistently configured infrastructure is harder to attack than a sprawl of hand-crafted servers. Security policies can be codified, audited, and enforced at scale.
But the same property creates risk in the opposite direction: a single misconfiguration is replicated across every instance that uses the same template. In a bespoke environment, a mistake affects one server. In a fully automated IaC environment, the same mistake can propagate to hundreds or thousands of workloads before anyone notices. The stakes of each configuration decision are therefore much higher.
The Human Factor: Skill Gaps in DevOps Security
IntSights notes that most cloud platforms and many DevOps tools offer capable security controls. The gap is not primarily a tooling gap — it’s an operator knowledge gap.
“Some [DevOps] tools do offer inherently higher security in their basic configuration, and most cloud platforms offer robust security defenses, but some tools rely entirely on their operator knowledge and expertise. The general shortage of experienced employees in the DevOps and security fields and the fact that most if not all tools are cloud-based make them prone to human errors.”
— Alon Arvatz, IntSights
This reinforces the argument for treating security as a shared responsibility embedded throughout the team, not delegated to a separate security function that reviews changes after the fact.
Practical Steps to Harden Your DevOps Toolchain
Based on the IntSights research recommendations, along with broadly accepted DevSecOps practices, the following controls address the most common exposure vectors:
1. Restrict Public Internet Access
Where operationally feasible, DevOps tools should not be directly reachable from the public internet. Place CI/CD servers, artifact repositories, and observability stacks inside a private network or VPC, accessible only via VPN or bastion host. If public access is genuinely required, use a reverse proxy or API gateway as the single entry point.
2. Enable Multifactor Authentication
MFA should be mandatory on every DevOps tool that supports it — CI/CD platforms, source control, container registries, issue trackers, and cloud consoles. Where native MFA is unavailable, route access through a single sign-on (SSO) provider that enforces it.
3. Use Non-Default Ports and Generic Hostnames
Avoid naming servers after the tools they run. Use generic or internal names that don’t advertise the software stack. Change default service ports where your tooling supports it. While this is security-by-obscurity and not a substitute for real controls, it meaningfully reduces noise from automated scanners.
4. Keep Infrastructure Patched and Up to Date
Treat your DevOps tool stack with the same patching rigor you apply to production application servers. Subscribe to security advisories for Jenkins, Kubernetes, GitLab, Terraform, and any other tools in your pipeline. Automate patch application and image rebuilds where possible.
5. Audit Tool Configurations Against Security Baselines
Use IaC linting and policy-as-code tools (such as Open Policy Agent, Checkov, or tfsec) to enforce security baselines on your infrastructure definitions before they are applied. This catches misconfigurations at the pull-request stage rather than after deployment.
6. Apply Least-Privilege Access to Pipeline Credentials
CI/CD pipelines routinely hold cloud credentials, signing keys, and deployment tokens. Scope these credentials to the minimum permissions required for each job, rotate them regularly, and store them in a dedicated secrets manager rather than environment variables or source code.
7. Monitor and Log Tool Activity
Enable audit logging on all DevOps tools and ship those logs to a centralized SIEM or log aggregation platform outside the pipeline itself. Unusual login patterns, API calls from unexpected IPs, or new administrative accounts should trigger alerts.
Key Takeaway
DevSecOps maturity cannot be measured solely by the security controls embedded in the software your pipeline produces. The pipeline itself — every CI server, artifact store, secrets manager, container registry, and observability stack — is part of your attack surface. Leaving those tools publicly accessible, under-authenticated, and poorly maintained hands attackers a privileged position inside your software supply chain without requiring them to break any of your application-layer defenses. Protecting the factory is as important as securing the product.