Security | Native Code

Section 1What we are, and what we are not

Native Code is a small studio. We are not SOC 2 certified, we are not ISO 27001 certified, we are not HIPAA compliant, and we are not a PCI cardholder data environment. We do not claim any of those, and you should be wary of a company our size that does.

What follows is what is actually in place. If your business needs a certification we do not hold, tell us early through the contact form and we will be straight with you about whether we are the right fit.

Section 2How data is protected

In transit. Everything travels over TLS. There is no unencrypted route into any of our systems, and plain HTTP is redirected rather than served.
At rest. Databases, file storage and backups are encrypted at rest by the provider holding them.
Passwords. Stored as salted hashes using an algorithm designed for the job. Nobody at Native Code can read your password, including us.
Card details. Never touch our systems. Payment goes straight to Stripe or to the app store, and we receive only the last four digits and the result.
Isolation between customers. Enforced at the database with row level security, so one account cannot read another’s rows even if application code has a bug. The rule lives below the code rather than inside it.

Section 3Who can reach what

Access to production is limited to the smallest number of people who need it, which today is a very small number.
Every account that can reach production has multi factor authentication switched on.
We look at customer data to fix a fault that has been reported, or where the customer instructs us. Not otherwise, and never out of curiosity.
Credentials and API keys live in the hosting provider’s secret store. They are not in source code, not in the repository, and not in a chat message.
Access is removed the day somebody stops needing it, not at the end of the quarter.

Section 4How we build

Dependencies are kept current, and security advisories against them are acted on rather than queued.
Input from a browser is treated as hostile: validated on the server, never trusted because the form validated it first.
Destructive and irreversible operations are gated and logged.
Automated checks run on every build, and a failing check blocks the deploy rather than warning about it.
We write down the security decisions that matter, so the reason a rule exists outlives the person who made it.

Section 5Infrastructure and backups

We run on managed infrastructure from established providers rather than servers we maintain ourselves, because their security teams are larger than our entire company. The full list is on the Subprocessors page.

Databases are backed up automatically on the provider’s schedule, and backups are encrypted.
Backups roll over within 35 days, which is also why deleted data can take that long to disappear entirely.
Restoring from a backup is something we have actually done, not something we assume would work.

Section 6What happens if something goes wrong

No system is perfectly secure. If we have an incident, this is what we do.

Contain it. Stop the bleeding first: revoke credentials, close the hole, take a service offline if that is what it takes.
Work out the scope. What was reached, whose data was in it, and over what period.
Tell the people affected. Without unreasonable delay, and within 72 hours of becoming aware where European law applies. We will tell you what happened, what data was involved, what we have done, and what you should do.
Tell the regulators and our business customers within the deadlines the law and our contracts set.
Write up what failed and fix the cause, not just the symptom.

We will not sit on a breach while we work out how to phrase it. An early message that says "this happened, we are still investigating" is more useful to you than a polished one that arrives a week late.

Section 7Reporting a vulnerability

If you have found a security problem in one of our products, we want to hear about it, and we would rather hear it from you than read about it later.

Please include what you found, the steps to reproduce it, and what an attacker could do with it. Give us a reasonable chance to fix it before you make it public.

We do not run a paid bug bounty. We are a small company and we would rather be honest about that than imply a reward we cannot pay. What we will do is answer you, fix what you found, tell you when it is fixed, and credit you publicly if you would like that.

Section 8If you research in good faith

We will not pursue legal action against you for security research carried out in good faith, as long as you:

only test against your own account and your own data;
do not access, modify or delete anybody else’s data;
do not degrade the service for other people, which rules out denial of service testing and automated scanning at volume;
report what you find to us promptly and give us a reasonable window before disclosing it;
do not extort us. A report is welcome; a demand for payment against a deadline is not a report.

If you are unsure whether something you want to try falls inside these rules, ask first through the form above. We answer within one business day.