Having a security threat model for Quarkus?

[snazy]

I've been thinking about whether it would make sense to have a security threat model for Quarkus.

I've used threat models in other projects and they worked quite well.
The useful part was not that they covered every possible attack.
It was almost the opposite: they made the project's implicit security contract explicit.

• what the project assumes about callers, inputs, configuration, and its environment
• which security properties the project claims under those assumptions
• which properties are left to application developers or operators
• which actors, components, and execution modes are in or out of scope
• what a security report needs to show before it can be considered an actual vulnerability

Another reason for doing this is the amount of scanner and AI-generated security reports open-source projects now receive.
It is very cheap to point at a suspicious piece of code.
Showing that it is reachable by an attacker and actually violates a security property is the hard part.

The same requirements should apply to every report, no matter whether it came from a human, scanner, fuzzer, or AI.

Keeping it maintainable

Quarkus is a pretty big project.
Trying to cover every threat, extension, configuration property, and public API in one document would create something that is impossible to keep current.

I think it needs to be layered:

• a small common model for actors, trust boundaries, responsibilities, scope, and the evidence expected from reports
• a high-level grouping of components that have different security characteristics, for example build-time augmentation, runtime request processing, security extensions, native integration, or dev/test facilities
• more detailed documents only where a component really has a different attacker model or security contract

The top-level document should be readable in one sitting.
It should also not turn into an audit, a CVE history, a secure-coding guide, or another copy of the architecture documentation.

What should a report have to show?

I do not think a reporter should have to provide a weaponized exploit.
But there should be a credible path from an in-scope attacker, through an input or action they control, to reachable code in a supported configuration.
The report should also say which security property is violated and what the impact is.

Things like these should not be enough on their own:

• calling an internal method that cannot be reached through a supported entry point
• using a test, mock, fixture, or reflection to bypass the control being evaluated
• assuming control over application code, build configuration, dependencies, or an administrator account when the model already considers that actor trusted
• behavior that only exists in an explicitly non-production mode
• pointing at a dangerous-looking operation without showing how an attacker can reach it

That does not mean an incomplete report is automatically invalid.
It may simply need more evidence.
Source-level reasoning or a safe reproducer can also be sufficient when a full exploit would be harmful or unnecessary.

Also, "non-default" cannot automatically mean "out of scope."
Many Quarkus capabilities are enabled through extensions and configuration.
Documented, supported production configurations should remain in scope unless the project explicitly says otherwise.

Who is responsible for what?

The existing Quarkus security policy already says that Quarkus is an ecosystem of extensions and libraries, many of which are not under the direct responsibility of the Quarkus team.

A threat model could make this more concrete:

• properties and defaults implemented by Quarkus
• responsibilities of application developers and extension authors
• deployment and operator responsibilities
• shared responsibilities where behavior depends on both Quarkus and the deployment
• findings that should be coordinated with an upstream library or third-party extension

Deployment hardening should not excuse a broken Quarkus invariant.
But an operator mistake is also not automatically a Quarkus vulnerability, unless Quarkus provides an unsafe default, breaks a documented property, or makes a misleading security guarantee.

For triage, I think it would already help to distinguish between a valid vulnerability, a report that needs more evidence, a hardening suggestion, an upstream issue, and something that is explicitly outside the model.
There should also be a "model gap" outcome.
If a credible report does not fit anywhere, the answer should be to improve the model, not to make up an ad-hoc reason for rejecting it.

Conversely, something that does not qualify as a vulnerability can still be a legit hardening issue.
Once it is clear that there is no confidential security issue, it can usually be handled publicly.

Where should it live?

Technically, I think the model itself should be a versioned top-level SECURITY-MODEL.md or THREAT_MODEL.md.
It should be the canonical place for scope and triage rules.

SECURITY.md and the website security page should link to it and could contain a short checklist for reports.
AGENTS.md should also point agents to the same document before they report a possible security issue.

I would not copy the actual rules into AGENTS.md.
Having two versions of the policy would only make it easier for them to drift apart.

WDYT?

In particular, I would like to understand:

• whether this kind of security contract would actually help Quarkus maintainers
• which parts of Quarkus need separate treatment
• which actors should be considered trusted at build time and runtime
• how production, dev, test, and remote-dev modes should be separated
• who should own the model and review changes to it

If the general direction makes sense, I can start with a draft based on the public documentation and a list of open questions.
It can then be corrected in small iterations instead of trying to design the complete model up front.

The approach is based on these public threat-model rubrics:

• https://gist.github.com/scovetta/2dc9a0695c7cbcc32e23799e00d2ced3
• https://gist.github.com/potiuk/da14a826283038ddfe38cc9fe6310573

The second one is ASF-specific.
I would reuse the useful structure, not the ASF policy parts.

[sberyozkin]

Hi @snazy Thanks very much for starting this discussion. Would you like to create a simple draft PR with a few basic rules, scopes, to make it to easier to visualize, for us to to discuss various points, such as

whether this kind of security contract would actually help Quarkus maintainers

and other ones you listed.

Thanks

[snazy]

Draft PR is up #55744 - rendered model

[potiuk]

Just t add on it - the easily installable version of the skill I was using (and I can confirm it's really great to create your threat model) is now available as marketplace plugin: https://github.com/alpha-omega-security/threat-model