By submitting this form, you agree to our 

Why developers must prioritise logging and visibility in CI/CD pipelines

This marks the final entry in our 10-part series on the OWASP Top 10 for CI/CD security risks. While production environments often benefit from rigorous hardening, logging and observability, in CI/CD pipelines this often remains critically under-addressed, despite being a key focus of OWASP. In this post, we’ll unpack the security risks posed by insufficient logging in CI/CD environments, why it matters, and how you can strengthen your defences using modern artifact management solutions like Cloudsmith, alongside powerful open-source tools like Falco and GUAC.

Risk of attacks going undetected in CI/CD pipelines

Without proper logging and visibility, attackers can move through your CI/CD systems undetected - whether stealing credentials, injecting malicious code, or tampering with artifacts. This lack of audit-ability makes post-incident investigations nearly impossible, delaying containment and increasing the potential damage.

As we look to evolving regulatory pressures through EU’s Cyber Resiliency Act (

), Network and Information Systems Directive 2 (

) and Digital Operational Resilience Act (

), it’s more urgent than ever to have adequate auditing and visibility capabilities to meet these compliance requirements.

At the same time, threat actors are increasingly exploiting programmatic access, automated bots, and compromised tokens to breach and persist within CI/CD pipelines. While strong observability might feel like a "nice-to-have" on a checklist, it should be your first line of defence and your best tool for recovery.


Why logging in CI/CD is often overlooked

While logging is typically mature in production environments (covering servers, apps, and network infrastructure) CI/CD systems often fall through the cracks. Consider how many tools touch your pipeline:


Supply Chain Management (GitHub & GitLab)

Deployment/orchestration platforms (Kubernetes)

Artifact repositories (Cloudsmith, Nexus & Artifactory)

Each of these components introduces new vectors, and often lack default security logging capabilities unless explicitly configured.


How to build effective logging and visibility in CI/CD

There are several elements to achieving sufficient logging and visibility:

Before you can secure your pipeline, you need to inventory every system involved, from source code managers, build servers, artifact storage, through to deployment systems, whether that be Kubernetes or Terraform. Open-source tools like 

 (Graph for Understanding Artifact Composition) help you 

 between artifacts, identify missing SBOMs/SLSA attestations, and catch policy violations. GUAC ingests metadata like SBOMs and builds a graph to trace how artifacts are produced, increasing transparency across your pipeline.

 explores the various nodes and relationships of GUAC. The below 

 searches the GUAC graph for any vulnerabilities affecting that Package URL (PURL), including transitive ones.


 of a given PURL. Users can generate a summary of all SBOMs, SLSA attestations, vulnerabilities and licensing information that GUAC knows about for the artifact:

 are enabled and accessible. Naturally, this same rule applies to other SCM tools like Gitlab and CI servers like CircleCI. These sources should include user access logs (such as logins and permission changes), as well as pipeline events (build triggers and artifact uploads). Developers also need to be able to track API usage and access token activity, deployment actions and runtime configurations, and more. 

. API tokens, webhooks, and CLI-based interactions are commonly exploited, and we must ensure visibility covers these too.

3. Centralise logs for correlation & alerting


Shipping logs to a centralised Security Information and Event Management (

) like Datadog allows you to correlate events across tools and detect anomalies early. Thankfully, Cloudsmith now offers a prebuilt Datadog Agent container with the 

 already installed. This streamlines observability by eliminating manual integration steps and avoiding version drift. You’ll get dashboards and alerts covering, artifact usage and delivery, audit logs, compliance status, and suspicious access patterns. In this way you can monitor if a previously unused artifact is suddenly downloaded from a production repository. That could be a red flag for your team.

4. Detect unwanted SCM activity in real-time with Falco


In some cases you might prefer not to send all events and logs to a centralised SIEM solution like Datadog, Dynatrace or Splunk (either due to verbosity of logs or due to storage costs). In these scenarios, 

 could be a great lightweight approach for monitoring real-time events from Supply Chain Management (SCM) platforms like 

 as well as the hosts and orchestration layers (

). Falco is an open-source runtime security tool that integrates seamlessly with GitHub and Kubernetes via dedicated plugins. It listens to events in real time and can alert you when something suspicious happens, like, if a user pushes sensitive credentials like Kubernetes 


