What sealfix protects

Edition: Community and Enterprise

Every security tool has a boundary. This page states sealfix's plainly, so you know what it guarantees and what remains yours to secure.

flowchart TB
    subgraph P["Protected by sealfix"]
      direction LR
      a["Values hidden from DBAs,<br/>tickets and e-mails"]
      b["No single-person<br/>production change"]
      c["No over-wide change"]
      d["Every change<br/>reversible"]
      e["No edited<br/>audit trail"]
      f["No swapped values<br/>after approval"]
    end
    subgraph Y["Yours to secure"]
      direction LR
      g["DBAs with SYSDBA or<br/>sysadmin on the target"]
      h["Bind values the target<br/>database records itself"]
      i["Root on the<br/>executor host"]
    end
    classDef ok fill:#E9EEF6,stroke:#23407A,color:#13202D
    classDef you fill:#F6E8EB,stroke:#7D1D2F,color:#13202D
    class a,b,c,d,e,f ok
    class g,h,i you

What it protects

Threat	How sealfix stops it
A customer's data in a ticket, e-mail or chat	Values are sealed on arrival; nobody around the change sees them
A DBA reading the values while reviewing	The DBA's view has no values, not even masked
One person changing production alone	Two approvals by different people, never the requester
A fix that touches far more rows than intended	The dry run counts rows; the execution rolls back if the count differs or exceeds the limit
A change that cannot be undone	Sealed before-images and a governed rollback
Someone editing the trail afterwards	Append-only by database grants, hash chain, signed checkpoints
Values or SQL swapped after approval	Every approval binds a digest of the template, the values, the target and the assessment
A stolen session approving a fix	Signed approvals with the approver's passkey, and a fresh passkey check before approving

What it does not protect, and what to do

Boundary	Why sealfix cannot cover it	What you do
A DBA with SYSDBA or sysadmin on the target	They can read the tables directly, outside sealfix	Limit those accounts; audit their use on the database
Bind values the target records itself	Statement logs, bind capture and traces sit inside the database	Harden the target (Targets); the connection test points these out
Root on the executor host	The executor holds the private key in memory	Harden the host, or keep the keys in an HSM (Enterprise)
A compromised web application with its database credentials	It could add requests and approvals of its own	Signed approvals make such approvals fail at the executor

How it is checked

• Tests for every invariant. Each guarantee above has tests that fail if it breaks, including a test that plants a value and looks for it in every log, response and error.
• Architecture tests. The rules about which code may depend on which are themselves tested.
• Static analysis and dependency scanning on every change.
• Signed releases with a software bill of materials.