Email the details privately. Include the affected component or URL, the steps to reproduce, and what you observed.
hello@tdacorp.inSecurity
Security is the starting position.
Most of the risk in a product sits around the code rather than inside it: who holds access, where credentials live, what the deploy path allows, where data crosses a boundary, and what an agent or integration is permitted to touch. That is where security is engineered in, from the first commit rather than before launch. This page states how the work is secured, and how to report an issue.
Practices
How the work is secured
Each row is a working practice, published as the policy the work runs on, so it can be checked against an engagement rather than taken on trust.
- Access
Least privilege, requested per system
Every person, process, token, and integration gets the narrowest scope that still does the job. Access is requested per system rather than granted broadly at kickoff, and time-bounded where the platform supports it.
- Secrets
Credentials stay in your store
Credentials live in your secret manager and are injected at runtime. They are never committed to source, pasted into a chat thread, or sent over email.
- Deployment
The path to production is reversible
Releases run through a defined path with checks at each gate, and a rollback that has been exercised rather than assumed. Environments rebuild from source, so recovery is a procedure, not an improvisation.
- Boundaries
Agents and integrations get explicit permissions
What an agent, job, or third-party integration may read, write, and call is decided and written down, not inherited from whatever credential was already available. Data that crosses a boundary crosses it deliberately.
- Design
Security starts at design
Threat modelling happens while the system is being designed, not as a hardening pass bolted on before launch. The safe shape is the first shape.
- Input
Hostile input is the default assumption
Everything crossing a trust boundary is treated as adversarial: validated against an explicit schema, bounded, and rejected when it does not fit.
- Failure mode
Fail closed
When a check cannot complete or a dependency is unreachable, access is denied, not waved through. Off is the safe default.
- Provenance
Decisions are written down
Security choices are recorded with their reasoning, so a control can be traced back to why it exists and reviewed instead of guessed at.
- Handover
Access is returned at the end
Infrastructure runs in your accounts and source lives in your repositories throughout, so revoking access is something you can do without asking. What was issued is handed back when the engagement closes, against the list it was issued from.
Disclosure
Reporting a vulnerability
Found a security issue in something TDACorp builds or runs? Report it privately first. Here is where to send it, what helps, and what you can expect back.
What we ask
- Report privately before disclosing anywhere public, and allow reasonable time to investigate and ship a fix.
- Send enough to reproduce it: the affected component or URL, the steps, and what you saw.
- Stay in good faith: do not access, change, or delete data that is not yours.
- Do not run tests that degrade the service for others, such as denial-of-service or spam.
What you can expect
- An acknowledgement that the report reached a human.
- A straight answer on whether it is something being fixed, and a rough sense of timing.
- A heads-up when a fix ships, and credit for the finding if you want it.
- No legal trouble for good-faith research that follows this policy.
Acknowledgement is an aim, not a service-level agreement: there is no security team on call, so no fixed response time is promised. There is no paid bounty. No SOC 2 or ISO 27001 certification is claimed and none is held: what is published on this page is the practice itself, which is the thing a certificate is a proxy for. Good-faith research that respects this policy is welcomed, not penalised.
Keep reading
Where the stance is written down.
This page states how the work is secured. These are the pages where the same stance appears as a contract term, as a document you receive, and as the engineering itself.
- PageTrust and dataThe other half of the question: the sub-processors behind this site, what each one holds, how long a submission is kept, and the entity details a vendor record asks for.
- ProcessThe commercial railsThe access and credential rules above, restated as contract terms: NDA, IP ownership, least privilege requested per system, and access handed back at the end.
- DocumentsSample artifactsThe access and security checklist is one of the eight formats, shown with what it records and the risk it removes.
- ServiceSecurity and systems depthWhere this stops being policy and becomes the engagement: access boundaries, hardening, and the debugging that starts where application logs run out.
Security is part of the build, not a line item.
It is designed in from the first commit, on every engagement. Book a call to talk through what that means for your system.