Security and compliance¶
PEART holds, in one place, the consolidated list of a consultancy's clients' still-unfixed vulnerabilities, with exploitation steps and evidence that routinely contains credentials, tokens and personal data. Part of it is exposed to the internet by design, because the client reaches the portal. That makes PEART one of the most valuable targets a security consultancy can host, and it sets the bar for how the product itself is built.
This section is written for the people who evaluate that: auditors, DPOs, and security-conscious
operators. It distils the project's normative security documentation (docs/security.md and the
architecture decision records) into a reader-facing account. Where a claim matters, it points at the
authoritative source rather than restating it, so the two never drift.
The principle this section keeps¶
Two disciplines govern everything here.
Declared limitation over vague promise. PEART states plainly what it does not protect, because a security product that overstates its guarantees loses the ones it does have. The clearest example is the database: it is stored in cleartext by a deliberate, documented decision, with full-disk encryption on the host as the compensating control. That is written down, not hidden, and this section reflects it exactly.
Relate, do not certify. The compliance mapping says a finding relates to control X of framework Y. It never says a finding proves non-compliance. The auditor draws the conclusion; the tool gives the correlational map the auditor would otherwise build by hand.
Threat model, in brief¶
The full threat model is in docs/security.md. Two points frame the rest of this section.
The most valuable assets, in order, are the evidence (screenshots and captures that carry credentials, tokens and PII), the exploitation steps against systems still in production, and the catalog of open findings (knowing which of whose systems are vulnerable, and since when, is itself actionable). Encryption keys and account credentials sit below those, and availability below them again: an outage is a nuisance, a leak is the end of the consultancy.
The primary trust boundary is not between authenticated and anonymous. It is between the portal
surface and the internal surface. Compromising peart-portal must not yield the encryption key, the
original evidence, internal-only fields, or a write to report content. The portal runs as a separate
process, never holds the master key, and cannot read the evidence directory; it serves every read
the client sees through a connection the SQLite driver refuses writes on, and reaches the few rows
it writes about itself, its session, its audit entries and its own credential, through a second
connection narrowed by interface. The boundary the product deliberately does not defend is the
host operator, who is trusted by design, with an audit trail as the only control; this too is stated
openly.