Third-Party and Integration Security
Section focus: Third-Party and Integration Security.
Best use: start with the section map below, then move into the deeper pages that match your role or stack.
Design note: this index was refreshed to act as a cleaner GitBook landing page instead of a plain directory listing.
Start with these pages
| Page | Why open it first |
|---|---|
| 📦 Marketplace, Actions, Images, Helm, and Public Component Review | High-value page inside Third-Party and Integration Security. |
| 🔄 Webhooks, OAuth, and SaaS Integration Security | High-value page inside Third-Party and Integration Security. |
| 🏃 Vendor Agents, Runners, and Build-Integration Trust Boundaries | High-value page inside Third-Party and Integration Security. |
Related sections
Intro: Product teams inherit real risk from third-party pipeline components, SaaS integrations, agents, runners, widgets, and public artifacts. This section helps reviewers decide when convenience becomes too much trust.
What this page includes
- public component and marketplace review
- webhook and OAuth integration trust decisions
- agents, runners, and build integration trust boundaries
- onboarding, ownership, and offboarding discipline
Section map
| Page | Why it belongs here |
|---|---|
| Marketplace, Actions, Images, Helm, and Public Component Review | Establishes review basics for public reusable components. |
| Webhooks, OAuth, and SaaS Integration Security | Covers common integration trust decisions inside products. |
| Vendor Agents, Runners, and Build-Integration Trust Boundaries | Focuses on components that execute code or touch sensitive runtime paths. |
| GitHub Actions and GitLab Components Review Playbook | Deepens source trust, version pinning, and secret-minimization review. |
| Third-Party Component Onboarding and Offboarding | Adds ownership, inventory, and retirement discipline. |
| Vendor Security Questionnaire for Engineering Integrations | Provides a short due-diligence template for engineering-facing vendors. |
Design bias
Treat external automation, plugins, and reusable components as trusted code with a lifecycle, not as static dependencies that can be approved once and forgotten.
Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.