For GitHub, Falco can set up webhooks on your repositories, analyse push events, new branch creation, token usage, as well as alert you via Slack, email, or send those alerts back into your SIEM. Falco doesn’t store or index your data, meaning it's a fast, lightweight, and cost-effective alternative for sufficient logging and visibility of Github. Think of it as a security camera for your repositories and clusters.

5. Enforce security policies and log decisions


As a comprehensive artifact management platform, Cloudsmith allows users to define and enforce security policies around artifact usage and publishing. Every decision made by these policies is logged and can be queried via API. We call these 

Example API call to retrieve policy logs:

You’ll get detailed insight into the evaluation start and end times of the Cloudsmith security policies, but also inputs used to evaluate those policies, the results and actions taken, as well as providing traceability and supporting regulatory audits and incident investigations.

Separate to decision logs, Cloudsmith provides client logs and audit logs. 

 provide a single pane of glass to visualise, filter, and export information about package usage within your entire workspace. It keeps the same artifact-agnostic support to unify information about all of your repositories, packages, and users in one place. No matter if your goal is gaining visibility, performing an exploratory analysis, or reporting to stakeholders, client logs provide all the information that you need. With client logs you could analyse which Maven artifacts were downloaded last month, or better understand all the different artifacts used in a staging pipeline.

 provide a timeline view of non-package (but typically administrative) actions that have occurred within the repository, such as creating/modifying repository Retention Rules or creation of an Entitlement Token.

You can’t protect what you can’t see.
Logging and visibility are your eyes and ears in fast-moving CI systems.


Invest the time to get it right, and your response time in a real-world attack could shrink from hours to minutes. That’s where different approaches matter. SIEMs can be really powerful for audit-ability of all logs data from multiple different CI/CD sources, but a dedicated event streaming approach through Falco might be ideal for triggering detections when a user has made an anomalous change to your Github repository in real-time.

CI/CD systems are increasingly targeted, so treat them like production. Logging must cover both human and programmatic access. Centralising logs unlocks correlation, detection, and faster incident response. Open-source tools like Falco and GUAC, and platforms like Cloudsmith and Datadog, make observability scalable and actionable. If you're deploying code to production, you need full visibility into your build and release pipeline. If you enjoyed this content, you can download the 

Nigel Douglas

Head of Developer Relations

OWASP CI/CD

OWASP CI/CD Part 10: Insufficient Logging and Visibility

Improper artifact integrity validation is a critical vulnerability in CI/CD pipelines characterised by insufficient mechanisms to cryptographically verify the authenticity and integrity of code and build artifacts traversing the pipeline. When these controls are weak or absent, adversaries with access to any pipeline stage can inject malicious or tampered artifacts that appear legitimate, enabling undetected propagation through the pipeline and eventual deployment into production environments.

This issue originates from the failure to enforce strong cryptographic validation of artifacts and dependencies within the CI/CD workflow. Because modern pipelines frequently integrate internally developed code, third-party dependencies, container images, and Infrastructure-as-Code (IaC) manifests, multiple vectors exist where unverified or malicious components can infiltrate.

In particular, attackers exploiting weak artifact validation can:

Insert malicious code in source commits, bypassing code signing controls.

Replace build artifacts or dependencies in artifact repositories or mirrors.

Modify cryptographic hashes or signatures to spoof legitimate artifacts.

Exploit lack of multi-source verification to propagate tampered components.

Without strong end-to-end integrity checks, the CI/CD pipeline can end up acting as a trusted path for delivering compromised software.

Why Artifact Integrity Validation Matters

Artifact integrity validation guarantees that every software package, container image, and configuration file has not been altered from its original, verified state. This is achieved through cryptographic hashes (eg: SHA-256), digital signatures, and metadata attestations which provide strong guarantees of provenance and immutability.

By rigorously validating artifacts, development teams ensure:

Protection against supply chain attacks involving compromised dependencies or build outputs.

