Security
What we do with your code, and what we will not claim about it
A security product that is vague about its own security is not worth trusting with a repository. Every control below says whether it exists in the code today or is still planned, because a page that lists both without distinguishing them is a page claiming security it has not built.
Reporting a vulnerability
Write to security@audixa.com. We will not take legal action over good-faith research, and we will tell you what we did about it.
There is no bounty programme yet. Saying so is better than implying one and disappointing somebody who spent an afternoon on us.
Built today
10 controls that exist in the code now
Your data is separated by organization, and that separation is tested
Every query against business data carries the organization it belongs to, enforced by the database layer rather than by each developer remembering. A generated test drives every API route with another organization's identifiers and requires a 'not found' answer.
Permissions are checked on the server, on every request
Roles are evaluated from one shared capability matrix. Hiding a button is not a control, so every page and endpoint re-checks rather than trusting what the browser was shown.
Changes to access take effect immediately
Roles and account status are read from the database on each request instead of being cached in your session, so removing somebody's access removes it now, not when their session expires.
Sensitive changes are recorded in an append-only audit log
Who invited whom, who changed a role, who altered settings. The application has no permission to update or delete those rows; the database rejects the attempt.
Secrets are kept out of logs
Credential-shaped values are redacted before anything reaches a log sink, and the same scrubbing runs independently over audit metadata.
We do not run your code
Dependency analysis reads your lockfile; it never installs or resolves anything. There is no build step, no test run and no package script executed anywhere in a scan.
Repository analysis happens in a throwaway sandbox with no network
Each scan gets its own container with networking disabled, a read-only image, memory and CPU limits and a wall-clock kill. The workspace is destroyed when the job ends.
Active checks only run against a domain you have proved you control
Verification is a DNS TXT record or a file at /.well-known. Until one of those succeeds, we do not send a request to your domain.
Our scanner cannot be pointed at a private network
Every outbound request resolves the hostname first, refuses any address that is not public, and connects to the address it validated — so a DNS answer cannot change between the check and the connection. Redirects are re-validated at every hop.
Repository access is read-only and short-lived
We ask for permission to read contents and metadata, nothing more, and each scan uses a token that expires. We never write to your repository and never open a pull request.
Not built yet
0 controls the scanning milestones will add
Limits
What a scan is not
- A clean scan means the checks we ran found nothing — not that your application is secure. We tell you which checks ran and which did not.
- We do not attempt to exploit anything. No brute forcing, no port scanning, no destructive payloads.
- We do not review business logic that only a human who knows your product could evaluate.
- We are not a compliance certification. We do not issue ISO, SOC 2 or PCI attestations, and a scan is not an audit.
- Automated analysis finds patterns. It misses things, and it sometimes flags something that turns out to be fine — which is why every finding carries a confidence level and its evidence.
We will never tell you your application is secure, and we will not write a letter saying it. The best an automated review can honestly say is which checks ran and what they found — which is genuinely useful, and is what every scan report says.
Data handling
What we store, and for how long
The short version
Your source code is not retained. A scan works in a container that is destroyed when the job ends, and what survives is the findings plus up to three lines of context around each match, with anything that looks like a secret redacted before it is stored.
Enquiries sent through this site are kept for 24 months from the last contact, and we will delete one sooner if you ask.
Read the whole thing before connecting anything
If a control you need is in the planned list rather than the built one, that is worth knowing now. Tell us which one and we will say honestly when it lands.