Security questionnaire answers

Pre-filled answers for the questions buyers ask most. Copy into their form; adjust wording to their question.

Hosting and data

• Where is customer data stored? On the customer's own server. Gardience is self-hosted; Bouziden Management hosts nothing and receives no customer data.
• Does the product phone home or send telemetry? No. The license is verified offline. An optional daily release check (off by default, turned on by an admin) sends only the license and version to gardience.com. Pages load nothing from the internet (verified by an automated browser crawl).
• Can it run air-gapped? Yes, from an offline bundle with all images prebuilt.
• Data at rest encryption? Vault secrets: AES-256-GCM. Backups: optional AES-256 with a passphrase. Disk encryption is the host's (customer's) choice.
• Data in transit? HTTPS only (TLS 1.2/1.3, HSTS). Agent traffic uses Salt's encrypted transport, with the newest authentication protocol required.

Access control

• SSO? SAML 2.0 and OpenID Connect, plus AD/LDAP (StartTLS on by default). Automated tests run against Keycloak, and Active Directory is tested in every release. Okta and Microsoft Entra ID were each tested with both OIDC and SAML, including group-to-role mapping, in October 2026. Google and Ping use the same standards and are confirmed with each customer during onboarding.
• MFA? Through the customer's IdP (enforced there).
• RBAC? Yes: admin, operator, approver, viewer, Windows help desk; scoping to node groups and commands.
• Privileged access? No person holds direct Salt rights day to day: every role, admins included, changes machines through Gardience (approvals, change windows, locks, audit). Root on the server can open a time-limited break-glass account (gardience breakglass on, 5 to 240 minutes) that Gardience audits, announces and closes on time. Every change passes through Gardience's per-node permission check, approvals, change windows and locks. Change windows also apply to workflows, schedules, API runs and held work; an admin can override them with a recorded reason. The live event stream (every job's arguments and output) is limited to admins.
• Service accounts? Gardience uses two: a scanner (read and patch-status only) and an automation identity that carries out changes after Gardience's checks. The automation identity holds Salt rights only for the functions Gardience calls, never all of Salt.
• Arbitrary command execution? Off on new installs (since 1.3.0), enforced by the Salt master's own permission list, so even a compromised web service could not run commands on the fleet. An admin turns it on with one command (gardience automation commands on); every command run is approved, audited and attributed. Their passwords are random (32 characters), stored owner-only on the server, never displayed, and every action by the automation identity is audited with the person it acted for.
• Session timeout? Local accounts: 8 hours by default (session_hours in users.yaml, 1 to 24). Directory (LDAP) and single sign-on accounts: 1 hour (directory_session_hours), so directory changes apply within the hour. One sign-in covers every open tab; signing out in any tab ends it everywhere, and closing every console tab ends it after a minute. Removing a user, changing their role or resetting their password ends their open sessions at once; gardience user signout NAME|--all does the same on demand.
• Separation of duties? Two-person approval; a requester cannot approve their own run. Baseline or reboot on more than one node from the dashboard, and clearing an audit tamper alarm, also need a second person.

AI features

• Does the product use AI? Optional and off by default. An admin can connect the customer's own AI service (Anthropic, OpenAI, Azure OpenAI or a self-hosted model) for the in-console assistant. The assistant only proposes a runbook or one Salt command; a person reviews and runs it under their own permissions, approvals and audit. It has no direct Salt access. Sent per request: the request text, page context (selected group or machine names), node group and runbook names, and the allowed command list; never secrets, audit or inventory data. Key stored encrypted.
• Bouziden Management receives none of this; the customer's server talks to the customer's AI service directly.

Logging and monitoring

• Audit logging? Sign-ins (local, LDAP and SSO, including failures), commands, approvals, changes and admin actions: who, what, where, when, and on whose behalf. Every change also records its per-node outcome in the chain: each node that succeeded and each that failed, with the reason, including changes interrupted by a service restart (collected from Salt's job cache when the service is back). Jobs the live event stream misses are added from the master's job cache. Keyed HMAC-SHA256 hash chain, verified every 15 minutes and on demand. The signed evidence pack for auditors carries the per-node results (change-results.csv), checked by the shipped verifier. If the log cannot be written, Gardience refuses changes until it can. Routine read-only scans record a node count and a SHA-256 of the node list rather than every name.
• SIEM integration? Forwarding over syslog TCP or TLS (RFC 6587) within seconds, resuming from the last entry sent after an outage. Syslog has no delivery receipt, so loss inside the SIEM itself is not detected; the full log and its keyed verification remain on the server. UDP is supported but cannot detect loss.
• Log retention? Kept on the customer's server indefinitely in 50 MB sealed segments. There is no automated retention: archive old sealed segments yourself (verification needs the whole chain) or rely on your SIEM.

Application security

• Secure development? See SSDF-SELF-ATTESTATION-DRAFT.md.
• Penetration test? Not yet by an independent firm. Every release must pass our own testing with standard tools: an OWASP ZAP attack scan of all endpoints signed in as an admin (the test fails if the sign-in does not work), nuclei, testssl.sh, nmap, Bandit and Trivy, plus our own SSO tampering and replay, permission tests, playbook sandbox isolation, audit-chain forgery, forged-event and release-tampering tests. Current numbers in SECURITY-TESTING.md. A separate adversarial code review in October 2026 found issues our own tests had missed; the confirmed ones were fixed (listed there).
• SBOM? CycloneDX per container image, built from the exact images in each offline bundle and published with the release.
• Vulnerability management? Every release must pass two scans: pip-audit of every pinned Python dependency (OSV/PyPI advisories) and a Trivy scan of each container image (OS packages and copies vendored inside Python packages). A fixable HIGH or CRITICAL finding blocks the release. CVE fixes within 7 days.
• Code signing? Releases are signed (Ed25519); upgrades verify signatures.

Business continuity

• Backup and restore? Built in, including the Salt PKI so agents never need re-trusting. Tested every release.
• RTO / RPO? See DR-RUNBOOK.md (RTO about a minute after promoting a warm standby, under 1 hour by restore; RPO = the sync interval for fleet data, about a minute for agent keys, seconds for the audit trail via SIEM forwarding over TCP or TLS).
• High availability? Primary plus optional warm standby: encrypted backups ship to the standby on a schedule and one command promotes it (refused while the old primary still runs); agents then reconnect on their own with no re-approval (about 20 seconds after promotion in our release drill). A returning old primary fences itself. Failover can be automatic (since 1.3.0, optional): with a witness configured, the standby promotes itself only when the primary's signed heartbeat is older than the set limit (3 minutes or more), the primary does not answer the standby, and the standby can read the witness; a primary cut off from both stops serving first, so there are never two primaries. Proven by the automatic failover drill in every release check. Or leave it manual: one command. No active-active clustering.
• Monitoring? Prometheus metrics endpoint (read-only API key) and gardience doctor health check.

Company

• Company: Bouziden Management LLC, Norman, Oklahoma. SAM registered (UEI Y5LBHH9WJ399, CAGE 22VQ0).
• Insurance: not yet in place. Technology E&O and cyber coverage will be bound before any production contract is signed, and we confirm limits in writing then.
• SOC 2 / ISO 27001: Not certified. Gardience is self-hosted and we hold no customer data.
• Subprocessors: none for the product. (The website uses Netlify.)