Detection of unauthorised modifications during artifact transit or storage.

Preservation of pipeline trust boundaries, preventing malicious code from reaching production.

Failures in integrity validation have severe consequences, including covert insertion of backdoors, data exfiltration, service disruptions, and erosion of trust in automated deployment systems.

The Multi-Source Challenge in Modern Pipelines

The wide variety of inputs in CI/CD pipelines can introduce risk at every turn. For starters, code is often contributed by numerous developers spread across different teams and geographies, which means there's a constant stream of changes flowing into the system. These code commits can vary widely in quality and intent, making it critical to validate each one thoroughly. At the same time, build artifacts are produced incrementally at various stages of the pipeline. While this modular approach increases efficiency, it also opens up the possibility for inconsistencies or vulnerabilities to creep in if not carefully managed.

Another layer of complexity is added by the dynamic resolution of third-party dependencies and container images, which are frequently pulled in on the fly. These external components may not always be trustworthy or up-to-date, and can act as silent entry points for malicious code. Finally, the deployment process itself often relies on IaC templates, which are sometimes sourced from multiple repositories. This fragmented structure makes it harder to maintain visibility and control over what’s actually being deployed. Altogether, each of these inputs expands the pipeline's attack surface, further emphasising the need for rigorous validation and security checks at every step.

Core Components of Artifact Integrity Validation

Ensuring artifact integrity throughout the CI/CD pipeline is not a single-step task, you’ll need to implement a comprehensive, layered approach that addresses security at multiple levels. At the heart of this process are cryptographic checksums and digital signatures, such as 

 signatures. These mechanisms verify that both source code commits and generated artifacts remain unaltered from their original, trusted state, providing a foundation of authenticity and non-repudiation. However, simply generating secure artifacts won’t solve all the issues. These artifacts must also be stored and distributed in a secure manner.

This is where secure artifact repositories come into play

. These registries should be trusted, access-controlled, and designed to prevent tampering, ensuring that only authorised users and processes can interact with stored artifacts. Just as important is the secure transport of artifacts across pipeline stages. Enforcing end-to-end TLS encryption, along with mutual authentication between services, helps protect against interception or unauthorised modification during transmission. Underpinning all of this is the robust key management systems.

Signing keys must be protected using Hardware Security Modules (

) or other secure vault solutions, with automated key rotation policies in place to reduce the risk of compromise over time. Together, these components form a cohesive security framework that protects artifacts from the moment they’re created, through every stage of the pipeline, all the way to final deployment.

Hypothetical Tampered Artifact Injection Workflow

This type of attack re-emphasises the necessity for multi-layered validation and continuous monitoring in CI/CD pipelines.

How Cloudsmith Can Help Secure Artifact Integrity

Cloudsmith is a fully managed, cloud-native artifact repository built from the ground up with a focus on security and supply chain integrity. It offers a comprehensive set of capabilities designed to protect against risks like tampered, mis-validated, or malicious artifacts.

Cloudsmith enforces immutability by ensuring that once an artifact is uploaded, it cannot be altered or deleted. This guarantees that the artifact remains in its original, trusted state. The attestation, along with the certificate, is recorded in Sigstore’s 

, providing a permanent record of the artifact’s authenticity and provenance. Each artifact is versioned and linked to cryptographic hashes and rich metadata, providing a complete audit trail that can be used for traceability and forensic analysis in the event of an incident.

Cloudsmith supports automated signing of artifacts using tools like Sigstore’s 

 for provenance, making it easier to embed trust into your software supply chain. These signatures can be verified before deployment or distribution, ensuring that only authorised and untampered artifacts are used in production environments.

Fine-Grained Access Control & Authentication

 and the ability to generate tightly scoped API tokens, Cloudsmith allows organisations to precisely define who can publish, read, or delete artifacts. This reduces the surface area for internal threats, and helps ensure that only trusted individuals can interact with critical software components.

Multi-Protocol Support with Secure Transport

 and protocols - including REST, OCI, Maven, npm, NuGet, Python (PyPI), and more. All transfers are encrypted with TLS, providing confidentiality and integrity during transit and reducing the risk of man-in-the-middle (MitM)-style attacks.

