The pipeline that builds and deploys your software holds more privileges than most administrators. It reads the source code, carries the signing keys and the cloud credentials and writes to production. It is also assembled from third-party actions, plugins and packages that change without notice.
We test this path the way an attacker would: what a contributor with minimal rights can do, what a malicious dependency or pull request can reach, and whether the artefact that is deployed is provably the one that was reviewed.
Artefacts and registries: signing, provenance, access control
Deployment: separation of duties, approvals, infrastructure as code
02Approach
How the work is done
01
Mapping
We trace the path from a commit to production and list the systems, identities and secrets along it.
02
Configuration review
Repositories, pipelines and registries are reviewed against the OWASP Top 10 CI/CD Security Risks and the SLSA requirements.
03
Attack simulation
From the positions of an external contributor, an internal developer and a compromised dependency we attempt to reach secrets and to alter what is built. The work is done on forks and test projects wherever that proves the point.
04
Hardening plan
Changes are ordered by the attack paths they close. Each comes with the configuration that implements it.
We run harmless proof code that shows what would be reachable, for example the name of a secret and not its value. Production pipelines are touched only where the rules of engagement allow it; most paths are proven in a test project with the same configuration.
We use a managed CI service. Is the provider not responsible for security?
The provider secures the platform. What you put on it is yours: permissions, triggers, secrets and third-party components. That is where attacks on pipelines succeed.
Does this include a software bill of materials?
We verify that the bill of materials your build produces is complete and matches the artefact. Generating and maintaining it is part of your build; we recommend how.