Informationsecurity policy.

Scope

This policy covers Kenii personnel, the Kenii software delivered to institutions, and the vendor-side services Kenii operates: the licensing service, the update service, and hosted evaluation sandboxes.

It does not cover institutional infrastructure. Kenii software installs into a content management system the institution owns and runs. Catalog, program, course and directory records live in the institution’s own database. Kenii does not copy those records to its own systems.

What Kenii is responsible for

1. The security of the code shipped to institutions.
2. The security of the licensing, update and sandbox services Kenii runs.
3. The conduct of Kenii personnel who hold credentials to an institution’s site.

Security requirements in the product

These are standing rules, enforced in review, not goals.

• Every administrative endpoint checks the caller’s capability before acting. Public read endpoints require an API key supplied in a request header.
• Input is sanitized at the boundary and output is escaped at the point of rendering.
• State-changing requests from the administrative interface carry a nonce.
• Access inside the product is role-based. An account granted directory editing sees only the directory.
• Network traffic uses TLS. The product makes no unencrypted outbound request.
• License grants are signed with Ed25519 and verified before an entitlement is honored.

Change control

• All source lives in version control. Work happens on a branch and is reviewed before it merges.
• Automated suites run before release: one covering create, read, update and delete across every content type through the REST layer, and one that loads every administrative screen and fails on an error.
• Dependencies are declared and pinned through Composer and npm. Support status is reviewed when a release is prepared.
• Every release carries a version and a changelog entry naming functional and security-relevant changes.
• Institutions decide when to apply an update. Kenii cannot push a change into an institution’s environment.

Patching

Security defects take priority over feature work. A fix is released as soon as it is validated rather than held for a scheduled release. Where a fix requires institutional action, Kenii states what to do in the release notes and contacts affected institutions directly for anything exploitable.

Secrets

Credentials are held outside version control in a single file readable only by the account that owns it. The repository ignores everything by default and allows specific paths, so a credential file cannot be staged by accident. Credentials are never placed in code, documentation, issues or chat.

Limits, stated plainly

Kenii is a small company. There is no separate security office, and no claim is made that one exists. Security ownership sits with the Co-Founder named above, and the controls in this document are the ones actually operated.

Where an institution requires a control Kenii does not have, Kenii will say so rather than assert otherwise.