Application Security & SDLC

This page describes how HQ is built, tested, and shipped, and the controls that keep security defects out of production.

Secure development lifecycle

• Version control and code review. All code lives in Git and changes are made through reviewed pull requests.
• Policy-as-code. HQ’s own engineering operates under machine-enforced policies (for example, repository-write discipline and credential-isolation rules) that are checked automatically during development.
• Separation of environments. Development, staging, and production are separated; production access is restricted to authorized operators.

Continuous integration gates

Every change runs through a CI pipeline that includes:

• Type-checking (TypeScript) — catches whole classes of defects before runtime.
• Linting — enforces consistent, safer code.
• Automated tests — unit and integration.
• Blocking cross-tenant isolation end-to-end tests — the pipeline actively attempts cross-tenant access and asserts it is denied. These are treated as first-class, blocking checks: a change that weakens tenant isolation fails the build (see Tenant Isolation).

Tenant-isolation tests being a CI gate — rather than a manual review item — is the single most important application-security control for a multi-tenant product, because it converts the most dangerous failure mode into an automatic build failure.

Honest note

Branch-protection / required-status-check enforcement (so the blocking jobs cannot be merged past) is being finalized across all repositories as part of the SOC 2 change-management program.

Dependency and supply-chain management

• Pinned dependencies. All projects commit lockfiles and install from frozen lockfiles in CI, so builds are deterministic and a dependency cannot silently change under us.
• Dependabot. The hq-pro, hq-cli, and hq-desktop-app repositories have Dependabot configured for security updates and monthly minor and patch version updates (npm and GitHub Actions in all three; also Cargo in hq-desktop-app and Docker in hq-cli).
• Secret scanning. The same three repositories run gitleaks in CI on the commits each pull request adds and on each push to main.

Honest note

Dependabot and gitleaks are not yet configured on every HQ repository (for example, hq-console, hq-mcp, and hq-deploy). SBOM generation is not in place.

Secrets in the SDLC

• No plaintext secrets are committed to source control.
• Human-held secrets are sourced from HQ Secrets (HQ’s own encrypted secrets-management system) and provisioned to environments through AWS SSM Parameter Store / Secrets Manager (see Infrastructure & Network Security).
• CI credentials are scoped to what each pipeline needs.

Honest note

One container-deployment pipeline currently authenticates to AWS with long-lived access keys; migration to short-lived OIDC-federated credentials (already used by some pipelines) is in progress.

Build integrity and distribution

• Auto-updates for the desktop app are cryptographically signed (minisign, Ed25519); clients verify the update signature before applying it, preventing tampered updates.
• Release builds of the macOS app are signed with an Apple Developer ID certificate and notarized by Apple, with the notarization ticket stapled to the app and the DMG. Windows installers (MSI and NSIS) are Authenticode-signed through Azure Trusted Signing. macOS Gatekeeper and Windows SmartScreen can verify the publisher at install time.
• The Developer ID certificate is imported into a temporary keychain on the CI runner, which is removed at the end of the job.
• All CI secrets are masked in build logs.

Application-layer protections

• Input authorization on every route via the API Gateway JWT authorizer (issuer + audience validation) before any handler executes.
• Capability-based sharing instead of broad ACL changes, with single-use, time-limited, path-pinned tokens (see Data Security & Encryption).
• Fail-closed authorization — when a scoped permission set cannot be represented safely, the request is denied.
• Rate limiting on sensitive redemption endpoints (e.g., share-link redemption).

Testing philosophy

HQ’s engineering culture treats verification as a release gate:

• “Can’t verify, can’t ship”: features require tests; bug fixes ship with regression tests.
• End-to-end tests are the truth signal for deployable changes, not just unit tests.
• Failing tests are fixed at the root cause rather than skipped or weakened.

Penetration testing

HQ has not yet undergone an independent third-party penetration test. Engaging a reputable firm and publishing an attestation/summary is a roadmap commitment (see Compliance Roadmap). We perform internal security review and adversarial testing in the interim.

Roadmap summary (application security)

Item	Status
Type-check / lint / test / tenant-isolation CI gates	In place
Lockfile-pinned, frozen-install dependencies	In place
Signed auto-updates	In place
Developer ID signing + notarization (macOS), Authenticode via Azure Trusted Signing (Windows)	In place
Required-status-check enforcement everywhere	In progress
Dependabot + gitleaks on hq-pro, hq-cli, hq-desktop-app	In place
Dependabot + gitleaks on remaining repositories	Not yet configured
SBOM generation	Planned
CI credentials fully on short-lived OIDC	In progress
Independent third-party penetration test	Planned