OWASP Top 10 CI/CD Security Risks Explained: Examples and Prevention

Quick answer: The OWASP Top 10 CI/CD Security Risks describe common ways attackers can abuse the systems that build, test, package, and deploy software. The risks include weak approvals, excessive permissions, malicious dependencies, poisoned pipeline definitions, exposed credentials, unsafe configurations, ungoverned integrations, unverified artifacts, and poor logging. Preventing them requires controls across source repositories, build runners, secrets, artifacts, deployment environments, and the people or services allowed to change each stage. A CI/CD pipeline is supposed to make releases repeatable. That same automation can make a security mistake repeatable too. If an attacker changes a workflow, compromises a dependency, or steals a deployment credential, the pipeline may deliver the attack through the same trusted path used for legitimate releases.

The OWASP Top 10 CI/CD Security Risks gives engineering and security teams a practical way to review that path. It does not replace threat modeling or a platform-specific hardening guide. It helps teams ask where trust is granted, how changes move toward production, and what would stop one compromised identity or component from controlling a release.

In short: Secure CI/CD by treating the delivery pipeline as production infrastructure. Require review for important changes, minimize permissions, isolate untrusted jobs, protect short-lived credentials, verify artifacts, control third-party integrations, and retain logs that show who changed or executed what.

What Is CI/CD Security?

CI/CD security protects the tools, identities, code, dependencies, build environments, artifacts, and deployment processes used to deliver software.

Continuous integration (CI) automatically builds and tests changes as developers commit code. Continuous delivery or deployment (CD) prepares or releases approved changes into an environment such as staging or production.

A typical delivery path may include:

• A developer workstation and source-code repository
• Pull requests, branches, and repository rules
• Workflow files or pipeline definitions
• Hosted or self-managed build runners
• Package registries and external actions
• Secrets used during build and deployment
• Artifact or container registries
• Cloud accounts, clusters, and production servers
• Logs, alerts, and approval records

Every connection introduces trust. A repository trusts contributors and installed apps. A runner trusts the workflow it executes. A package manager trusts registries and package names. A deployment job trusts an artifact and credentials. Production trusts the result of the pipeline.

CI/CD security is the work of limiting, verifying, and monitoring those trust relationships.

Why CI/CD attacks can have a wide impact

Pipelines often hold permissions that individual users do not. They may read private code, access signing keys, publish packages, push container images, update infrastructure, or deploy directly to production.

That makes a pipeline an attractive target. An attacker who compromises one developer account may reach one repository. An attacker who compromises a broadly trusted build service, reusable workflow, or artifact can reach many repositories, environments, or customers.

The important question is not only, “Is our application code secure?” It is also, “Can we trust the process that turns this code into the software running in production?”

What Are the OWASP Top 10 CI/CD Security Risks?

OWASP lists ten risks that affect modern software delivery systems:

• Insufficient Flow Control Mechanisms
• Inadequate Identity and Access Management
• Dependency Chain Abuse
• Poisoned Pipeline Execution
• Insufficient Pipeline-Based Access Controls
• Insufficient Credential Hygiene
• Insecure System Configuration
• Ungoverned Usage of Third-Party Services
• Improper Artifact Integrity Validation
• Insufficient Logging and Visibility

The order is useful for discussion, but it is not a universal priority list for every organization. Your most urgent risk depends on the pipeline's permissions, exposure, architecture, and the value of the software it delivers.

1. CICD-SEC-1: Insufficient Flow Control Mechanisms

What the risk means

Flow controls determine how a change moves from development to production. The risk appears when one compromised person, service account, repository, or automation component can push a change through the entire path without an independent check.

For example, a maintainer account may be able to edit a workflow, merge it into the default branch, and trigger a production deployment. If that identity is compromised, the pipeline can turn the attacker's change into a trusted release.

Practical example

Imagine that a repository deploys automatically whenever code reaches main. Branch protection is disabled, workflow files do not require specialist review, and the deployment environment has no approval step. A stolen maintainer token can be enough to change the pipeline and deploy malicious code.

The individual tools may all be working as configured. The failure is the absence of a second control between change and release.

How to prevent it

• Protect production branches and prevent direct pushes.
• Require pull-request review from someone other than the author.
• Require designated reviewers for workflow, infrastructure, and security-sensitive files.
• Run required tests before merge or deployment.
• Protect production environments with explicit approval where the risk justifies it.
• Separate the ability to change code from the ability to approve a release.
• Prevent administrators from casually bypassing rules, and audit any necessary bypass.
• Use different workflows and credentials for testing and production.

