Techly Secure Development Policy

Purpose

Security is cheapest when it is built in. This policy sets the rules Techly Operations Pty Ltd (Techly) builds Pyron to, so that each new feature inherits the same protections instead of reinventing them.

Scope

All code and configuration in Pyron: the application, its programs and workers, its infrastructure code and its CI. Engineers, and the AI coding assistants they direct, work under the same rules and pass the same checks.

Built in once, used everywhere

Each of these is a single path that every feature goes through, and automated tests fail a change that goes around it:

• Writes. Every change a person, an automation or the AI makes goes through one command path, which asks the permission engine before anything is written. A command that destroys or hides data requires an explicit confirmation, and a change to someone's access is recorded on the audit trail.
• Reads. Reads go through queries scoped to what the person asking may see, and any exception is recorded with its reason.
• Workspaces apart. Each workspace's data lives in a database schema of its own, and every sign-in token names the workspace it was issued for. Tests that try to reach one workspace's data from another run on every change.
• Untrusted code. Pages and automations run as programs in isolated sandboxes with no network access of their own; they reach records only by asking Pyron, which checks permissions as for any other request.
• Outbound requests. When Pyron fetches an address for an automation or the assistant, it refuses private and internal addresses.
• Input. Data is validated against its declared schema, and invalid data is refused rather than silently corrected.
• Uploads. Every uploaded file is scanned for malware before anyone can open it.

Writing code

• Typed. The frontend is strictly typed TypeScript, and the backend's Python is type-checked. Existing type errors are held at their current number, which may only shrink.
• Fail clearly. Code fails with a clear error rather than guessing a default or swallowing an exception.
• Tested. Every change carries tests that prove it. Acceptance tests drive the real application in a browser.
• Documented. A change that makes the documentation untrue corrects it in the same change.

Secrets

• Secrets are never written into source code. They are held in AWS's encrypted parameter and secret stores and given to each service at run time.
• Secret detection runs on every change, and GitHub's push protection refuses a commit that carries a known kind of secret.
• CI reaches AWS only with short-lived credentials that GitHub issues for each run. No workflow reads a stored cloud key.

Dependencies

• Every dependency is pinned in a lockfile, and installs use exactly what the lockfile says.
• Container base images are pinned to an exact digest.
• Dependencies are scanned and updated as the Techly Vulnerability and Patch Management Policy says.

Environments

• Production is kept apart from Techly's other environments. A network policy stops staging and production reaching each other.
• Development and test environments use made-up data, except as the Data Classification Policy allows.
• Customer data is handled as the Techly Data Classification Policy says.

Review and release

Every change reaches production through a pull request and its required checks, and is released as the Techly Change Management Policy says.

Who is responsible

• The Technical Director owns this policy and the checks that enforce it.
• Everyone who changes Pyron, and every AI assistant working for them, follows it.

Review

The Technical Director reviews this policy every year.