What do teams get wrong about dependency and script security in CI/CD workflows?

Teams often trust third-party packages and shared scripts more than they should. Malicious or altered dependencies can run during builds, while unsafe scripts can leak environment variables, inject commands, or manipulate artifacts. The right control set includes integrity verification, SBOM generation, continuous scanning, and peer review for operational scripts and external code pulled into the pipeline.

Why dependency trust becomes a build-time security problem

CI/CD workflows turn dependencies into active execution paths, not passive inputs. A package, action, or shared script can run with the pipeline’s network access, repository permissions, and secret exposure, which means “it built successfully” is not the same as “it was safe.” The main mistake is treating source provenance, artifact integrity, and execution trust as separate concerns when they converge in the pipeline.

That is why build integrity needs a supply-chain mindset. Provenance controls such as SLSA matter because they help teams distinguish intended build inputs from tampered ones, while ecosystem guidance from OpenSSF supports the wider problem of open-source package trust and maintainer risk. In practice, the question is not whether the dependency is popular, but whether the pipeline can verify what actually ran and what it produced.

Teams also understate how dependency risk changes when the pipeline has long-lived secrets or broad token scope. NHIMG’s own research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes dependency execution a direct exposure path rather than a theoretical one. When build steps can read environment variables or write artifacts, a compromised package can pivot from code import to credential theft in one run.

Why shared scripts are often the weakest control in the workflow

Operational scripts are frequently treated as internal housekeeping, so they receive less review than application code even though they can alter the same production-facing systems. A shell script, deployment helper, or pipeline fragment can inject commands, rewrite files, or suppress checks with very little visible change in the repo. That makes script security less about language choice and more about whether execution authority is bounded and reviewable.

The common failure is inheritance of trust. Teams reuse scripts across projects, copy them into pipeline templates, or pin them to mutable branches and tags, then assume internal ownership is enough of a safeguard. That assumption breaks when a script is updated outside the review path, pulls in remote content at runtime, or depends on environment context that was never intended to be available to every job.

Good practice is to treat operational scripts as change-controlled build assets. Review should cover command construction, file handling, outbound network calls, artifact mutation, and any access to secrets or signing material. If a script can influence what gets shipped or what gets published, it belongs in the same integrity conversation as any other release-critical component.

What strong teams verify before they trust the pipeline

Strong teams do not rely on a single control to catch bad dependencies or unsafe scripts. They combine integrity verification, SBOM generation, continuous scanning, and peer review because each control sees a different failure mode. Dependency scanning helps surface known risk, SBOMs help establish what entered the build, and review helps catch logic that automated scanners will miss.

Peer review is especially important for scripts that control environment setup, artifact signing, deployment, or release promotion. A script may be syntactically valid and still be unsafe if it expands variables unsafely, shells out with untrusted input, or copies secrets into logs and artifacts. The safest pattern is to require explicit approval for changes that can affect trust boundaries, not just code quality.

For practitioner navigation, it helps to anchor the problem in software supply-chain controls rather than generic hardening. The most useful external references are the SLSA build provenance model and the OpenSSF supply-chain ecosystem, because both push teams toward verifiable inputs, reproducible trust, and clearer build accountability.

Risk and Threat Considerations

CI/CD dependency and script abuse is risky because it converts ordinary delivery tooling into a high-trust execution channel. A malicious package, compromised action, or altered script can exfiltrate secrets, poison artifacts, or establish a durable foothold inside the release process before defenders notice.

Failure mechanism: The attacker abuses trusted build-time execution, often through dependency resolution, mutable script references, or overly broad job permissions, to run code with access to secrets, tokens, or signing steps.

Impact: The result can be secret theft, artifact tampering, malicious releases, repository compromise, or downstream compromise of systems that trust the pipeline’s outputs.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS 15 — Service Provider Management	CI/CD often depends on third-party packages and hosted build services.
	CIS 16 — Application Software Security	Pipeline scripts and build logic are software assets that need review and testing.
	CIS 18 — Penetration Testing	Supply-chain and pipeline abuse is best validated through adversary-style testing.
Recommendation — Assess third-party build dependencies and service providers before allowing them into delivery workflows. Review and test pipeline scripts and build automation with the same discipline as application code. Exercise CI/CD trust boundaries with attack simulation to find exposed secrets and unsafe execution paths.
NIST CSF 2.0	PR.DS — Data Security	CI/CD workflows must protect secrets, source inputs, and released artifacts from tampering and exposure.
	PR.IP — Information Protection Processes and Procedures	Dependency review, SBOMs, and script review are process controls for pipeline integrity.
	DE.CM — Continuous Monitoring	Continuous scanning is central to spotting dependency drift and malicious changes in pipelines.
Recommendation — Protect build inputs, secrets, and artifacts with integrity and access restrictions. Formalize dependency approval, script review, and supply-chain verification procedures. Continuously monitor builds and dependencies for tampering, anomalies, and newly exposed risks.
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Exposure	CI/CD compromise frequently exposes tokens, keys, and other pipeline secrets.
	NHI-04 — Overprivileged Non-Human Identities	Build jobs and automation often carry excessive permissions that widen blast radius.
	NHI-06 — Third-Party and Supply Chain Risk	External packages and shared actions are supply-chain dependencies that can become attack vectors.
Recommendation — Store pipeline secrets outside code and rotate any exposed credentials immediately. Reduce pipeline credential scope and remove permissions that are not needed for the job. Verify provenance and pin trusted dependencies before allowing them into CI/CD.

Practitioner Guidance

What to prioritise: Protect the trust boundary first. If a workflow step can reach secrets, publish artifacts, or trigger deployments, treat that step as security-critical even when the code looks like ordinary automation.

What to verify: Confirm that dependencies are pinned to immutable versions, scripts are reviewed like code, and pipeline jobs only receive the minimum credentials needed for that stage. If a build can succeed without access to a secret, remove that secret from the job.

Common mistake: Teams often scan for vulnerable packages but ignore the script layer, where a single line can leak credentials or alter release outputs more directly than a known CVE.

Practitioner takeaway: The real control objective is not just “known-good dependencies,” it is “no unreviewed code path can execute with more privilege or secret access than the job actually needs.”