Tessera Viz
PX-02
Security and compliance
A smaller attack surface, on purpose.
Most of what a security reviewer has to read about a visualization library is not the library. It is the few hundred packages underneath it, each with its own maintainers, its own release cadence and its own capacity to change while nobody is looking. The decision to ship none of them is the security posture; everything below follows from it.
What we ship.
No third-party runtime dependencies
None in the Community packages, and a check on every build fails if an import appears — transitive ones included. Supply-chain risk is the risk of our code and nobody else's.
An SBOM with every release
So a supply-chain review has something to read rather than something to reconstruct.
Secret scanning in CI
On every change, because the cheapest credential leak to fix is the one that never reaches a branch.
Licences verified locally
Signed with Ed25519 and checked on the machine. There is no phone-home, so an air-gapped deployment is not a special case that quietly stops working.
No telemetry
None in the Community or Enterprise runtime. We do not know how many nodes you drew, and we have arranged not to be able to find out.
Air-gapped deployment
Documented and supported, including offline map tile packs. It is one of the main reasons the library has no dependencies.
Where we stand on certification.
ISO 27001
We have completed an internal gap assessment against the controls and we publish where we stand. We are not currently certified and we will not claim to be. Certification is a business decision we will make with our first enterprise customers.
What you can have today
For a security review, ask us: we will provide the gap assessment, the SBOM and the architecture documentation. Enterprise source is available under NDA for review, and in escrow on request.
Why say it this way
A security reviewer who catches an implied certification stops the deal. One who is told the truth early often becomes the advocate for it inside their own organisation.
Reporting a vulnerability.
Where to send it
contact@par2labs.com, with "security" in the subject line. Tell us what you found, how to reproduce it and how you would like to be credited.
What happens next
It goes to the engineers who wrote the code, not to a queue. We will confirm we have it, tell you whether we can reproduce it, and keep you informed until it is fixed and released.
What we ask
Give us a reasonable window to ship a fix before publishing, and do not test against anyone else's deployment. We will not threaten a researcher who follows that.