Skip to content

Security

Only what we actually do.

This page describes the security practices we operate day to day, written as documentation rather than marketing. If a practice is not listed here, we do not claim it.

01

Secure development

Code is reviewed before it is merged. New dependencies are reviewed before they are added. We run static analysis on our own code using scanning tooling we built internally.

Secrets are kept out of repositories and injected through environment configuration.

02

Access control

Access to infrastructure and customer material is least-privilege: people get access to what their work requires and nothing more. Accounts are protected with hardware security keys or multi-factor authentication.

Customer data is separated per project. Work for one customer does not sit in another customer’s environment.

03

Encryption

All traffic to alialabs.org is served over TLS. Devices and backups that hold project material are encrypted at rest.

04

Customer data handling

Project material is used only for the engagement it belongs to. Access is limited to the people working on that engagement.

At the end of an engagement, project material is returned or destroyed on request. We sign NDAs before sensitive documents are exchanged. Ask for one before sending anything you would not want us to see without it.

05

Environment separation

Development, testing and production are kept separate. We touch customer production systems only when the engagement requires it, and we prefer to work under the customer’s own access controls rather than standing credentials of our own.

06

Dependency management

Dependencies are pinned. New dependencies are reviewed before they enter a project. During an active engagement, and during any contracted support period after it, we monitor published vulnerability advisories for what we ship and update when they affect us. Monitoring beyond that period is a support arrangement rather than something every project carries indefinitely.

07

Backups

Project work is kept in versioned, encrypted backups, so a lost device or a bad change does not lose customer work.

08

Responsible disclosure

If you believe you have found a vulnerability in anything ALIA Labs operates, email [email protected]. We will acknowledge within a reasonable time, investigate, and credit the report if you want credit.

Do not test against systems we operate for customers.

09

Encrypted contact

Reports and sensitive documents can be encrypted to our OpenPGP key. Mail clients that support Web Key Directory find it automatically from the address above. You can also download the public key directly.

Fingerprint

FC50 D457 2569 1141 C4E2  7099 189B 9E34 60CA 94F0

ed25519 · created 17 August 2026 · expires 16 August 2028

Check the fingerprint above against the key you import. If they do not match, do not use the key, and tell us.

We do not currently hold third-party security certifications. If your procurement process requires specific controls, ask us. We will tell you plainly what we do and do not have.