Assessing Altiward for your organisation
For security, procurement and architecture reviews: what Altiward is, how it's built, released and supported, what you run yourself, and what it doesn't have yet.
Last reviewed
At a glance
| Question | Answer | Evidence |
|---|---|---|
| What is it? | Oversight for SAP Privileges on Macs: an agent on each Mac, and a server, database and web console you run. It checks who holds admin against what Privileges granted, can remove rights, and sends the record to your SIEM. It never grants admin itself. | README, How it works |
| Is it released? | Yes | Releases for altiward, altiward-forwarder and altiward-siem |
| Licence and cost | Apache 2.0, free. There's no licence key or activation, so nothing stops working when a contract ends. | LICENSE |
| Where does the data go? | To your server, then to the SIEM and identity provider you configure. No telemetry, crash reporting or registration, and nothing is sent to us. | Data handling |
| Development practices | Altiward meets the OpenSSF Best Practices passing criteria (October 2026): a self-assessment against the Open Source Security Foundation's criteria for change control, reporting, testing, security and analysis, with each answer and its evidence public. | OpenSSF Best Practices, project 15960, and the weekly OpenSSF Scorecard |
| Who supports it? | The project, through GitHub Discussions and issues, with no guaranteed response time. There's no paid support contract today. | Getting help |
How releases are built and signed
Every release can be traced to the source it was built from. Releasing documents the process.
- Built by CI from a protected tag
- GitHub Actions builds each release from a version tag, never on someone's computer. Release tags can't be changed or deleted once pushed, and a maintainer approves each release run before anything is built or signed.
- Signed, with a public record
- The server image and each release's checksums are signed with cosign by the release workflow's own GitHub identity, and the signatures are recorded in Sigstore's public transparency log. No one holds a signing key that could be copied.
- SBOM and provenance
- The server and forwarder images are published with a software bill of materials and build provenance.
- Notarized Mac packages
- The agent package and the forwarder's on-Mac hook are signed with Apple's Developer ID and notarized by Apple.
- Checked before an upgrade
upgrade.shchecks the files against the signed checksums, and the signature, before it changes anything. You can check a release by hand too.
How changes reach the code
- Pull requests with required checks
- Every change to
maingoes through a pull request that must pass CI: the server's tests against Postgres andgovulncheck, the Mac agent's build and tests, the console build, and a check that the server image starts, installs and upgrades withupgrade.sh. Each commit carries a Developer Certificate of Origin sign-off. - Dependencies kept current
- Dependabot checks the Go, npm, Docker and GitHub Actions dependencies every week.
- Source you can read
- The architecture, the agent's design notes and the event schema are public, along with all the code, for your own review.
Vulnerabilities and supported versions
- Private reporting
- Reports come in through GitHub's private vulnerability reporting or by email. We acknowledge them within five working days and publish a security advisory with the fix. See Reporting a security problem.
- Supported versions
- Fixes go to the latest two minor versions of the server and the agent, and to the latest forwarder release. A new minor version comes about each quarter, so each is supported for about six months. See the security policy.
- Security fixes are flagged
- Each release's notes have a Security heading, and the console tells admins when a newer release is out and whether it fixes a security problem.
What you run
Altiward is self-hosted: your team owns the server, its data and its upgrades. The install guide covers each step.
Deploy
The server is one container, with Postgres and Caddy for TLS, on a Linux server with Docker Compose, on your own Postgres and load balancer, or on Azure Container Apps with Deploy to Azure. Your MDM installs the agent, to a pilot group first.
Upgrade
upgrade.sh checks the release, shows its upgrade order, breaking changes and security fixes, backs up the database and settings, and asks before changing anything. Nothing updates itself. The server accepts the last two agent minor versions, so Macs can catch up at your pace.
Operate
You back up Postgres, look after certificates if Caddy doesn't, connect single sign-on and your SIEM, and watch Fleet for Macs that stop checking in. Removing Altiward leaves SAP Privileges working as before.
Questions from reviewers
Is Altiward a PAM product, like BeyondTrust or CyberArk?
No. It doesn't vault credentials, record sessions or grant admin. It adds oversight to SAP Privileges on Macs: whether the admin rights on each Mac match what Privileges granted, and evidence for your SIEM. Compare it with SAP Privileges alone, or with other temporary Mac admin tools.
Does it help with the DSPT?
It gives you evidence for CAF-aligned DSPT outcomes B2.c and C1 on your Macs. See DSPT evidence for admin rights on your Macs.
Who do we contact?
Email hello@altiward.com. For a security problem, follow Reporting a security problem instead.
Start your review
Data handling lists what Altiward collects, stores and sends. The install guide covers the server, agent, SIEM export and upgrades.