Flow controls should match the impact of the action. A documentation preview does not need the same approval process as a job that publishes a package or changes a production database.

2. CICD-SEC-2: Inadequate Identity and Access Management

What the risk means

Identity and access management determines who and what can use CI/CD systems. Problems arise when accounts are shared, inactive users retain access, authentication is weak, or roles grant more authority than a person or service needs.

The risk covers human identities, service accounts, bots, deploy keys, personal access tokens, applications, and machine identities used by runners.

Practical example

A former contractor remains a member of the source-code organization because offboarding covered email and chat but not developer tooling. The account still has access to private repositories and can approve pull requests. Even if the person never abuses that access, the forgotten identity increases the attack surface.

How to prevent it

• Connect critical developer platforms to centralized identity management where practical.
• Require phishing-resistant multi-factor authentication for privileged users.
• Remove shared accounts and identify the owner of every service identity.
• Apply least privilege to repository, organization, CI, registry, and cloud roles.
• Review access regularly and after team or vendor changes.
• Automate onboarding and offboarding across the full toolchain.
• Limit personal access tokens by repository, permission, and lifetime.
• Use separate administrator accounts for privileged actions.
• Monitor dormant accounts and unexpected privilege changes.

Do not review repository permissions in isolation. A user with limited repository access may still have broad authority in the CI service, package registry, cloud account, or secret manager.

3. CICD-SEC-3: Dependency Chain Abuse

What the risk means

Builds regularly download code from package registries, container registries, plugins, reusable actions, and other external sources. Dependency chain abuse occurs when an attacker causes a malicious or compromised component to be selected and executed.

This can involve typosquatting, dependency confusion, account takeover, malicious updates, compromised transitive dependencies, or mutable references that silently point to different code later.

Practical example

A company uses an internal package called company-utils, but the build configuration also checks a public registry. An attacker publishes a public package with the same name and a higher version. If resolution rules prefer that version, the build runner downloads and executes the attacker's package.

Another common pattern is referencing a third-party CI action by a movable tag such as v1. If the tag is later changed to a compromised commit, future pipeline runs can execute different code without a change in your repository.

How to prevent it

• Lock dependency versions and review lockfile changes.
• Pin reusable actions and high-risk build components to immutable commit hashes or digests.
• Configure private and public registry resolution deliberately.
• Reserve internal package names in public registries where appropriate.
• Use trusted internal mirrors or approved registries.
• Generate and retain a software bill of materials for released artifacts.
• Scan direct and transitive dependencies for known vulnerabilities.
• Monitor for abandoned packages, maintainer changes, and unexpected releases.
• Limit network access from build jobs that do not need to download arbitrary code.
• Test updates before allowing automated tools to merge them.

A vulnerability scanner helps with known vulnerable versions. It may not detect a new malicious package that has no published advisory, so provenance, pinning, review, and behavior monitoring still matter.

4. CICD-SEC-4: Poisoned Pipeline Execution

What the risk means

Poisoned Pipeline Execution, or PPE, occurs when an attacker manipulates the instructions that a CI runner executes. The malicious instructions may be placed directly in a workflow file or indirectly in a script, configuration file, build tool, test, or other file referenced by the pipeline.

The danger is highest when untrusted code runs in a privileged job with access to secrets, repository write tokens, registries, or deployment environments.

Practical example

Suppose a public repository runs pull-request code on a self-hosted runner. The workflow checks out the contributor's branch and executes its build script. The same job has access to a cloud deployment token.

A malicious pull request can change the build script to print or transmit the token. The attacker does not need permission to merge the change. The vulnerable event and runner configuration execute it during validation.

How to prevent it

• Treat pull requests and forked code as untrusted.
• Do not expose production secrets to jobs that execute untrusted code.
• Review trigger types such as pull-request-target events and understand which revision runs with which permissions.
• Use ephemeral runners that are destroyed after a job.
• Isolate jobs by trust level, repository, and environment.
• Restrict outbound network access when a job does not need it.
• Protect workflow files and referenced scripts with code-owner review.
• Set the default job token to read-only and raise permissions only for a specific step.
• Avoid running public contributions on persistent self-hosted runners with internal network access.
• Review generated or dynamically constructed pipeline steps before execution.

