DevSecOps and Software Supply Chain

CI/CD Pipeline Security

We review the permissions, runners and secrets of your CI/CD pipeline. We ensure that a single compromised account cannot access production.

What it is

A CI/CD pipeline automates building, testing and deploying code to production. Write access to production and the most valuable secrets are usually controlled by the pipeline. If a developer account or third-party plugin can change pipeline steps, it gains those privileges. The review references the OWASP Top 10 CI/CD Security Risks and NIST SP 800-204D.

Scope

  • Who can change pipeline definitions and from which branch a release can be made
  • Isolation of runners and sharing between teams
  • Short-lived, job-based credentials (OIDC) instead of long-lived keys
  • Version pinning and permissions for third-party plugins and actions
  • Approval steps and protected environment rules for production deployment
  • Secrets in pipeline logs and traceability of changes

The need

When organizations need it

  • When a developer account or pipeline key is compromised or suspected to be.
  • When a supply chain attack is announced in a CI/CD plugin or build tool you use.
  • When teams start writing their own pipeline definitions and no one reviews them centrally.

Method

How we work

  1. Map

    We map all pipeline steps, the identities used and the systems accessed.

  2. Takeover paths

    We show the paths from a developer account or plugin to production.

  3. Hardening

    We work with your teams to narrow permissions and replace long-lived keys with short-lived identities.

  4. Retest

    After changes, we retest to confirm the same takeover paths are closed.

Outcome

What you have at the end

You have the identified takeover paths and the change that blocks each one. Retesting shows that unreviewed code cannot reach production through a single account.

Frequently asked questions

Which CI/CD platforms do you work with?

The assessment method is platform-independent. Recommendations are implemented using the features of your platform, such as GitHub Actions, GitLab CI, Azure DevOps or Jenkins.

Does the pipeline stop during the review?

No. The review is performed using configurations and read-only access. Changes are made with your teams' approval and according to your release schedule.

Are self-hosted runners risky?

They pose a risk when shared between teams and not cleaned between jobs. Isolation and recreating runners for each job reduce this risk.

DevSecOps and Software Supply Chain

Other services in this area

Let's talk about this service.

Tell us briefly what you need. We will agree on the scope and timing together in the first meeting.

Schedule a Meeting