[KEP-9] Trusted Extensibility Features in Security Model

[rashidakanchwala]

Summary

Kedro allows custom runners, datasets, hooks, config loaders, and plugins by design. If these contain malicious code, that's the developer's responsibility, not a Kedro vulnerability.

Problem

Security researchers report "vulnerabilities" when Kedro runs user-provided code.

Example: kedro run --runner my.CustomRunner → reported as "arbitrary code execution vulnerability"

Kedro is designed to do this. We need to clarify what's user responsibility vs. framework bug.

Proposal

Add a new section to the security model explaining that Kedro's extensibility features are designed to run user code.

The section will list the extensibility points (runners, datasets, hooks, config loaders, plugins, custom resolvers) and state clearly: if you write or install malicious code through these features, that's your responsibility, not a Kedro vulnerability.

We'll also clarify what still counts as a framework bug: configuration files executing code unintentionally, bypassing documented security restrictions, or the framework exposing credentials.

Benefits

• Fewer false reports
• Clear responsibility boundary
• Less time on non-issues

Implementation

Update docs/about/security_model.md once approved.

[datajoely]

You might also want to put it behind a flag the user has to opt in to

[rashidakanchwala]

Opt-in for using custom runners for instance?

[datajoelypx]

yes

[deepyaman]

Honestly, I don't think this requires a KEP/vote. I don't even see this as a change to Kedro.

Kedro has ALWAYS been a framework that is extensible by design, that users own a lot of custom logic for. These aren't security vulnerabilities. Are the reporters even security researchers? 😂

My personal preference would be to put the responsibility on reporters to explain how the "vulnerability" would be exploited based on how Kedro is used, and to close anything without sufficient work explaining that, following a policy similar to https://tiangolo.com/open-source/contributing/#closing-automated-and-ai-prs (I like the policy to be applied for code contributions, too, honestly).

+1 if it helps move forward with this :)

[Galileo-Galilei]

Hard agree on this : I see it more as a documentation than a change, and not something worth a KEP. I also agree that the burden should be on people reporting vulnerabilities, especially if we can discard it in a glance and estimate it is the expected behaviour of the framework. EDIT : But like @deepyaman, happy to +1 if needed!

That said, I think the framework may (should ?) be more informative on the auto discovery of plugin hooks mechanismd. I know a lot of kedro users that do not understand how kedro-mlflow works behind the scene and I am always afraid that it is very easy to add a hook from a plugin without a user noticing (there is a log, but it should be more catchy).