The key control is separation. A job that tests unknown code should not share the same secrets, runner state, or network reach as a job that deploys trusted code.

5. CICD-SEC-5: Insufficient Pipeline-Based Access Controls

What the risk means

Pipeline-based access controls govern what a running job can reach. Even if the user who triggered a pipeline has limited access, the runner may hold powerful credentials or network access.

OWASP highlights the danger of pipeline execution nodes that can move laterally into other repositories, cloud resources, artifact stores, internal services, or production systems.

Practical example

A CI runner uses one cloud role for every repository. That role can read production secrets, write container images, and deploy to several environments. A compromised low-risk repository can therefore become a path into high-value production resources.

The repository was not the final target. The shared runner identity connected it to the target.

How to prevent it

• Give each pipeline and environment a narrowly scoped identity.
• Separate build, test, publish, and deploy permissions.
• Use short-lived workload identity instead of shared static cloud keys.
• Restrict runner network paths to the services required by the job.
• Separate runners for public, internal, and production workloads.
• Prevent one repository from using another repository's secrets by default.
• Scope artifact and registry permissions to specific projects and operations.
• Use environment-specific roles and accounts.
• Deny production access from pull-request and feature-branch jobs.
• Review the effective permissions of each job, not only the permissions written in the workflow.

Least privilege in CI/CD should be evaluated at runtime. A workflow may request read-only access while the underlying runner still has a powerful instance role or mounted credential.

6. CICD-SEC-6: Insufficient Credential Hygiene

What the risk means

Pipelines use credentials for source control, registries, cloud services, signing, notifications, and deployment. Credential hygiene fails when secrets are stored insecurely, remain valid too long, appear in logs, are shared across environments, or carry excessive permissions.

Practical example

A deployment token is stored as a long-lived CI variable and reused by development, staging, and production. A debugging command prints the environment during a failed job. The token is masked in ordinary output, but an encoding or transformation bypasses the masking rule.

One leaked value now opens several environments and remains useful until someone notices and rotates it.

How to prevent it

• Replace long-lived credentials with short-lived, job-specific identities where possible.
• Store secrets in an approved secret manager or protected CI secret store.
• Scope each secret to the repository, environment, and operation that needs it.
• Prevent secrets from reaching untrusted branches and pull requests.
• Rotate credentials on a schedule and immediately after suspected exposure.
• Scan code, Git history, build artifacts, and logs for exposed secrets.
• Avoid printing complete environments or request headers during debugging.
• Test whether masking survives common encodings and transformations.
• Keep production and non-production credentials separate.
• Record ownership and last rotation for every important credential.

Deleting a secret from the current branch does not make it safe. If it entered Git history, a build log, a package, or a container layer, treat it as compromised and rotate it.

7. CICD-SEC-7: Insecure System Configuration

What the risk means

CI/CD platforms, runners, repositories, registries, and related infrastructure include many security settings. Default, outdated, inconsistent, or misunderstood configurations can expose administrative interfaces, allow unsafe job execution, weaken isolation, or grant unintended access.

Practical example

A self-hosted runner is persistent and shared by several repositories. Jobs run with administrative privileges, Docker exposes its socket to the runner, and workspaces are not cleaned between jobs. Malicious code in one build can inspect files from another job or use the Docker socket to control the host.

How to prevent it

• Harden CI servers, runners, registries, and source-control settings against a documented baseline.
• Patch supported components and remove abandoned plugins.
• Prefer ephemeral, isolated runners for sensitive or untrusted workloads.
• Avoid privileged containers and exposed container-engine sockets unless required and strongly isolated.
• Block public access to administrative services.
• Disable unused features, anonymous access, and legacy authentication.
• Encrypt connections between pipeline components.
• Review organization-wide defaults for new repositories and projects.
• Manage important settings as code and review configuration changes.
• Test backups and recovery for pipeline configuration and critical metadata.

Configuration review is not a one-time setup task. Platform updates, new repositories, temporary exceptions, and copied workflows can cause the baseline to drift.

8. CICD-SEC-8: Ungoverned Usage of Third-Party Services

What the risk means

Third-party applications can connect to repositories, pull requests, build jobs, tickets, chat systems, and cloud services. Each integration receives permissions and becomes part of the CI/CD attack surface.

