Not necessarily. A sub-workflow can run with different, weaker or missing controls than the main flow that calls it, and platforms often give no single view of the gap. Treat every sub-flow as its own component: document inputs and outputs, validate data at the boundary and apply the same security standard.
The problem
OWASP's Vulnerable and Untrusted Components (CD-SEC-06) describes how nested logic obscures security flaws. A main workflow may rely on sub-workflows or prebuilt components, each with different controls, and the platform often lacks a unified view of the gaps while inherently trusting the underlying functionality.
OWASP's example: a builder creates a subflow that publishes a status update to a webhook for business intelligence ingestion. One solution uses it for business status updates. Another reuses it and unknowingly includes personal data, which then leaves the system.
Why reuse spreads the problem
A helpful sub-flow gets copied. If it is flawed, every app that calls it inherits the flaw, and one fix has to be found and applied in many places. OWASP notes the same dynamic with AI-suggested blocks reused in several parts of an app.
Questions for each sub-flow
| Question | Why |
|---|---|
| What inputs does it expect, and in what format? | Prevents unexpected data arriving |
| What does it return or send out? | Reveals leakage |
| What identity does it run as? | May differ from the parent |
| Which connectors does it hold? | Expands the blast radius |
| Does it log, and what? | Gaps and over-logging |
| Who owns it? | Someone must patch it |
Practices that work
- Write a short contract for each sub-flow: inputs, outputs, data classes allowed, identity and owner.
- Validate data entering the sub-flow, even when the parent is trusted. OWASP advises clearly documenting what a sub-workflow expects and what should be validated beforehand.
- Make sure each component follows the security controls of the core application.
- Build standardized, secure sub-components for common tasks such as sending a notification or writing a record, and have people reuse them.
- Track where each shared component is used, so a fix reaches every caller.
A simple dependency map
| Sub-flow | Owner | Used by | Data allowed | Last review |
|---|---|---|---|---|
| Send status to dashboard | Ops lead | 5 apps | Counts, no personal data | Q3 |
| Create ticket | Support lead | 3 apps | Names, ticket text | Q3 |
| Upload file | Platform team | 7 apps | Non-sensitive only | Q2 |
Keep the map beside the app inventory. When a flaw is found in one component, the map tells you whom to call.
Testing the boundary
Pass unexpected input into the sub-flow directly: empty values, overlong text, extra fields. Confirm it rejects or ignores them and does not forward them on. Then inspect what it sends outward with a record that includes a sensitive field, and confirm that field does not appear.
Where Safeguard fits
Where components are written as code and stored in repositories, Safeguard's SBOM generation and dependency scanning list their packages and flag known issues. The free scan is at https://gold.safeguard.sh/scan. Visual flows inside a platform need the platform's own dependency views.
Quick check
Should every sub-flow have an owner?
Yes. A shared component without an owner will not be patched.
Is validating input in a trusted parent flow enough?
No. Validate at the sub-flow boundary too, because other callers may send different data.
Sources
Last reviewed: 19 October 2026.
