OWASP CI/CD Part 7: Insecure System Configuration

Insecure system configuration is a textbook example of how neglected settings can create an entry point for attackers targeting your CI/CD pipelines. It’s rarely the cutting-edge zero-day that causes a breach. More often, it’s the unpatched service, the overly permissive role, or the default password that was never changed.

While this risk overlaps with CI/CD credential hygiene  (covered in Part 6 of our OWASP CI/CD series), the focus here is much broader. This blog post addresses the overall hardening of systems across your pipeline. Yes, weak or default credentials may be part of the problem, but they’re just one symptom of a larger issue in misconfigured systems that were never designed with security in mind.

Why Insecure System Configuration is a Top CI/CD Security Risk
At Cloudsmith, we think about this risk constantly. Configuration is the foundation of your security posture. And when you’re managing artifacts (arguably the most sensitive assets in your software supply chain) you need absolute confidence in the integrity and security of every system that touches them.

The problem with “Insecure by Default” in CI/CD Pipelines

Continuous Integration and Continuous Delivery (CI/CD) stacks are a composite of systems, some SaaS, others self-hosted, and often from different vendors and with distinct security models. Each layer (application, network, and infrastructure) contributes its own configuration surface area. Misconfigure any piece, and the entire chain inherits the weakness.

Examples of these common CI/CD misconfigurations:

• Outdated Jenkins or GitLab runners with known vulnerabilities. For example, in GitLab, managing a large fleet of runners at the group level can make it difficult to track which ones are out of date. Runners that aren’t upgraded regularly may miss critical security patches, leaving your pipeline infrastructure exposed.
• Artifact repositories exposing ports or APIs publicly. For example, you could query for Terraform or IaC exposing artifact repo via an open port. By running a modified version of the GitHub Search query below, adversaries could find Terraform (.tf) or similar configs where artifact systems are binding to all interfaces or exposed ports:

"artifact" AND ("0.0.0.0/16" OR "0.0.0.0:8081" OR "public") AND (path:*.conf OR path:*.yml OR path:*.env OR path:*.tf OR path:*.json)

• Default credentials should never be used in any environment, not even in staging, and especially not when those credentials are publicly accessible. Staging environments should be secured to the same standards as production.
• Pipeline agents being afforded full OS access with persistent credentials in memory. Reference the OWASP Cheatsheet for best practices around minimizing the time window where a secret is in memory and limiting access to its memory space.
• Poor logging setups, leaving no audit trail when something does go wrong. We’ll talk about this in greater detail in part 10 of the OWASP series. Attackers could, for example, use an admin interface or automated job to exfiltrate secrets using encryption or double base64 encoding. In this way, we should be logging every action within our CI/CD system.

Cloudsmith’s perspective on “Secure by Design”

As a fully managed, cloud-native artifact management platform, Cloudsmith is built around secure configuration by default. Here’s how our approach mitigates the types of risks outlined in CICD-SEC-7:

1. Immutable infrastructure with managed updates:
   Self-hosted repositories and build systems often lag on patching due to upgrade complexity. Cloudsmith removes that burden. As a SaaS platform, patches and security fixes are applied continuously behind the scenes. No action is required by customers, and no outdated binaries are exposed.
   
2. Fine-grained access controls:
   CI/CD misconfigurations often stem from over-broad permissions. In Cloudsmith:
   
   - You can define token bandwidth controls, Entitlement Permissions scopes and lifetimes with surgical precision.
   - Enforce RBAC for users and teams to help ensure least privilege at the org, repo, and user level.
   - Artifact access is always protected by HTTP/S with authentication to prevent users from anonymously accessing public artifact repositories. Go a step further by enforcing Multi-Factor Authentication (MFA) for all users in Cloudsmith.
   
3. Secure defaults:
   Misconfigured systems often rely on insecure defaults. Cloudsmith’s default posture includes:
   
   - Cloudsmith repositories that are Private by Default and require authentication for access. Users can choose between entitlement token authentication or HTTP Basic Authentication for accessing these private repositories.
   - Cloudsmith doesn't have default username and password credentials for API access. Instead, users authenticate using their API key, which can be retrieved through the cloudsmith login command or by accessing their user settings. For SAML SSO users, the CLI supports authentication with SAML, eliminating the need to retrieve API keys from the web application.
   - Cloudsmith enforces strict rate limiting and automated IP reputation filtering. Unless specified otherwise, all requests to the API are rate limited to prevent abuse, accidental or otherwise.
   
   These defaults matter, especially when systems are being provisioned and connected to CI tools automatically.
   
4. Audit and traceability:
   Finally, you can’t secure what you can’t see. Cloudsmith's Audit Logs track every action (upload, download, token use, deletion) with full audit trails and webhook integrations. This makes it significantly easier to trace incidents, validate configurations, and enforce compliance.

Hardening beyond artifacts

Whether you’re using Cloudsmith or managing your own stack, here are 6 proactive actionable steps we recommend in our OWASP eBook:

Secure Your CI/CD Pipelines With Cloudsmith

At Cloudsmith, we strongly believe artifact management is about trust, control, and visibility. And secure configuration is where that trust begins.

If you’re looking to harden your pipeline end-to-end, don’t feel like the job is done after scanning your code. Scan your infrastructure. Review your configs. And if you’re managing your artifacts, consider doing it somewhere that’s already hardened for you.

If you found this content helpful and want to dive deeper into securing your CI/CD pipelines, beyond credential hygiene best practices, be sure to check out our free Cloudsmith eBook on the OWASP Top 10 for CI/CD security risks - download it here.

Liked this article? Don\'t be selfish (:-), share with others:   Tweet