The risk grows when teams can install apps without review, nobody tracks which services are active, or old integrations retain broad access after their business purpose ends.

Practical example

A developer installs a code-review service and grants it access to every repository because that is the easiest installation option. The team later stops using the service, but the authorization remains. A compromise of the vendor or its token could still expose private code or modify pull-request activity.

How to prevent it

• Maintain an inventory of installed apps, webhooks, bots, OAuth grants, and external CI services.
• Require review before a service receives organization or repository access.
• Grant access only to selected repositories and required permissions.
• Evaluate the vendor's security practices and incident process.
• Review integrations regularly and remove unused ones.
• Monitor new installations and permission changes.
• Use separate test organizations when evaluating unfamiliar tools.
• Avoid sending secrets or sensitive code to services that do not need them.
• Prepare a revocation and rotation process for third-party incidents.
• Include connected services in offboarding and vendor termination procedures.

The convenience of an integration should not decide its access. Start with no access and add only what the service needs.

9. CICD-SEC-9: Improper Artifact Integrity Validation

What the risk means

An artifact is the output that moves toward release, such as a package, binary, archive, container image, or deployment bundle. Integrity validation proves that the artifact is the expected output from an approved process and has not been replaced or modified.

Without that verification, a valid workflow may deploy a malicious artifact from an untrusted location or a compromised registry.

Practical example

A build creates a container image and pushes it using a mutable tag such as latest. The deployment later pulls whatever image the tag points to. If an attacker can overwrite the tag, production may run an image that was never created by the approved build.

How to prevent it

• Use cryptographic hashes or immutable digests when promoting artifacts.
• Sign artifacts and verify signatures before deployment.
• Record provenance that connects an artifact to its source, workflow, and builder.
• Make artifact repositories immutable where possible.
• Separate permission to upload an artifact from permission to promote or deploy it.
• Prevent rebuilds between stages when the same verified artifact can be promoted.
• Generate artifacts in isolated, controlled builders.
• Validate checksums for downloaded tools and dependencies.
• Restrict who can move or overwrite tags and releases.
• Retain evidence for the exact artifact running in each environment.

Testing source code and testing the released artifact are not always equivalent. The safest process builds once, verifies the result, and promotes that same immutable artifact through environments.

10. CICD-SEC-10: Insufficient Logging and Visibility

What the risk means

Logging and visibility determine whether a team can detect suspicious CI/CD activity and reconstruct it later. An attacker benefits when repository, CI, registry, identity, and cloud events are missing, short-lived, scattered, or never reviewed.

Practical example

A workflow is changed late at night, a new organization token is created, and a package version is published. Each platform records part of the activity, but the logs stay in separate consoles and expire before anyone investigates.

The team sees the malicious package but cannot reliably determine which identity changed the workflow, which runner executed it, or what secrets the job accessed.

How to prevent it

• Centralize audit logs from source control, CI, registries, identity providers, secret stores, and deployment platforms.
• Retain logs long enough for detection and investigation.
• Record workflow changes, job triggers, approvals, secret access, artifact publication, and production deployment.
• Alert on new administrators, unusual token creation, disabled protections, and workflow changes outside normal patterns.
• Monitor failed and cancelled jobs, not only successful deployments.
• Correlate user, service, repository, runner, artifact, and environment identities.
• Protect logs from alteration by the systems they monitor.
• Test alerts with controlled exercises.
• Define who reviews alerts and how escalation works.
• Keep time synchronized across pipeline systems.

Logs are useful only if someone can act on them. Every important alert needs an owner, response path, and enough context to make a decision.

Real-World Examples of Pipeline Attacks

Real incidents rarely fit into only one category. A single compromise may combine weak credentials, excessive permissions, third-party trust, artifact manipulation, and limited visibility.

SolarWinds: malicious code reached a trusted software update

The SolarWinds compromise became a defining software supply-chain incident. Microsoft reported that attackers inserted malicious code into a library belonging to the SolarWinds Orion Platform. The resulting backdoor was compiled and distributed through trusted software updates.

The incident shows why protecting source code alone is not enough. Teams also need trustworthy builders, controlled release flows, artifact integrity, and the ability to detect unauthorized activity inside the delivery environment.

It is relevant to several OWASP CI/CD categories, particularly flow control, pipeline execution, system configuration, artifact integrity, and logging. The lesson is not that one missing checkbox caused the incident. It is that a trusted delivery path can amplify a compromise when malicious output passes through it.

