What Knolo's Security Center Publishes Today, and What It Doesn't

Most security pages look finished on day one. They list a contact address, a policy and a badge or two, whether or not anyone has reviewed them. Knolo's security center takes the opposite approach. Each record says what has been published and what has not, and the empty ones stay empty until they are real.

This post walks through that public record as it stands today and explains why the gaps are shown on purpose.

Security as part of the release contract

The security center opens with a simple position: security is part of the specification, not a page at the end of the product. If Knowledge Images are meant to be verified by anyone holding the bytes, then the things around them need to be checkable too. That means who signed a release, which versions are still supported and how problems get reported and fixed.

The center indexes four records:

• Disclosure, which is marked as process prepared
• Advisories, with none published
• Supported versions, with the policy still forthcoming
• Release keys, not yet published

Each one has its own page, and each page uses the same rule: when a record has not been published, the site says so plainly.

Advisories: an empty list is a real answer

The advisories page currently shows zero published advisories. The site states that an empty list is better than a fabricated incident history.

When advisories do exist, each record is meant to include affected versions, severity, remediation, disclosure dates and verification references. That gives anyone running a Knolo artifact enough to decide whether they're affected and how to check the fix.

Supported versions: no guessing

The supported versions page makes the case that users shouldn't have to guess whether an artifact still gets security attention. The planned matrix covers project, version, release date, support status and end-of-support date, set per project and per release.

That matrix is not published yet. The page says it will be listed when the release policy is finalized and before production releases require it. This ties into the wider lifecycle and compatibility records, where versions are meant to move through stages in public.

Disclosure: use the right channel

The responsible disclosure page describes a policy that is structured for review before publication. The final version will define scope, report contents, safe-harbor language, coordinated disclosure, acknowledgement and communication expectations. Right now the channel is not yet published, the scope is still to be defined and safe-harbor language needs legal review.

Until that's published, the guidance is practical:

• Don't send sensitive security details through an unverified channel or a general contact form.
• Follow the security process documented in the relevant public repository.
• Include impact, affected versions, reproduction steps and any proposed mitigations.
• Discuss embargoes and timelines with the affected maintainers so there's room to fix things.

Security researchers who report responsibly should receive acknowledgement when it's safe to give.

Release keys and the verification center

Signed releases only help if people can find the right public keys. The security center says no release keys are published yet, and that public fingerprints will appear before signed release verification is enabled.

The verification center is where those keys will live alongside canonical repositories and package names. Today it lists the official domains so people can tell real Knolo surfaces from impersonators:

• www.knolo.org and knolo.org
• knolo.dev
• hub.knolo.dev
• learn.knolo.dev

The page also includes a certificate lookup that is a future surface. Entering an ID doesn't invent a result. Until a live registry is connected, no certificate result is shown.

Why show the gaps

It would be easy to fill these pages with plausible text. The problem is that a security record is only useful if it can be trusted, and one invented entry undermines all the real ones. By marking each record as published or not, knolo.org lets readers see exactly what they can rely on today.

That matches the rest of the project. The specifications and KIPs records are labeled the same way, and the open-source @knolo/core runtime fails closed when bytes don't match their digest. The security record follows the same rule.

If you build on Knolo, bookmark the security center and check back as disclosure, version support and release keys move from planned to published.