Cloudsmith integrates seamlessly with popular CI/CD platforms like 

, and so much more. These integrations allow teams to automatically publish signed artifacts and enforce policy checks (such as signature validation or provenance verification) at every stage of the delivery pipeline, embedding security directly into the development workflow.

 that provide a timeline view of non-package (but typically administrative) actions that have occurred within the repository, such as creating/modifying repository Retention Rules or creation of an Entitlement Token. These logs are essential for compliance and incident response, providing visibility into potential unauthorised usage patterns within the platform and development teams.

By using Cloudsmith as a central, security-aware artifact repository, your team can enforce strong cryptographic validation, limit exposure through precise access control, and maintain a clear audit trail. This makes it significantly harder for malicious or improperly validated artifacts to enter and propagate through the software supply chain.

To effectively defend against vulnerabilities stemming from inadequate artifact integrity validation, teams should adopt a series of interlocking best practices that reinforce trust across every stage of the software supply chain. A foundational step is implementing signed commits and enforcing commit signing policies within Source Code Management (

) systems. By requiring all commits to be signed with verified developer identities (and rejecting those that are not) businesses can ensure the authenticity of code contributions and trace their origins with confidence.

Beyond the source code itself, artifact signing and the use of in-toto attestations are critical for verifying the integrity and provenance of build outputs. With the right tooling, teams can sign every artifact generated during the build process and produce cryptographically verifiable attestations that describe how, when, and with what inputs those artifacts were created. This establishes a transparent, tamper-evident trail from source to binary.

Third-party components are another common source of risk. To mitigate this, it’s essential to perform multi-source integrity checks on all external dependencies. This means verifying package or container digests against official vendor-provided checksums and cross-referencing those results with additional trusted sources, reducing the chance of accepting a compromised or spoofed dependency.

Equally important is the secure storage of build artifacts. Repositories such as Cloudsmith provide access controls, audit logging, and built-in protections against unwarranted changes, helping to ensure that only validated artifacts make it into later stages of the pipeline or into production environments.

Finally, security shouldn't end once an artifact is deployed. Continuous drift detection and monitoring are crucial for identifying anomalous changes to IaC configurations or runtime environments. Free open-source tools such as Sysdig’s 

 can help detect early signs of Github account modifications, allowing teams to respond quickly and maintain a strong security posture over time.

Together, these practices create a resilient defence against integrity-based attacks, reducing the risk of compromised artifacts reaching production systems.

Improper artifact integrity validation remains a critical attack vector threatening software supply chain security. By adopting comprehensive cryptographic validation, secure artifact storage, and vigilant monitoring (all achievable within Cloudsmith) you can significantly reduce the risk of malicious code propagating unnoticed into production environments.


In the next and final instalment of this series, we will examine the last major risk identified in the OWASP Top 10 for CI/CD systems, which deals explicitly with insufficient logging and visibility. Reading through this series, and the associated 

, readers should be provided with a consolidated framework for securing their entire software delivery lifecycle end-to-end. Stay tuned.

OWASP CI/CD Part 9: Improper Artifact Integrity Validation

The boundaries of what organizations build internally and what they adopt externally have blurred. Developers routinely integrate third-party services into critical CI/CD pipelines, often with minimal friction and limited oversight. This rapid plug-and-play convenience, while key to modern engineering velocity, is also quietly expanding the attack surface in ways many teams struggle to track - let alone govern. This issue is no longer whether to use third-party services in your SDLC; it must be a discussion of how well you understand and control these third-party integrations within your software supply chain.

What is the risk of ungoverned 3rd party service usage in CI/CD?

Ungoverned usage of third-party services is a systemic vulnerability. These services often receive broad access to 

. Worse still, that access is frequently granted without rigorous vetting or centralized control. It’s trivially easy to wire up a 

 application, drop an integration token into a CI pipeline, or add an open-source action from a marketplace - and in that moment, a third party becomes an implicit actor within your development lifecycle. From reading source code to injecting build artifacts, their potential impact scales with the permissions they're granted, and too often, those permissions are overly permissive by default.