Source: Microsoft's analysis of the Solorigate DLL

Codecov: a modified uploader extracted CI environment data

In 2021, Codecov disclosed that an attacker gained unauthorized access to its Bash Uploader and modified it. Codecov's post-mortem explains that the altered uploader extracted information including environment variables from customer CI environments.

This is a clear example of third-party and dependency trust affecting downstream pipelines. Customers who downloaded or invoked the trusted uploader executed modified code inside environments that could contain valuable credentials.

Controls such as immutable references, checksum or signature verification, tightly scoped job credentials, outbound network restrictions, and secret exposure monitoring can reduce the impact of this type of compromise.

Source: Codecov's April 2021 post-mortem

CircleCI: a stolen session led to customer secret exposure

CircleCI's 2023 incident report states that malware on an engineer's laptop stole a valid, multi-factor-authenticated SSO session. The unauthorized actor later exfiltrated customer information that included environment variables, keys, and tokens for third-party systems.

This incident demonstrates why multi-factor authentication is essential but not sufficient. Session protection, endpoint security, least privilege, short-lived credentials, audit visibility, and rapid rotation also matter.

For customers, it reinforced a difficult rule: if pipeline secrets may have been exposed, assume access and rotate them. Waiting for proof that each credential was used can give an attacker more time.

Source: CircleCI's January 2023 incident report

tj-actions/changed-files: a compromised action exposed runner secrets

In March 2025, researchers identified malicious code in the widely used tj-actions/changed-files GitHub Action. Palo Alto Networks Unit 42 reported that the payload printed credentials found in the CI runner's memory to workflow logs. The attackers also moved existing tags to point to the malicious commit, so workflows using those tags could execute it.

The incident connects dependency chain abuse, third-party trust, credential hygiene, mutable references, and pipeline permissions. It also shows why an apparently small workflow helper can become part of a much larger trust boundary.

Pinning an action to a reviewed commit reduces exposure to a moved tag, but it is not the only control. Jobs should also have minimal token permissions, limited secrets, isolated runners, and monitoring for unexpected changes in third-party actions.

Source: Unit 42's analysis of the GitHub Actions supply-chain attack

A Practical CI/CD Security Review

The OWASP list becomes more useful when teams turn it into questions about their own delivery path.

Source and change control

• Can anyone push directly to a protected branch?
• Who can edit workflow and infrastructure files?
• Can the same person create, approve, and deploy a change?
• Are bypasses logged and reviewed?
• Do automated updates receive appropriate testing and approval?

Identities and secrets

• Which human and machine identities can reach the pipeline?
• Are old accounts and tokens removed promptly?
• Are job credentials short-lived and narrowly scoped?
• Can untrusted branches or forks access secrets?
• Would logs reveal a secret even if ordinary masking is enabled?

Runners and execution

• Which jobs execute untrusted code?
• Are sensitive runners ephemeral and isolated?
• Can a job reach internal services or other workloads?
• Does the runner inherit powerful host or cloud permissions?
• Can one repository affect another through a shared runner?

Dependencies and third parties

• Are actions, packages, images, and plugins pinned to immutable versions?
• Which external apps can read or modify repositories?
• Who approves new integrations?
• Can build jobs download arbitrary code from the internet?
• How will the team respond if a trusted provider reports a compromise?

Artifacts and deployment

• Is the deployed artifact the same artifact that was reviewed and tested?
• Are artifacts signed or verified by digest?
• Can tags or files be overwritten?
• Who can publish and who can promote?
• Can the team identify the exact source and build behind production?

Detection and response

• Are audit logs retained centrally?
• Will the team notice an unexpected workflow change or token creation?
• Can logs connect a release to a user, workflow, runner, and artifact?
• Who receives the alert?
• Has the team tested credential rotation and deployment rollback?

CI/CD Security vs. Website Security

CI/CD security and website security protect different parts of the software lifecycle. They overlap, but one cannot replace the other.

CI/CD security protects the delivery process. It asks whether an attacker can manipulate source changes, workflows, runners, dependencies, credentials, artifacts, or deployment permissions.

Website security protects the deployed system. It asks what users and attackers can reach after release, including application behavior, authentication, authorization, security headers, TLS, exposed services, client-side secrets, and infrastructure configuration.

