The public repository is currently a proposal, standards, documentation, and publishing foundation. It does not yet provide the complete reference platform described in the vision and must not be used as though it were a reviewed production system for founder, applicant, mentor, financial, or compliance data.

Security reports are welcome for:

• the repository and its automation;
• the published project site;
• dependencies and build or release configuration;
• accidental disclosure of secrets or personal data;
• future reference-implementation code as it is added; and
• specification flaws that could lead conforming implementations to expose, confuse, or retain data improperly.

Please do not open a public issue.

Use one of these private channels:

1. GitHub private vulnerability reporting, if it is enabled; or
2. email jeremy.fritzhand@ahduni.edu.in with the subject Open Innovation Stack security report.

Include, where possible:

• the affected file, URL, commit, or version;
• a description of the issue and its likely impact;
• safe reproduction steps or a proof of concept;
• whether personal data or credentials may be exposed;
• any temporary mitigation; and
• how you would like to be credited.

Do not include real participant data in a proof of concept. Use invented records and redact secrets.

This is a community-stage project without a guaranteed response SLA. The maintainers aim to:

• acknowledge a report within seven calendar days;
• confirm scope and coordinate a safe disclosure plan;
• prioritise containment of exposed credentials or personal data;
• provide progress updates for material issues; and
• publish a fix and advisory when public disclosure is safe.

Complex issues may take longer. Reporters will be told when that is the case.

Until formal releases exist, only the latest default branch and the currently published project site are supported. Draft documents and historical commits may contain known gaps.

If personal data, a secret, or a confidential document enters repository history:

1. report it privately immediately;
2. rotate or revoke exposed credentials;
3. preserve only the minimum evidence needed for response;
4. remove the material from the working tree and history using a coordinated process; and
5. assess notification and legal obligations before public disclosure.

A follow-up deletion commit alone does not remove sensitive data from Git history.

The following are design requirements, not claims about current implementation:

• explicit tenant and role boundaries;
• least-privilege access and server-authoritative sensitive changes;
• audited authentication, authorisation, and data-export paths;
• encryption in transit and appropriate protection at rest;
• append-only audit events for sensitive transitions;
• purpose, consent, retention, deletion, and portability controls;
• secret scanning and dependency review;
• abuse protection on public-write surfaces;
• negative tests for cross-tenant and cross-role access;
• threat modelling before handling real participant data; and
• independent review before production claims.

Privacy-preserving analytics require specific, testable guarantees. “Federated” or “anonymised” is not itself a security property.

The maintainers support good-faith research that avoids privacy violations, data destruction, service disruption, social engineering, and access beyond what is necessary to demonstrate an issue. Coordinate before testing against systems or data you do not own. This statement is an expression of project intent and not a substitute for permission from a system owner.

There is no bug-bounty program at this time.