Control read and write access to source code, development tools and software libraries, since these are sensitive assets that shape what your systems do.
What an auditor, or Sekit's evidence engine, asks for.
CI/CD pipeline security
The security controls in the automated build-and-deploy process, including containers and infrastructure-as-code.
From the Sekit evidence catalog
In practice
Source code access control usually lives inside whatever platform hosts the repository, GitHub, GitLab or Bitbucket, rather than a separate policy document. An SME will show branch protection rules and required reviews as evidence, but the gap auditors find is the build pipeline itself: the credentials and secrets that let the pipeline write to production often have broader access than any individual developer, and nobody has reviewed who can trigger a deploy or edit the build definition directly. A former contractor's repository access, granted for a single project, is rarely revoked the day the engagement ends.
Common gaps
Repository branch protection restricts direct pushes, but the CI/CD pipeline's own credentials can bypass those restrictions entirely.
Access to edit build definitions and deployment scripts is not reviewed separately from access to the source code itself.
Former contractors retain read access to private repositories months after their engagement ended because offboarding does not cover source control.
Questions your auditor will ask
Who can push directly to the source code without going through review?
Nobody, branch protection requires an approved pull request before code merges, and the pipeline cannot be tampered with because build definitions and secrets are locked down.
Can the deployment pipeline be modified without anyone noticing?
No, build definitions, secrets and deployment steps are technically locked down and each pipeline stage enforces its own security gate.
Is access to source code reviewed when someone leaves the team?
Repository access is tied to the identity provider, so it is revoked automatically as part of the offboarding process.
Where regulation demands it
NIS2 Article 21 requires configuration management (6.3) and controlled change management (6.4) for systems handling source code and build definitions.
ENS mp.sw.2 requires controlled acceptance and commissioning procedures, which extends to who can modify code reaching production.
Related controls
Via the shared Sekit CSF topic, not the framework's own index.