Skip to main content

Process Risks in Modern CI/CD

The CI/CD pipeline is today one of the most critical assets of any organisation that develops software continuously.
Everything that reaches production - code, configuration, infrastructure, artefacts - inevitably passes through this mechanism.

For a long time, CI/CD was seen merely as an automation tool: compile, test, package, distribute.
That view is no longer sufficient.

In the current context, CI/CD is an operational decision system, where it is determined, automatically or semi-automatically:

  • what may move forward;
  • what must be blocked;
  • when a version is considered acceptable;
  • who takes responsibility for a promotion.

The pervasive adoption of advanced automation - regardless of the concrete technology - does not change this reality, but it accentuates the process risks associated with the pipeline.

This document identifies those risks and establishes clear prescriptions for mitigation, validation and evidence, ensuring that CI/CD remains:

  • deterministic,
  • auditable,
  • reproducible,
  • governable,
  • and with explicit human accountability.

🎯 Fundamental principle​

CI/CD may execute actions,
may produce signals,
may generate recommendations.

But it cannot take responsibility.

The final decision on any irreversible action - promotion, deploy, rollback, exposure to users - is always human, assigned to an explicit role and supported by verifiable evidence.

🧭 CI/CD as a critical decision system​

Treating CI/CD as simple automation leads to systemic errors.

In practice, the pipeline:

  • replaces the former release committees;
  • encodes organisational policies;
  • materialises security requirements;
  • creates or destroys evidence of compliance.

Any conceptual failure at this point propagates to the whole lifecycle.

For this reason, the risks associated with automation in CI/CD must be treated as process risks, and not as isolated technical problems.

⚠️ Risk R1 - Non-determinism of the pipeline​

Description​

A pipeline becomes non-deterministic when identical runs do not produce equivalent results, without any explicit change to the code or the versioned configuration.

In this scenario, the result no longer depends only on:

  • source code;
  • the pipeline definition;

and comes to depend on implicit context, often neither versioned nor controlled.

How it arises​

  • Configurations resolved dynamically at run time;
  • Steps generated or altered without an explicit record;
  • Volatile external dependencies;
  • Environmental context not pinned.

Impact​

  • Impossibility of reproducing historical builds;
  • Inconclusive audits;
  • Incidents that cannot be analysed retroactively;
  • False confidence in previous results.

Prescribed mitigations​

  • The pipeline must be treated as a versioned artefact;
  • The pipeline definition must be explicit and declarative;
  • Clear separation between:
    • the pipeline definition;
    • the pipeline run;
    • the results produced.

Minimum evidence required​

  • Versioned pipeline definition (e.g. YAML/DSL);
  • Unambiguous identification of the version run;
  • Complete run logs;
  • Clear association with a commit/hash.

Relates to. Violates CIC-001; materialises MT-130.

⚠️ Risk R2 - Confusion between automatic suggestion and effective decision​

Description​

Results presented as scores, ratings, priorities or recommendations are often interpreted, in practice, as final decisions.

This confusion is subtle, but dangerous:
a poorly defined soft gate turns into a hard bypass.

How it arises​

  • Ambiguous language in the outputs;
  • Operational pressure for speed;
  • Progressive automation without redefining responsibilities.

Impact​

  • Improper promotions;
  • Silent bypass of security controls;
  • Difficulty in assigning responsibility after an incident.

Prescribed mitigations​

  • Gates must be explicit, binary and unambiguous;
  • The final decision must require named human approval;
  • There must be a formal distinction between:
    • automatic signal;
    • promotion decision.

Minimum evidence required​

  • Record of the decision;
  • Identity of the owner;
  • Timestamp and context of the approval;
  • Reference to the evidence considered.

Relates to. Violates CIC-004; materialises MT-126.

⚠️ Risk R3 - Plausible evidence without empirical execution​

Description​

Well-structured, convincing or complete outputs do not constitute evidence if they are not associated with real, observable execution.

In modern CI/CD, the appearance of rigour can mask the absence of effective validation.

How it arises​

  • Aggregated reports with no link to concrete execution;
  • Synthesised or derived outputs;
  • Excessive abstraction over tests or scans.

Impact​

  • Failed audits;
  • False perception of coverage;
  • Decisions based on appearance, not on facts.

Prescribed mitigations​

  • Evidence must always derive from observable execution;
  • Each relevant result must be traceable to:
    • a test;
    • a scan;
    • a validation actually executed;
  • Non-verifiable outputs must not be accepted as evidence.

Minimum evidence required​

  • Execution logs;
  • Artefacts produced;
  • Return codes;
  • Explicit reference to the action executed.

Relates to. Violates CIC-005; materialises MT-129.

⚠️ Risk R4 - Exfiltration of secrets and sensitive context​

Description​

The pipeline handles highly sensitive information:

  • proprietary code;
  • secrets;
  • configuration;
  • intermediate artefacts;
  • context-rich logs.

Any external dependency or implicit export mechanism constitutes a potential leakage vector.

How it arises​

  • Excessive logging;
  • Debug active in production;
  • Implicit upload of context;
  • Lack of data segregation.

Impact​

  • Exposure of secrets;
  • Leakage of intellectual property;
  • Legal or contractual non-compliance.

Prescribed mitigations​

  • Principle of minimum necessary context;
  • Systematic reduction of sensitive logging;
  • Explicit policies for the use of external systems;
  • Regular review of configuration and outputs.

Minimum evidence required​

  • Applicable policies;
  • Validated configuration;
  • Documented reviews;
  • Evidence of log control.

Relates to. Violates CIC-003; materialises MT-120, MT-131.

⚠️ Risk R5 - Dilution of operational accountability​

Description​

When the pipeline “decides”, no one decides.

The absence of an explicit human owner destroys the notion of non-repudiation and compromises the governance of the process.

How it arises​

  • Automation without redefinition of roles;
  • Lack of clear ownership per environment;
  • Organisational ambiguity.

Impact​

  • Incidents without an owner;
  • Ineffective escalations;
  • Governance and audit failures.

Prescribed mitigations​

  • Each promotion must have an explicit human owner;
  • Responsibilities must be associated with clear roles;
  • Irreversible actions require a named decision.

Minimum evidence required​

  • Role → action mapping;
  • Promotion records;
  • Complete history of decisions.

Relates to. Violates CIC-011; materialises MT-128.

📊 Operational summary of the risks​

RiskWhere it occursKey mitigationEvidence required
R1Pipeline definitionExplicit versioningYAML + logs
R2Decision gatesHuman approvalNamed record
R3OutputsObservable executionArtefacts
R4ExecutionContext containmentPolicies
R5PromotionClear accountabilityAudit trail

🧩 Conclusion​

Automation in CI/CD is not the problem.
The problem arises when automation implicitly replaces decision, accountability or evidence.

A well-designed pipeline:

  • speeds up the process;
  • reinforces security;
  • improves quality;
  • and increases, rather than reduces, the capacity for governance.

This document establishes the invariants needed for CI/CD to remain a reliable control instrument, even in a context of pervasive automation and growing complexity.