[Linux-aus] Grant Application from Miguel Jacq for KEEN

[Miguel Jacq]

Hi Jonathan,

On Mon, 19 Oct 2026, at 21:10, Jonathan Woithe wrote:
> Hi Miguel
> 
> Thank you for applying for a Linux Australia grant.
> 
> With its posting to the Linux Australia mailing list[1], the two week
> community consultation period has opened.  During this time Linux Australia
> members can provide feedback and seek additional information about your
> application.  If you haven't done so already, you are encouraged to join the
> linux-aus mailing list[2] to make it easier for you to provide answers to
> any questions which might be asked.

Ah, terrific! I've now joined the list :) Really cool to see how the members get involved (I've been reading over recent months' grants).

I'm thankful for the reply and the open discussion because upon submitting the proposal, I realised it was a bit 'open ended' in the way grants sadly often are (thank you to my wife, a former local gov grants officer, who I ought to have had read over it before I sent it :) ).

So I'll seize the moment to frame my goal a bit more specifically into two outcomes that any grant funds would be dedicated to:
*
*## Outcome 1: An independent security assessment and remediation

A source-assisted penetration test of KEEN’s web application and API, using a dedicated instance with synthetic data, via an independent pentesting organisation.

The pentesting scope will cover:
 • Authentication, session management and authorisation (including testing the MFA and OIDC flows).
 • Permissions across user roles and sensitive operations (in particular chasing any privilege escalation paths).
 • Agent enrollment, ingestion endpoints and webhook authentication.
 • Connector credentials, secret handling and outbound requests.
 • Evidence access, data exports and sensitive-information exposure.
KEEN is a somewhat unique tool in that its attack surface is spread across two sides: frontend (web interface) as well as its 'ingestion' system from upstream sources, which (although curated by the admin) are, if malicious, potential risks of resource exhaustion, data tampering, MITM etc. So it's a project well worth an audit itself.

I will triage each finding and record its treatment. Confirmed vulnerabilities will receive fixes and appropriate regression tests.

The target of outcome 1 is to remediate and independently retest all critical and high-severity findings within the agreed assessment scope before releasing 1.0.0. Remaining findings will have a documented treatment decision.

Outcome evidence would include: the original report,* *a findings register, traceable fixes, regression-test results and an independent retest report. A public security summary will describe the assessment’s scope and limitations once disclosure is appropriate.

## Outcome 2: A stable KEEN 1.0.0 release

Getting KEEN to 1.0.0 and ready for adoption:
 • Resolving agreed release-blocking defects.
 • Validating installation, upgrade and backup restoration against the release candidate.
 • Updating deployment and security documentation to match the released version.
 • Publishing supported-environment information, known limitations, release notes and vulnerability-reporting instructions.
 • Producing a release candidate followed by the 1.0.0 release when the agreed acceptance criteria are met.
Outcome evidence: versioned documentation and published release artifacts (container images).

Reaching the 1.0.0 milestone is also an important goal for agencies I'm discussing hosting partnerships with, who specialise in both ISO27001 and hosting of FOSS-based applications, such as https://codeenigma.com - imminent adopters of KEEN themselves.

I estimate about $10,000 for the pentesting (allowing for retest and some labour for remediation work), but I would not expect Linux AU to cover it all. Whatever amount seems viable to the members, for a FOSS compliance tool that helps people escape the expensive Vanta/Drata walled garden, is appreciated.

Hope that provides some advanced clarification for the members as to where the funds would be directed.

Warmly,
Miguel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.org.au/pipermail/linux-aus/attachments/20261019/e5308fac/attachment.htm>