Third-party integrations are a growing attack surface in CI/CD pipelines

2025 Cloudsmith Artifact Management Report

 highlights this security blind spot with clarity. More than 67% of developers surveyed say they review AI-generated code from third-party services like GitHub Copilot and Cursor before every deployment, yet large portions of production code may still go unvetted. This is quickly becoming a growing vulnerability in the software supply chain. And with estimates suggesting that 

AI-generated code now comprises up to half of modern codebases

, it reflects a growing recognition that while third-party AI services accelerate delivery, they also demand enterprise-grade governance that most organizations are still catching up to implement.

Today’s integrations extend well beyond OAuth tokens, as outlined in 

control 8 of the OWASP top 10 for CI/CD pipelines

. In GitHub alone, third parties can interface via applications, SSH keys, token provisioning, and even webhook configurations - each a potential pivot point for adversaries. In build systems like GitHub Actions or CircleCI, external plugins or shared pipeline components can be injected with little more than a few lines of YAML. These integrations often inherit the full context of the build environment, including secrets, signing keys, and deployment permissions. Without tight scoping, sandboxing, or runtime constraints, the consequences of compromise ripple far beyond a single stage.

 (MCP) solutions aim to address this by providing a unified interface for all these third-party APIs, tools, and data sources, reducing the complexity of managing multiple integrations. Whether fetching data from a database or making a third-party API call, the same protocol is used throughout. That said, integrating MCP with your CI/CD pipeline 

, such as the potential for prompt injection, credential exposure, and supply chain attacks - particularly in 

. Vendors need to build secure solutions to prevent manipulation of model outputs that could lead to data leakage, unintended actions, or even system compromise.

Example: GitHub Actions and Supply Chain Risk

Similarly, supply chain attacks against open source projects often begin by exploiting insecure GitHub Actions workflows. These workflows frequently contain secrets that attackers can exfiltrate, resulting in privilege escalation within the repository. The 

 trigger is widely known to be particularly vulnerable due to its interaction with public forks, which can allow untrusted code to run with elevated permissions. Workflows that use this trigger should be treated with special care, as should the associated security risks. 

Sysdig threat researchers recently discovered

 that pull_request_target was far from the only insecure GitHub Actions workflow in active use.

This interconnectedness is precisely what makes the ungoverned use of third-party services so dangerous. Once a malicious actor compromises a seemingly harmless plugin, service, or GitHub Action with write access, they can cascade their control - from modifying a repository, to triggering builds, to deploying tampered artifacts into production. In this light, every under-reviewed integration is a supply chain risk waiting to be exploited.

Enforcing governance for 3rd party services in CI/CD pipelines

Organizations are beginning to understand that governance must be continuous, not just front-loaded. It’s not enough to approve a service at the point of integration. Visibility into what services are active, how they were connected, what they were granted, and what they are actually doing must be ongoing. And when access is no longer needed, de-provisioning must be swift and definitive. Without this lifecycle discipline, the principle of least privilege remains aspirational rather than operational.

Modern artifact management solutions are uniquely positioned to support this evolution. By embedding 

 capabilities, they automate enforcement of access controls and security gates across every environment. From the first artifact check-in to its distribution across edge or cloud, these systems become not just repositories, but security control planes. They enable organizations to implement fine-grained governance over what is built, how it’s built, and who has the power to influence it.

Balancing CI/CD velocity and visibility in supply chain security

The convenience of third-party services can no longer outpace the control mechanisms that govern them. To build securely at scale, organizations must treat integrations not as trusted accelerators, but as entities to be continuously validated, constrained, and monitored. 


As highlighted in our 2025 findings, the future of secure software delivery hinges on this balance between velocity and visibility - and the organizations that master it will be those that survive and thrive in the era of increasingly sophisticated supply chain threats.

Learn More: Free OWASP CI/CD Security eBook

If you found this guide 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 - 

OWASP CI/CD Part 8: Ungoverned Usage of 3rd Party Services

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 

 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 

, 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 

