Skip to main content

Advanced Recommendations for CI/CD Security

This file complements the main controls defined in this chapter with advanced practices, aimed at organisations with greater maturity, regulated environments or critical needs for traceability, auditability and resistance to sophisticated attacks.

These recommendations do not replace the mandatory controls per risk level, nor do they delegate operational decisions to automatic mechanisms.
Their objective is to reinforce detection, validation and governance, always maintaining explicit human decision, empirical evidence and non-repudiation.

🔁 Continuous integration of findings into the development cycle​

  • Automatic creation of issues for critical or blocking security findings (e.g. GitHub Issues, Jira);
  • Direct link between pipeline findings and the backlog items of product teams;
  • Tags and labels on findings to facilitate triage and ownership (e.g. team:frontend, risk:L3);
  • Real-time feedback via Slack, Teams or CI/CD bots.

Governance note:
Automatic creation of findings speeds up response, but does not replace human triage nor the decision on acceptance, exception or blocking.

🧪 Attack simulation and adversarial validation of pipelines​

  • Intentional bypass tests: attempting to force a deploy with a failed SAST, without provenance or with ignored findings;
  • Assessment of runner permissions: executing actions with simulated privilege escalation;
  • Simulated executions with revoked tokens, blocked environments or altered artefacts;
  • Man-in-the-pipeline attacks in staging environments (verification of reaction).

These practices make it possible to validate not only technical controls, but also:

  • organisational reaction,
  • clarity of responsibilities,
  • effectiveness of alerts and blocks,
  • quality of the evidence produced during simulated incidents.

🔒 Application of Zero Trust principles in the pipeline​

  • Zero trust between repositories, runners, artefacts and environments - each element must be authenticated, validated and isolated;
  • All pipeline commands must assume that the runner may be malicious, and vice versa;
  • Integration with external authorisation services (e.g. Rego/OPA, ZTA gateways).

Canonical principle:
Zero Trust in CI/CD does not mean “automating trust”, but rather automating continuous verification, keeping critical decisions outside the implicit control of automatic mechanisms.

📦 Control of external components used in the pipeline​

  • Restrictions on GitHub Actions or third-party scripts:
    • Allow only internal actions or actions of validated origin;
    • Mandatory use of @sha (digest) or @version pinning;
  • Validation of the integrity of remote files before execution;
  • Audit of the artefacts used in scanner tools (e.g. updates of CVE databases, linters).

These practices treat external components as supply chain dependencies, subject to:

  • explicit approval,
  • traceability,
  • periodic review.

🕵️ Monitoring and anomaly detection in pipelines​

  • Analysis of anomalous behaviour in CI/CD pipelines (e.g. irregular execution time, new step added, new external domain contacted);
  • Centralised logging with alerts for events such as:
    • Execution outside usual hours;
    • Changes to pipeline files without an approved pull request;
    • Runners executing jobs outside their defined scope.

Beyond detection, these capabilities must produce preservable evidence, with adequate retention and correlation between event, pipeline, artefact and decision taken.

📑 Continuous governance and cross-validation​

  • Integration with the organisational catalogue of applications and risk classification;
  • Periodic verifications that:
    • L3 applications keep the mandatory controls active;
    • Exceptions are being reviewed;
    • YAML templates and workflows are up to date and signed;
  • Formal versioning of the security policies applied in pipelines.

Continuous governance ensures that automation does not degrade control, and that deviations are detected before they become structural.

🧭 Process risks reinforced by these practices​

Beyond technical risks, these advanced recommendations explicitly mitigate process risks, such as:

  • Non-determinism of the pipeline and loss of reproducibility;
  • Implicit bypass of gates through outputs or recommendations;
  • Dilution of responsibility in promotions and exceptions;
  • Plausible evidence without underlying empirical execution;
  • Lack of early detection of operational deviations.

📉 Additional mitigated risks​

  • Execution of malicious external code without control (OSC&R: CI0001, CI0011);
  • Intentional bypasses with operational impact (OSC&R: CI0002, CI0014);
  • Untracked use of outdated or insecure actions/scripts;
  • Detection failures due to the absence of a feedback loop (OSC&R: SC0006, CI0016).