Skip to main content
The most subtle attack on a desktop application is the one that gets a malicious build into your installer or your update channel. This page describes the controls that protect that path.

​
The build pipeline

Studio’s frontend, backend, and Go agent are built in the same controlled CI environment as the AWS infrastructure. The pipeline runs through AWS Amplify Hosting:
PhaseWhat happens
Backend pre-buildA required-secrets check runs first; if any expected SSM parameter is missing, the build fails before any code runs.
Backend buildAmplify CDK synthesises the AppSync schema, the DynamoDB tables, the Lambda functions, the IAM and KMS resources.
Backend post-buildSmoke tests run against the deployed stack — including the FIPS endpoint assertion (kms-fips.us-east-1.amazonaws.com) and the principal-tag mapping.
Frontend pre-buildDependencies install; lockfile is enforced.
Frontend buildNext.js produces the static export shipped inside Electron.
Agent buildGo sidecar compiles with GOEXPERIMENT=boringcrypto and the version-stamped build flags.
Desktop packageelectron-builder produces signed installers for macOS (universal and Intel) and Windows (x64).
Release publishArtifacts upload to a controlled CDN under download.altostrat.io.
Per-branch secrets live in AWS SSM Parameter Store, scoped to the branch and the AWS account. Secrets are never committed; the CI environment fails the build rather than substituting placeholders.

​
Code signing

PlatformSignature
macOSSigned with an Apple Developer ID Application certificate. Notarized through Apple’s notary service so Gatekeeper allows the install without a right-click bypass.
WindowsSigned with an Authenticode certificate. The installer reports a verified publisher in the standard SmartScreen / UAC dialogs.
Both signatures are verified by the operating system at install time and on every launch. An installer whose signature does not validate is rejected by the OS before it can run.

​
Update flow

The desktop app uses electron-updater for self-update. The flow:
1

App checks for updates

On launch and on a periodic schedule, Studio checks the release feed at download.altostrat.io for the current channel.
2

Compare with installed version

If a newer version exists, Studio downloads its metadata file (latest-mac.yml or latest.yml) which contains the version, release date, and SHA-512 hashes for each artifact.
3

Download the artifact

Studio downloads the platform-specific installer.
4

Verify SHA-512

electron-updater computes the SHA-512 of the downloaded artifact and compares it against the hash in the metadata file. A mismatch aborts the update.
5

Verify signature

The OS verifies the installer’s signature. macOS additionally checks notarization status. A failed signature aborts the update.
6

Apply on next restart

The verified update is staged. Studio applies it on the next restart so a long-running session is not interrupted mid-task.
The metadata file is served alongside the artifacts on the same controlled domain. Both are TLS-protected; the SHA-512 verification provides a defense-in-depth check that the bytes you ran through the OS-level signature check are also the bytes the release pipeline produced.

​
Release artifacts

Release artifacts are versioned and immutable. The naming follows:
ArtifactWhere to download
macOS Apple Siliconhttps://download.altostrat.io/studio/altostrat-studio-apple-arm64-latest.dmg
macOS Intelhttps://download.altostrat.io/studio/altostrat-studio-apple-x64-latest.dmg
Windows x64https://download.altostrat.io/studio/altostrat-studio-windows-x64-latest.exe
The latest symbolic links always point to the most recent release in the active channel. A specific version is also addressable by version number for organizations that want to pin to a known build.

​
Dependencies

Studio’s dependency surface is large by browser-app standards and small by desktop-app standards. The main lines of defense:
  • Lockfile enforcement. Every release builds against a committed lockfile. Floating versions are not used in production builds.
  • No post-install scripts. Dependencies that try to run scripts during install are rejected; the lockfile-install step disables this.
  • Periodic vulnerability scanning. The dependency tree is scanned against published advisory databases on every release; high-severity advisories block the release until addressed.
  • First-party crypto. Cryptographic primitives that matter for Studio’s safety claims are not pulled from arbitrary third parties. AES-256-GCM is BoringCrypto in the Go agent; KMS is AWS-managed; the JWT path is Clerk-managed.

​
What we do not do

  • No remote code load at runtime. Studio does not download and execute additional code modules at runtime. Updates always go through the signed installer flow.
  • No silent telemetry-driven feature flags that change behavior. Feature flags exist for staged rollout, but they enable or disable existing code paths; they do not load new code.
  • No second binary fetched at runtime. The Go sidecar is part of the signed installer. It is not a separate download.

​
What you can verify

  • The macOS signature: codesign -dv --verbose=4 /Applications/Altostrat\ Studio.app reports the signing identity and team.
  • The macOS notarization: spctl --assess --type execute /Applications/Altostrat\ Studio.app reports accepted from the notary service.
  • The Windows signature: right-click the installer → Properties → Digital Signatures, or Get-AuthenticodeSignature in PowerShell.
  • The release SHA-512: visible in latest-mac.yml / latest.yml on the download server, comparable against your downloaded installer.

​
Reporting a supply-chain concern

If you find something that looks like a tampered installer, an unexpected signature, a suspicious update prompt, or any indication that the supply-chain controls described here failed, contact us through troubleshooting. Supply-chain concerns are escalated immediately and not subject to normal triage queues.

Identity and access

The runtime authentication that depends on the signed binary having reached your machine intact.

Agent and local runtime

The two processes inside the signed installer and how they coordinate.