Security Practices

It covers the security of this corporate site and the way Edelon builds and operates its own systems.

It does not cover the security of a deployment within an institution’s infrastructure. There, controls, configuration and incident response are governed by the contract entered into with that institution, and much of the surface belongs to the institution, not to us. Nor does it replace the Vulnerability Disclosure Policy, which is the channel for reporting a finding.

Three principles govern technical decisions, and they are stated here because they explain why the controls are what they are:

• Closed by default. In the absence of an explicit authorization, or upon a failure of the control itself, the system denies. A control that opens when it fails is not a control.
• Least privilege. Access is granted on demonstrated need and with the narrowest scope that allows the work to be done.
• Evidence. A security claim is only as good as the proof that supports it. That is why this document distinguishes what is implemented from what is designed and from what has not been demonstrated.

The following is active in production, and you can verify it yourself with your browser’s developer tools. There is no need to take our word for it:

• Mandatory encrypted transport. The site is served only over HTTPS and declares HSTS with a two-year duration, so that the browser refuses to fall back to cleartext.
• Restrictive content policy. The site’s own origin is the only permitted source for scripts, styles, images, fonts, media and connections. Plug-ins are blocked, embedding the site in third-party frames is prohibited, and both the destination of forms and the base URL are pinned to the site’s own domain.
• Hardening headers. A file is prevented from being interpreted as a type other than the one declared, embedding in frames is denied, the referrer is trimmed when crossing origins, and device capabilities are restricted: geolocation is disabled entirely.

One limitation remains that we prefer to declare rather than omit: the content policy still allows inline styles and scripts, which reduces its effectiveness against content injection. Correcting this requires migrating to a per-request signature scheme. It is pending work, not a resolved item.

This site contacts no third party. There are no advertising networks, no analytics tags, no remote fonts and no tracking pixels. Fonts are served from the site’s own domain precisely so as not to reveal who visits us.

Nor is any tracking cookie set or any identifier stored in your browser. What the site does store, and why, is declared in the Cookie Policy.

This is not aesthetic minimalism. A company that publicly maintains that operating an institution’s infrastructure does not make it the owner of that institution’s information cannot, at the same time, hand its visitors’ browsing over to an advertising network. Consistency is demonstrated on the site itself or it is not demonstrated at all.

No change reaches the main branch without passing automated checks: type checking, static analysis with security rules, tests and a full build. In addition, changes are reviewed before they are merged.

Dependencies are pinned by version and recorded, so that the set of third-party code that goes into a deployment is reproducible and auditable.

It is worth being precise about what this means and what it does not: these are engineering controls that reduce defects, not a security program certified by a third party.

Edelon’s systems are built on three structural decisions, applicable to institutional deployments:

• Authorization by declared policy. Permission is resolved against explicit, readable rules, not against conditionals scattered throughout the code. A rule that cannot be read cannot be audited.
• Isolation between institutions. One institution’s data cannot be reached from the context of another, and isolation is enforced at the data layer, not only at the application layer.
• Evidence trail. Significant operations leave a record of who, what, when and under what authorization, so that a decision can be reconstructed afterward.

These are design properties verified in development. The execution evidence that would allow us to claim a level of assurance to a third party is in progress and is not yet published. Until it exists, this document does not take it for granted.

If you find a weakness in this site or in an Edelon system, we want to know. The scope, the response commitment and the safe harbor for good-faith research are set out in the Vulnerability Disclosure Policy.

That safe harbor prevails over the security clause of the Terms of Use: good-faith research within the published scope is authorized and does not constitute a breach.

This section exists because its absence would be the most telling part of the document. Edelon is in its build phase and does not assert what it cannot prove:

• We do not hold ISO/IEC 27001 certification, a SOC 2 report or an equivalent accreditation.
• No independent security audit or penetration test has been carried out with results that we can publish.
• We do not yet operate continuous security monitoring, nor do we publish committed availability targets or recovery times.
• There is no rewards program: the disclosure channel carries no financial compensation.

When any of these points changes, it will change here, with its date. Anticipating it would be exactly the kind of claim that this document exists to avoid.