OWASP CICD-SEC-8, Ungoverned Usage of 3rd Party Services, is the risk that apps, plugins and tokens connected to source control and build systems gain broad access without approval or review. A compromise of one integration can reach far beyond it. Control it by approving, scoping, monitoring and removing integrations.
Why is this risk easy to create?
OWASP notes that connecting a third party to a source control system takes seconds to minutes and can grant anything from reading code in one repository to fully administering the organization. In many cases no special approval is required before it happens.
Build systems are the same. Adding third-party functionality to a pipeline is often one or two lines in a configuration file, or installing a plugin from the build system's marketplace, such as an action in GitHub Actions. That functionality then runs as part of the build with full access to whatever the pipeline stage can reach, including secrets.
Because this is so easy, nobody keeps a list. OWASP says organizations struggle to see which third parties have access to which systems, by what method, with what permission level, and how much of that permission is actually used.
What is the impact?
OWASP's point is that your organization is only as secure as the third parties you implement. With loose control, role-based access and least privilege cannot be enforced. A single compromised third party can be used to do damage far outside the system it connects to. Their example: a third party with write permission on a repository can push code, which triggers a build, which runs the adversary's code on the build system.
Real incidents show the pattern. OWASP's references include a code coverage tool in CI being compromised to steal environment variables from builds, and attackers who took over a static analysis vendor engineer's account. Read the primary write-ups for details instead of relying on summaries.
What does OWASP recommend?
It frames control as a lifecycle with four stages.
Approval. Vet third parties before they get access, and set permissions according to least privilege.
Integration. Keep continuous visibility of every integration: the method (marketplace apps, plugins, OAuth applications, programmatic tokens), the permission granted, and the permission actually used.
Visibility over ongoing usage. Scope each third party to the resources it needs and remove unused or redundant permissions. Third parties in the build should run in a scoped context with limited access to secrets and code, and strict ingress and egress filtering.
Deprovisioning. Review integrations periodically and remove those no longer used.
A constructed example
A team of 60 engineers lists the OAuth apps and actions across its source control organization and finds 47 integrations. Nobody can name an owner for 19. Eleven have write access to repositories, and four were granted by people who have since left. The security lead makes a short register with owner, purpose, permission and last use, and removes the 19 orphans after a two-week notice. For the remaining apps she narrows write access to read access where the app only reports. Pipeline actions are pinned to a specific commit instead of a moving tag, and secrets are available only to the jobs that need them. The register becomes part of the offboarding checklist.
How to check or apply this
- List every app, plugin, action, OAuth app and token connected to source control, CI and registries.
- Record owner, purpose, permission granted, permission used and last activity.
- Require approval for new integrations, with a named reviewer.
- Reduce permissions to what is used. Prefer read access.
- Pin pipeline actions and plugins to immutable versions, and review updates.
- Give jobs only the secrets they need, and restrict outbound network access from build runners.
- Review the list quarterly. Remove integrations with no owner or no recent use.
- Add integration removal to your offboarding and vendor exit steps.
Safeguard's policies and gates and its dependency and SBOM scanning can enforce rules on what enters a pipeline and what dependencies a build uses, which supports steps 3 and 5. The integration inventory itself needs a process of its own.
Quick check
Is a pipeline plugin a third party?
Yes. OWASP counts plugins and marketplace actions as third-party integrations that run with the access of the stage they execute in.
What is the first thing to do?
Make a list. OWASP identifies lack of visibility into which third parties have which access as the core problem.
Sources
Last reviewed: 18 October 2026.