, you could query for Terraform or IaC exposing artifact repo via an open port. By running a modified version of the 

 query below, adversaries could find Terraform (

) or similar configs where artifact systems are binding to all interfaces or exposed ports:

 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 

 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 

, use an admin interface or automated job to exfiltrate secrets using encryption or 

 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 

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.



CI/CD misconfigurations often stem from over-broad permissions. In Cloudsmith:

 scopes and lifetimes with surgical precision.

 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 


Misconfigured systems often rely on insecure defaults. Cloudsmith’s default posture includes:

 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, 

 command or by accessing their user settings. For SAML SSO users, the 

, eliminating the need to retrieve API keys from the web application.

 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.



Finally, you can’t secure what you can’t see. Cloudsmith's 

 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.

Whether you’re using Cloudsmith or managing your own stack, here are 

Secure Your CI/CD Pipelines With Cloudsmith

At Cloudsmith, we strongly believe artifact management is about 

. 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 

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 - 

OWASP CI/CD Part 7: Insecure System Configuration

 series, looks at some of the common risks associated with Insufficient Credential Hygiene. By better understanding the flaws that affect credential hygiene, we can better understand how even the most sophisticated pipelines were compromised.

CI/CD systems rely heavily on credentials (application secrets, tokens, deploy keys, and more) to operate. These 

 move between services, repositories, environments, and human actors, creating a complex web of access points.

they become prime targets for attackers. Once compromised, these secrets offer 

nities to adversaries with the intention of directly accessing your code, infrastructure, and data.

Secrets live in many places: code repositories, CI/CD configuration files, container images, build logs, and even in the runtime environment. They're used by humans, machines, and processes across different trust boundaries - each with their own associated requirements and risks.

Unlike a centralized authentication system, secrets management is often distributed, ad hoc, and invisible until breached.

Here are some of the most pervasive and dangerous practices seen in real-world CI/CD environments.:

 are a time bomb. Even if deleted from the latest branch, they remain visible in the commit history to anyone with access.


Overly-permissive credentials in pipelines


CI/CD pipelines often use credentials to access source code, artifact repositories, cloud resources, and production systems. Without 

 (which limits what actions credentials can perform and what resources they can access) and 

 (which grant access only under specific conditions like IP Address, time of day, or workload identity) these credentials can become open doors for unauthorized access.

Ask yourself:
- Does each pipeline only access the secrets it needs?
- Are secrets scoped to specific environments or job steps?
- Can unreviewed code access production secrets?

Where possible, organizations should enforce the 

Secrets embedded in container image layers

 (such as API tokens or SSH keys) can inadvertently remain in 

. Anyone with access to the image can retrieve them, even if they’re not meant to persist beyond the build.


 during a build, becomes a liability. Logs may be stored indefinitely, aggregated into third-party observability platforms, or exposed through dashboards.



Static credentials that never expire are dangerous - especially in environments with high personnel turnover or external contractors. Without regular rotation, credentials accumulate risk with every day they remain active. 

 is a production best-practice that ensures credentials are short-lived.

Real-world breaches caused by poor credential hygiene

 where secure environment variables (type of secrets) were exposed during builds triggered by pull requests to public repositories. Even though secrets were encrypted in storage, they were made accessible during build execution, potentially leaving them susceptible to compromise by anonymous users issuing pull requests against public repositories.

While the Travis CI team quickly patched the issue, it highlighted how even secure systems can leak secrets when trust boundaries are not well-defined. In this scenario, Travis CI has strongly recommended that both Public and Private Repository customers rotate their secrets on a regular basis

If possible, users affected in these scenarios should set expiration dates on those tokens or rotate their secrets regularly; this reduces the risk of old secrets being exploited.

Cloudsmith Blog

OWASP CI/CD Part 10: Insufficient Logging and Visibility

OWASP CI/CD Part 9: Improper Artifact Integrity Validation

OWASP CI/CD Part 8: Ungoverned Usage of 3rd Party Services

OWASP CI/CD Part 7: Insecure System Configuration

OWASP CI/CD Part 6: Insufficient Credential Hygiene