Traditional review processes struggle because low-code and no-code platforms can produce thousands of applications and automations at speed. That volume makes manual security reviews too slow to keep up, leaving gaps in visibility and increasing the chance that insecure business logic, unsafe integrations, or weak governance will expose data, create supply-chain risk, or enable ransomware.
Where traditional review loses the thread
Traditional application review assumes a bounded queue of custom-built apps with clear ownership, stable release cycles, and a manageable number of dependency and access decisions. Low-code and no-code platforms break that assumption by shifting creation to business users and speeding up delivery, so review teams no longer see a small set of well-scoped applications. The result is a visibility problem as much as a speed problem.
That is why review becomes brittle when it is used as the only control. The reviewer is asked to judge not just code quality, but composition, connector use, data exposure, and workflow logic across a growing population of citizen-built apps and automations. Guidance for Non-Human Identities is relevant here because the same scale dynamics often apply to the credentials and tokens that these platforms consume, even when the application itself looks simple.
Manual review also struggles with business logic that is technically valid but operationally unsafe. A low-code workflow may pass a conventional app security checklist and still move sensitive data into an over-permissioned connector, trigger an unreviewed approval path, or expose an integration point that downstream systems trust too much. For that reason, platform-level controls matter as much as app-level inspection, especially when many builders reuse the same connectors and templates.
What security gaps emerge at platform speed
The most common failure is not a single catastrophic bug, but accumulation. Each low-code app may look modest, yet the platform can rapidly create thousands of apps, automations, and integrations, which multiplies the chance that one of them contains weak governance, excessive access, or an unsafe data flow. That volume also makes drift hard to detect, because the security posture changes faster than a manual review queue can follow.
Another gap is supply-chain style exposure through connectors, reusable modules, and third-party services. Once a workflow depends on external systems, the security question is no longer only “is this app secure?” but “is this app still safe when a connector, token, shared component, or upstream process changes?” NHIMG’s Guide to the Secret Sprawl Challenge is a useful companion perspective because low-code environments often inherit the same credential, token, and rotation problems that emerge anywhere secrets are embedded into fast-moving delivery pipelines.
Ransomware and data exposure become more likely when overly broad access is combined with weak governance. A workflow that can read, transform, and forward data across multiple systems can also accelerate exfiltration or destructive actions if the underlying permissions are excessive or the approval logic is weak. In practice, the platform becomes an amplifier: one mis-scoped automation can affect many records, many systems, and many users.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 6 — Access Control Management | Low-code risk grows when app builders gain broad data and connector access. |
| CIS 8 — Audit Log Management | Visibility gaps are central when many automations and apps are created quickly. | |
| CIS 16 — Application Software Security | Low-code still needs secure review of workflows, integrations, and logic before release. | |
| Recommendation — Enforce least privilege for platform users, connectors, and published automations. Centralize logging for app creation, connector use, and privilege changes. Apply security requirements to published workflows, connectors, and business logic. | ||
| NIST CSF 2.0 | GV.1 — Governance Policy, Roles, and Responsibilities | The main failure is weak ownership and governance over platform-built apps. |
| PR.AA — Identity Management, Authentication, and Access Control | Unsafe low-code environments often hinge on excessive access and weak connector control. | |
| DE.CM — Continuous Monitoring | Rapid app proliferation requires ongoing detection of risky workflows and drift. | |
| Recommendation — Define clear accountability for platform publishing, approval, and monitoring. Restrict builder, connector, and data access to the minimum required scope. Monitor new automations, unusual integrations, and privilege escalation events continuously. | ||
| OWASP Agentic AI Top 10 | A2 — Tool and Action Misuse | Low-code automations can misuse connectors and actions even without custom code. |
| A6 — Data Exposure and Leakage | Unsafe workflows can move sensitive data across connectors and apps. | |
| Recommendation — Constrain which external actions workflows can invoke and under what conditions. Classify and restrict data movement paths before publishing automation. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secret Sprawl and Credential Exposure | Low-code platforms often rely on embedded tokens, keys, and shared connectors. |
| NHI-03 — Excessive Privilege | Platform-generated automations commonly inherit more access than they need. | |
| Recommendation — Store and rotate platform credentials centrally instead of embedding them in workflows. Limit automation privileges to the minimum required for each approved use case. | ||
Practitioner Guidance
What to prioritise: Review the platform governance model before you try to review every app. The first questions are who can publish, which connectors are approved, where secrets live, and what telemetry exists for new app creation and privilege changes.
What to verify: Confirm that high-risk actions are controlled at the platform layer, not only in post-build review. If builders can create automations with production data access, outbound integrations, or embedded credentials without policy enforcement, traditional review is already too late.
Common mistake: Treating low-code and no-code work as “lighter-weight” application development. The code may be lighter, but the operational blast radius is often larger because non-developers can publish at scale, reuse sensitive connectors, and bypass the normal friction that slows engineering teams.
What good looks like: Security sees an inventory of apps, automations, owners, connectors, and privileged actions, with controls that flag risky patterns early. Review still exists, but it becomes targeted and exception-based rather than the only barrier.
Practitioner takeaway: If the platform can create software faster than review can inspect it, the control point must move left into policy, connector governance, and runtime visibility, or the review process will only document risk after it has already spread.
Related resources from NHI Mgmt Group
- What breaks when security review stops at pattern matching for application code?
- What breaks when software supply chain security is handled only through manual review?
- What breaks when AI agent security is handled like ordinary application security?
- What breaks when loyalty fraud is handled only through manual review?
