01 / TRUST
Least privilege
Applications and services should receive only the permissions needed for their role, with sensitive access made explicit where practical.
SAGE / SECURITY
Security should be understandable, layered and continuously tested.
Sage is being developed with security as a system property rather than a marketing feature. The principles below describe product direction; they are not a certification, guarantee or claim that Sage currently satisfies a particular security standard.
02 / ISOLATION
Clear boundaries
System components should be separated in ways that reduce unnecessary trust and limit the effect of individual failures.
03 / UPDATES
Maintainable security
A secure platform must be updateable. Sage is being shaped around reliable update, recovery and maintenance paths rather than assuming software remains static.
SECURITY POSITION
No operating system is “unhackable.”
Vidran will avoid absolute security claims. As Sage matures, public documentation should distinguish implemented controls, planned controls, testing methods, known limitations and the environments for which a given release is appropriate.
AREAS OF DEVELOPMENT
Security work spans the entire product.
Application permissions
Designing clearer controls around access to files, devices, identity, network services and other sensitive resources.
Software integrity
Exploring mechanisms for trusted distribution, validation and safer installation of software.
Data protection
Considering encryption, credential handling, secure storage and recovery as integrated platform concerns.
Security response
Future public releases should include a defined vulnerability-reporting and remediation process appropriate to the maturity of the platform.