The library documents itself · Security & governance
stzSecurityGraph
28 own methods · 0 forms written with extensions, listed under their method
the source: base/security/stzSecurityGraph.ring(opens in a new tab) · All classes · The area reference: Security & governance
Under each method, its extensions (Q CS XT Z ZZ IB W U): bold and ticked, it exists; struck, it does not. The extensions and what they mean
No method of this class is run on this page: the class reaches files, the network, processes, the clock, chance or sound, and an example run here would only be an example of its effects. Each method carries the explanation the library gives of itself.
Method
Explanation, as the source carries it
init
(no comment in the source: the name reads as a sentence) initno extension
GraphQ
(no comment in the source: the name reads as a sentence) graph qno extension
Name
(no comment in the source: the name reads as a sentence) nameno extension
AddActor
nodes ----------------------------------------------------------- posture: trusted | external | sandboxedno extension
Tampering
actors whose graph posture no longer matches the one AddActor recorded [ [ actor, recorded, found ], ... ]no extension
AddTool
(no comment in the source: the name reads as a sentence) add toolno extension
AddStore
(no comment in the source: the name reads as a sentence) add storeno extension
AddCapability
capabilities are auto-created by Holds/Grants, but may be declared toono extension
Holds
edges (the meaning is the label) -------------------------------- an actor directly holds a capabilityno extension
Uses
an actor uses a toolno extension
Grants
a tool grants (confers) a capabilityno extension
Delegates
an actor may act as another (delegation -- transitive trust)no extension
a site references a secret 1 examples runno extension
StoredIn
a secret lives in a storeno extension
MayAttach
the CONSTRAINT: no live secret to a sandboxed actor ------------- TRUE when attaching pcSecret to pcActor keeps the surface sound (a sandboxed actor must not hold a live secret it could exfiltrate).no extension
AttachSecret
Attach a secret to an actor -- the governed door. REFUSED for a sandboxed actor at construction (audit -> gate), so the escalation can never enter the graph through the sanctioned API.no extension
ReachesEffectful
queries --------------------------------------------------------- Can this actor reach the 'effectful' capability by ANY path (directly, or through a tool, or through delegation)? The multi-hop escalation question.no extension
ReachesCapability
(no comment in the source: the name reads as a sentence) reaches capabilityno extension
PathToCapability
THE PATH ITSELF, not merely whether one exists (incident I5): an investigation must be able to say HOW an actor could reach a capability -- "billing-agent -> deploy-tool -> effectful" -- and an empty list means no path.no extension
PathToEffectful
(no comment in the source: the name reads as a sentence) path to effectfulno extension
CutCapability
Remove EVERY path by which pcActor reaches pcCapability, by cutting the actor's OWN first-hop edges that lead there: a capability it holds directly, a tool it uses that grants it, an actor it delegates to that reaches it. Other actors are untouched -- a colleague using the same tool keeps it. Returns the edges removed, as [ from, label, to ].no extension
BlastRadius
Every node that can REACH this secret (reverse reachability) -- the blast radius: which sites and actors a leaked secret exposes. Rotation planning.no extension
AuditEscalations
(no comment in the source: the name reads as a sentence) audit escalationsno extension
NumberOfEscalations
(no comment in the source: the name reads as a sentence) number of escalationsno extension
Violations
proof + internalsalso written: CheckRulesno extension
IsSound
(no comment in the source: the name reads as a sentence) is soundalso written: RulesAreSoundno extension