Why Awareness Training Doesn’t Stop Citizen Developer Security Risk

• A Forrester Developer Survey found 39% of organizations already use low-code tools to empower citizen developers, with another 27% planning to adopt the approach within the following year.

• Security teams frequently cannot see what citizen developers build in real time, which turns well-intentioned productivity fixes into invisible exposure rather than reviewed changes.

• OWASP's Citizen Development Top 10 catalogs recurring failure patterns including blind trust, authorization misuse, sensitive data leakage, and security misconfiguration in citizen-built apps.

• SQL injection, long assumed to be a legacy-code problem, has resurfaced as a real risk in low-code and no-code development, as shown by the Clop ransomware group's exploitation of a SQL injection flaw in MOVEit.

Why doesn't security awareness training stop citizen developer risk?

Awareness training doesn't stop citizen developer risk because the problem isn't a knowledge gap, it's a speed and visibility gap. Business users building apps, automations, and now AI agents are moving faster than policy documents and training decks can keep up with, and even employees who genuinely know the rules will still forget, skip, or misinterpret them under deadline pressure. An analysis of why awareness campaigns fail to change citizen-developer behavior points to a more basic issue underneath that: IT and security teams often can't see what a citizen developer builds in real time at all, which means the exposure is invisible long before anyone gets a chance to correct it.

A common real-world version of this: someone in Finance connects a spreadsheet or dashboard tool to a third-party service to save a few hours a week, without looping in IT, because from where they're sitting it's just a productivity fix, not a security decision. Multiply that pattern across every department building its own automations and the training-based model breaks down structurally, not because people are careless, but because no amount of training scales to catch every individual judgment call made outside IT's view.

How fast is citizen development actually growing inside enterprises?

Quickly, and it's no longer a fringe practice. A Forrester Developer Survey found that 39% of organizations already use low-code tools to empower citizen developers, with another 27% planning to adopt the approach within the following year, meaning a clear majority of enterprises are either already there or headed there soon. Forrester researcher Chris Gardner described the underlying risk plainly in independent reporting on Forrester's prediction about citizen-developer risk: citizen developers "aren't necessarily ready for developing code. They're a bit of amateurs and they're not really trained on things like application security or data sensitivity." That's not a knock on the people building these tools; it's a description of a role that was never designed to carry security responsibility in the first place.

Source: Forrester Developer Survey, as reported in independent industry press covering Forrester's low-code and citizen development research.

What kinds of security failures show up most often in citizen-built apps?

The most common failures cluster around a handful of recurring categories rather than one single flaw. OWASP's Citizen Development Top 10 project catalogs these patterns explicitly, including blind trust in citizen-built tools without verification, authorization misuse from improper permission assignment, sensitive data leakage from inadequate handling of confidential information, and asset management failures from poor tracking of what's actually been built. Security misconfiguration and the use of unvetted, untrusted components round out the list, and both show up repeatedly in real citizen-built apps because the platforms that make building easy don't automatically make the output secure by default.

What makes these categories persistent rather than one-off is that they aren't really coding mistakes in the traditional sense; they're a mismatch between how much trust a platform extends to whatever gets built on it and how much security review that output actually receives. A low-code platform doesn't distinguish between an app built by a trained engineer and one built by someone who has never had a security review in their life, which means the platform's default permissiveness becomes the app's default risk profile.

Part of why this is hard to catch manually is sheer volume. Citizen developers build because a self-service tool is faster than waiting weeks for an IT project queue to open up, and that speed advantage is exactly what makes after-the-fact manual review impractical once an organization has hundreds or thousands of these workflows running. Many business users also simply don't recognize what they're handling as sensitive; a spreadsheet with customer records or internal financials doesn't announce itself as regulated data, and a well-meaning integration connecting that data to a public-facing tool can create real exposure without anyone involved realizing a security boundary was crossed.

Why did SQL injection resurface as a citizen-developer risk?

SQL injection resurfaced as a citizen-developer risk because a widely held assumption, that low-code and no-code platforms are too abstracted from raw code to be vulnerable to it, turned out to be false. Research into SQL injection risk inside low-code and no-code development points to the Clop ransomware group's exploitation of a SQL injection flaw in the MOVEit file transfer software as a stark real-world example, a campaign estimated to have generated the group up to $100 million from exfiltrating data across thousands of corporate clients and tens of millions of individuals. That single vulnerability class, decades old in traditional software, is proving just as viable inside newer low-code and no-code environments, largely because citizen developers building on those platforms typically have no application security training and existing security tools weren't built with these environments in mind.

Three factors keep this risk alive rather than fading out as platforms mature: the sheer volume of citizen-built apps being created without security training, a persistent misconception that injection flaws can't occur outside traditional code, and application security tooling that, in many cases, still isn't built to scan low-code and no-code environments the way it scans conventional software.

What actually reduces citizen developer risk if training doesn't?

What works is building safety into the platforms and workflows themselves rather than relying on people to remember rules under pressure. A breakdown of shadow engineering risk across low-code and RPA platforms frames this as a distinct architectural layer, sitting on top of standard SaaS security, that requires its own discovery and guardrails because standard security tooling doesn't reach the apps and automations built within these platforms. Practically, that means maintaining a real inventory of what's been built, identifying which apps and automations handle sensitive data or have risky configurations, and routing that information to the people who can fix it, rather than issuing a policy and hoping it's followed.

A governance dashboard that tracks centralized ownership across every citizen-built app, flow, and agent is one way organizations have operationalized this, surfacing orphaned or undocumented apps automatically instead of waiting for a training reminder to prompt someone to self-report what they've built. That shift, from asking people to behave differently to designing systems that don't depend on perfect behavior, is the difference between a policy that looks good in a slide deck and one that actually holds up once citizen development scales past what any single security team can manually track.

None of this means citizen development itself is the problem. The business case for letting non-engineers build their own tools is real: teams move faster, IT backlogs shrink, and departments solve problems without waiting on a project queue. The risk isn't that citizen developers exist; it's that most organizations are running that model without the visibility layer that would let security teams catch a risky configuration before it ships rather than after it's already been running in production for months.

Frequently Asked Questions

Is citizen development a security problem because employees are careless?

Not primarily. The core issue is that security teams often can't see what's being built in real time, so even well-intentioned employees create exposure that goes uncorrected simply because no one outside their team knows it exists.

Can SQL injection really affect low-code and no-code applications?

Yes. Despite a common assumption that abstraction protects these platforms, low-code and no-code applications remain vulnerable to SQL injection, and real-world exploitation of this vulnerability class has caused large-scale data breaches.

What is the OWASP Citizen Development Top 10?

It is an OWASP project cataloging the ten most common security risk categories in citizen-developed applications, including blind trust, authorization misuse, sensitive data leakage, security misconfiguration, and poor asset tracking.

Does more security training for business users solve citizen developer risk?

On its own, no. Training doesn't scale to catch every individual decision made outside IT's view, which is why organizations increasingly pair training with automated discovery and governance of what's actually been built.