Topic starter
11/10/2026 6:56 pm
TL;DR: Splitting CI and deployment workflows is not enough if the same execution environment, runner, credentials, or artifact path can still bridge test code into production authority, according to Testifysec. The practical lesson is that untrusted jobs need scoped permissions, short-lived credentials, protected promotion decisions, and verified artifacts.
Editorial analysis by NHI Mgmt Group, based on content published by Testifysec: “CI/CD Isolation: Keep Production Authority Away from Untrusted Code”.
Key questions
A: Split the workflow, but more importantly split the trust boundary.
Q: Why do short-lived credentials still need tight trust policies in CI/CD?
A: Short-lived credentials reduce persistence, but they do not reduce the blast radius of a bad issuance decision.
Q: What breaks when deployment approval sits inside the same code path being released?
A: The approval can no longer be trusted as an independent control.
Practitioner guidance
- Scope untrusted jobs to minimal repository permissions Remove deployment and signing authority from test jobs, and keep their access limited to the exact resources needed for validation.
- Separate runners for trusted and untrusted execution Do not reuse a privileged self-hosted runner for untrusted work unless the reset, isolation, and cleanup boundary is demonstrably stronger than the threat.
- Bind OIDC trust to narrow claims Configure cloud trust policies for the intended repository, environment, and other emitted claims, then limit the token's permissions and lifetime.
Bottom line: CI/CD separation only works when the execution environment, credentials, and artifact flow are also separated.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/10/2026 6:57 pm
CI/CD isolation is a trust-boundary problem, not a file-structure problem. Separate YAML files are useful for governance, but they do not stop credential reuse, runner reuse, or artifact reuse. The real control question is whether an untrusted job can influence a later privileged job without crossing an explicit security gate. Practitioners should design CI/CD as an identity- and authority-separation problem, not as a repository hygiene exercise.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
A question worth separating out:
A: Artifact verification proves that the object being promoted is the exact one that passed the gate. Observability only shows what happened during execution and may miss secret access, payload changes, or transient abuse. Useful evidence is not the same as control, so both are needed but they answer different questions.
👉 Read our full editorial: CI/CD trust boundaries must extend beyond separate workflow files