Consider three situations:

• A secure pipeline deploys an application with broken authorization. The delivery process behaved correctly, but the product is unsafe.
• A secure application is built by a compromised pipeline. The code review may look clean, but the released artifact cannot be trusted.
• Source code and pipeline controls are sound, but the production proxy omits a security header or exposes an origin service. The issue exists only after deployment.

That is why mature teams verify both the path to production and the result running in production.

What CI/CD controls cannot prove

A protected branch and signed artifact do not prove that:

• Users cannot access another user's records.
• Production CORS and Content Security Policy are correct.
• TLS, DNS, and email authentication are configured safely.
• A deployment did not expose a debug route or environment file.
• The website meets performance and technical SEO requirements.

What a website scan cannot prove

An external scan cannot prove that:

• Workflow files require independent approval.
• Runners are isolated from one another.
• Cloud deployment roles follow least privilege.
• Third-party actions are pinned and governed.
• Artifacts are signed and verified.
• Pipeline audit logs are complete.

The two reviews answer different questions. Combining them closes gaps that either one would leave behind.

How to Secure Your Deployed Website With FlawPilot

FlawPilot helps teams check the code they are shipping and the public result after deployment. It is a supporting control, not a replacement for the CI/CD governance described above.

Scan the deployed website or web application

A FlawPilot public scan reviews externally visible signals across security, performance, infrastructure, and technical SEO. It can surface issues such as security-header gaps, TLS configuration, CSP and CORS concerns, DNS and email-authentication problems, exposed services, Core Web Vitals, caching, canonical tags, robots directives, and sitemap issues.

This outside-in view matters because the deployed result can differ from the repository. Hosting platforms, reverse proxies, CDNs, DNS, environment settings, and production-only integrations can introduce problems after the build completes.

Scan the connected source repository

FlawPilot's opt-in source-code scanning checks a connected repository for insecure code patterns, exposed secrets, and vulnerable dependencies. That gives teams an inside view to complement the public scan.

Source scanning does not prove that every pipeline control is secure. It can help identify risks in the code and dependencies being delivered, while pipeline IAM, runner isolation, artifact signing, approval rules, and audit logging still require their own controls.

Add a scan to the CI/CD workflow

FlawPilot supports CI/CD integration through its REST API. Teams can trigger a scan, wait for the result, read the scores, and decide whether a job should warn or fail when a selected threshold is missed. The documented workflow patterns cover GitHub Actions, GitLab CI, and Bitbucket Pipelines.

Start in warning mode if the team has not established a baseline. Review several real runs, fix high-impact findings, and then set a threshold that reflects the application's risk. A score should support the release decision, not replace engineering judgement.

Store the FlawPilot API key in the CI provider's protected secret storage. Do not commit it to the repository. Give the job only the permissions and network access it needs.

Review the fix and verify production

FlawPilot provides prioritized findings and remediation guidance. For supported findings, AI-assisted fixes can suggest configuration, header, or code changes.

Treat every suggestion as a proposed change. Review it, test the affected journey, deploy it through the normal controlled process, and scan again. A local edit or merged pull request is not proof that the production response changed.

Know what FlawPilot does not replace

FlawPilot does not replace:

• Repository and CI identity management
• Branch protection and independent approvals
• Runner isolation and network segmentation
• Secret-manager design and credential rotation
• Third-party service governance
• Artifact signing and provenance
• Central pipeline audit logging
• Manual penetration testing for complex business logic
• Incident response when compromise is suspected

Use FlawPilot to help detect code and deployed-site gaps, prioritize work, and verify fixes. Use the OWASP CI/CD controls to protect the system that builds and delivers those changes.

Run a free FlawPilot scan to review the public security, performance, infrastructure, and SEO signals of your deployed website or web application.

Final Thoughts

CI/CD automation should make delivery consistent, not make compromise easier to distribute. The OWASP Top 10 CI/CD Security Risks gives teams a structured way to find where one identity, integration, runner, dependency, or artifact has been trusted too broadly.

Start with the actual path your software takes from commit to production. Reduce permissions at every step, separate untrusted work from release authority, verify what you deploy, and retain enough evidence to investigate unusual activity.

Then inspect the deployed result. A secure pipeline can still release an insecure application, and a strong application can still be undermined by a compromised delivery process. Protecting both is what turns a fast release process into a trustworthy one.