Security architecture
This page describes the production environment as it is built. It is written for the person at a radiology group or hospital who has to sign off on a new tool.
The boundary
The application runs on a single-tenant environment inside GigHz LLC's AWS account, in a United States region, using only HIPAA-eligible services. The web application, its database, the email service and the deployment pipeline all live inside that account. There is no shared hosting and no third-party platform between the browser and the application.
Transport
The application domain resolves directly to the AWS environment and TLS terminates there. It is deliberately not proxied through a content delivery or DDoS-mitigation network: proxying would mean a third party decrypts clinical traffic in transit. The company's marketing site is a separate system on a separate domain and is proxied in the ordinary way; nothing clinical passes through it.
No third-party code on the clinical page
Every script the application page loads is served from the application itself. The JavaScript libraries it depends on are vendored and pinned to exact versions; nothing is loaded from a public CDN. There is no advertising, no third-party analytics and no tag manager. The automated test suite fails the build if a public CDN host or a floating dependency version appears in the plugin.
Accounts and roles
- Each radiologist has an individual account created through email verification and acceptance of the Terms. There are no shared or demo logins on the production site.
- Clinical users cannot reach the administrative console; administrative URLs are locked to administrators, and the administrative toolbar is not shown to clinical users.
- Administrative functions (settings, rollout of features, review queues) are separated from the clinical application, and anything intended for administrators is not rendered to clinical users.
- Author and user listings are disabled, so account names cannot be enumerated from the site.
- Login hardening: generic failure messages, no username disclosure, rate limiting at the web server.
Secrets
API credentials are stored server-side and never shipped to the browser; the browser calls the application, which calls the model services. Keys are entered by the owner directly into the administrative console and are never transmitted through chat, email or support channels. Email is sent by signing requests with the server's own IAM role, so there is no email password anywhere in the system.
Account email (verification, password links, onboarding, billing notices) is sent through Amazon SES from the application's own domain with DKIM signing, SPF and DMARC. Bounces and complaints are delivered to the operations mailbox. No email ever contains report content. Every message is logged (recipient, subject, status, time) for delivery auditing.
Backups and recovery
The environment is backed up on a schedule within the same AWS account; backups inherit the account's encryption and access controls. Recovery is from backup to the same environment.
Change control and testing
Every release passes a deterministic test suite before it can be packaged (currently several hundred invariants covering routing, placement, impression rules, clinical scoring, the PHI boundary of the feedback payload, the CDN gate and the deployment health of the live site), plus mutation testing that plants defects to prove the checks can fail. A nightly run re-tests the deployed site and files any regression. See Quality assurance.
Reporting a security concern
Email signal@gighz.com with "security" in the subject. We acknowledge within two business days.
This page is generated from documentation that ships with the application (docs v1.2.2). Version numbers, prices and trial lengths on this page are read from the running system, not typed by hand.