Security
Security overview
BLACKGLASS is a configuration-integrity product. This page describes what it does to improve your security posture — and how we protect the data you entrust to us.
What BLACKGLASS does for security
Integrity first, monitoring second
BLACKGLASS is not a SIEM, a vulnerability scanner, or a log aggregator. It is a configuration-integrity product. Its job is to answer one question: is this host still in the configuration we approved, and if not, what changed, when, and why does it matter? Every feature — baselines, drift detection, risk classification, evidence export — exists to answer that question reliably and with an auditable record.
Baseline creation
A baseline is a point-in-time snapshot of a host's security-relevant configuration: listening ports, local users and group memberships, sudo rules, enabled systemd units, SSH daemon policy, firewall rules, installed packages, and kernel parameters. Without an explicit baseline, drift is undetectable — you cannot tell whether a new port or user is authorised or a sign of compromise. Baselines are also compliance evidence: proof that a system was in an acceptable state at a specific time.
Drift detection
At each scan, BLACKGLASS re-collects the same surface areas and diffs against the active baseline. Every changed, added, or removed item surfaces as a finding. Configuration drift is a well-documented attack vector — attackers abuse CI pipelines, provisioning scripts, and emergency access to make changes that are never reviewed or reverted. BLACKGLASS makes that drift visible and attributable.
| Category | What is detected |
|---|---|
| Network | New or removed listening ports, firewall rule changes |
| Identity | New users, removed users, group membership changes, sudo policy changes |
| Persistence | New systemd units or services, authorised SSH key changes, crontab changes |
| Policy | sshd configuration deviations (e.g. PasswordAuthentication, X11Forwarding) |
| Supply chain | Installed or removed packages, version changes |
| Integrity | File hash deviations on critical system files |
| Privilege escalation | New SUID/SGID binaries, new kernel modules |
| Environment | /etc/hosts changes (DNS hijack detection) |
Risk classification
Raw findings are classified into categories that map to standard security risk taxonomy: network exposure, identity drift, persistence, policy mismatch, and package / supply-chain changes. Classification tells a responder whether a finding is a potential lateral-movement vector, a compliance gap, or a sign of attacker activity — so teams can triage rather than guess.
Evidence and reporting
- –Host baseline report — structured record of what the host looked like at baseline time, suitable for a change record or audit questionnaire
- –Drift report — timestamped diff between baseline and current state, with risk classification and recommended response
- –Fleet posture summary — across all enrolled hosts: unacknowledged drift by category and severity, with trending
- –Evidence bundles — exportable packages containing baseline, findings, acknowledgements, and operator notes for SOC 2, post-incident review, or CAB submission
- –Audit timeline — chronological view of what changed on each host across all scans
How BLACKGLASS protects your data
Encryption and transport
All UI and API traffic is served over HTTPS / TLS 1.3. There are no HTTP endpoints. Drift results, baselines, evidence bundles, and audit logs are encrypted at rest (AES-256). Encryption is always on — not an option.
Access control
Three built-in roles: Viewer (read-only), Operator (scan + acknowledge), and Admin (full access). API tokens are scoped to a role at issuance. Enterprise adds SSO / SAML / OIDC with MFA enforced at your identity provider.
Data minimisation and retention
BLACKGLASS collects only what is needed to compute drift — not file contents, not environment variables, not secrets. Retention is configurable per plan (30 days free, 180 days Pro, custom on Enterprise). Data is hard-deleted after the window closes — not hidden, removed.
Secrets and credential handling
SSH credentials are never stored. They are fetched just-in-time from a pluggable SecretProvider (Doppler, Infisical, Vault, or env vars for dev), held in memory only for the scan connection lifetime, and never written to disk or logs. The browser never sees raw credentials.
Audit logging
Every security-relevant action is recorded: authentication, scan execution, baseline changes, drift acknowledgement, evidence export, and user management. Logs are append-only at the application layer and kept separate from raw operational output. No host configuration data is written to application logs.
Platform hardening
The service runs on hardened cloud infrastructure with network segmentation and SSH-key management access. All secrets are managed via a secrets manager — none are committed to source control. Dependencies are pinned and reviewed on a regular vulnerability cadence. Tenant data is scoped by workspace at the application layer.
Ready to start monitoring?
Connect your first host in minutes. No agents. No open inbound ports.