The detector catalogue
Every detector we run, what it reads, what it emits, and the confidence it can honestly claim — because a detector reports evidence, not a verdict
On this page — 6 sections
A detector is the smallest unit of discovery: one collector, pointed at one kind of surface, emitting one kind of evidence. Keeping them small is what allows a report to say which component produced a given claim, and what that component could not have known.
What a detector is, and is not
Each detector has a fixed contract. It reads a defined surface, emits evidence in a defined shape, states a confidence characterisation, and records its own version alongside every record it produces. It does not decide whether anything is wrong.
- One surface each. A detector that reads TLS handshakes does not also read configuration files. Two surfaces means two detectors and two independent records.
- Evidence, quoted. Output includes the observed material a reviewer would need to reach the same conclusion: the negotiated parameters, the certificate field, the manifest line, the directive.
- Read-only. No detector writes to a target, restarts a service, installs an agent or holds a credential beyond the run.
- Versioned.
pki.chain-walk@4is a different component frompki.chain-walk@3, and any change in output attributable to that difference is labelled as such.
Naming and versioning
Detector names are two parts, lowercase, separated by a dot: the surface family, then the thing being read. The family prefix tells you which credential a detector needs and therefore which conversation you will have with your own security team before it runs.
- `edge.*`
- Reachable network listeners. Needs a network position, no credential.
- `pki.*`
- Certificates and certificate authorities. Public material, plus a CA inventory export where one exists.
- `source.*`
- Version-controlled code and its dependency graph. Needs a read-only repository token.
- `image.*`
- Container images and their layers. Needs a pull-only registry credential.
- `config.*`
- Server, proxy and application configuration. Needs a configuration read or an operator-produced export.
- `access.*`
- SSH, VPN and remote access policy. Needs appliance or host configuration read.
- `transport.*`
- Brokers, queues and database listeners. Needs a configuration read or an administrative metadata query.
- `keystore.*` and `hsm.*`
- Key metadata and hardware modules. Needs a list-and-describe role only.
- `build.*`
- Release pipelines and signing paths. Needs read access to pipeline definitions.
Detector versions move independently of the scoring method version. A detector change alters what we saw. A method change alters what we concluded from it. Conflating the two makes a delta impossible to explain, which is why they are tracked separately and reconciled separately. See How the method is versioned.
Catalogue: network, PKI and transport
These detectors carry most of a first run. They need the least privilege and produce the most immediately actionable evidence, because the surfaces they read are the ones an adversary can also see.
| Detector | What it looks at | What it emits | Confidence characteristics |
|---|---|---|---|
edge.tls-handshake | Reachable TLS and mTLS listeners at agreed addresses | One asset per listener: protocol version, cipher suite, key-exchange group, signature algorithm, plus the handshake summary as evidence | High on what was negotiated with us. Silent on the full set of parameters the listener would accept unless enumeration is separately scoped. |
pki.chain-walk | Presented certificate chains, and CA inventories where exported | Subject key algorithm and size at each chain position, signature algorithm, validity window, issuer | High. Algorithm and key-size fields are explicit in the certificate, so there is little to infer. |
transport.broker-policy | Message broker, queue and event-bus listener configuration | Transport policy per listener, client authentication mode, inter-broker settings | High when configuration is read directly. Medium when derived from a client-side default rather than the broker itself. |
transport.db-listener | Database listener configuration and driver defaults | Required transport policy, at-rest algorithm selection, driver fallback behaviour | Medium. Drivers frequently override server preference at runtime, and the override is not visible from the listener. |
access.ssh-policy | sshd and client configuration, host key material as advertised | Host key algorithms, permitted key-exchange, cipher and MAC lists, per-user overrides | High on configured values. Blind to keys distributed outside the managed path. |
access.vpn-proposal | IKE and IPsec proposals, TLS VPN profiles | Proposal sets, forward-secrecy group, peer authentication method | High on the appliance configuration. Medium where clients carry their own profiles. |
config.cipher-directive | Web server, reverse proxy, load balancer and application configuration files | Explicit protocol and cipher directives, and the effective policy they compose | High where the file is authoritative. Medium where a downstream layer can override it silently. |
Catalogue: code, build, keys and hardware
The second group reads inside the estate rather than at its edges. These detectors find the cryptography that never appears in a handshake: signing paths, at-rest choices, libraries linked into shipped binaries, and the mechanisms a hardware module makes available.
| Detector | What it looks at | What it emits | Confidence characteristics |
|---|---|---|---|
source.crypto-call-site | Source files in repositories in scope | Call sites into cryptographic APIs, with algorithm arguments where they resolve statically | High where the algorithm is a literal. Falls to low where it is selected at runtime from configuration, and is reported as unresolved rather than guessed. |
source.dependency-graph | Manifests, lockfiles and resolved dependency trees | Cryptographic libraries and providers with versions, transitive providers, advisory matches from the GitHub Advisory Database | High on presence and version. Says nothing about whether the code path executes. |
image.layer-inventory | Container image layers, metadata and shipped binaries | Crypto libraries per layer, embedded trust stores, statically linked cryptography | High on presence. Medium on version when a binary is stripped of build metadata. |
build.signing-path | Release pipeline definitions and signing steps | Signing algorithm, key custody location, timestamp authority, presence of a verification gate before deployment | Medium. Pipelines often delegate to a step we can see only by name, and that step is reported as opaque. |
keystore.object-census | Key management service and key vault object metadata | Key type, size, algorithm, creation and rotation dates, usage flags, enabled state | High. Metadata is authoritative and requires no inference. |
hsm.mechanism-probe | Hardware security module management interface | Partition inventory, firmware level, supported mechanisms, availability of ML-KEM, ML-DSA and SLH-DSA mechanisms | High on capability. Silent on which mechanisms applications actually call, which is resolved from the application side instead. |
A detector reports evidence, not a verdict
No detector in the catalogue emits a risk rating, a tier or a recommendation. edge.tls-handshake will tell you that a listener negotiated a particular key-exchange group. It will not tell you that this is unacceptable. That judgement belongs to the scoring method, which is published, versioned and separately reviewable.
The separation is not stylistic. It is what makes both halves auditable. An auditor can dispute the evidence without touching the method, or dispute the method without re-running collection. If a detector emitted verdicts, every disagreement about policy would require a new scan.
Collection answers what is there. The method answers what it means. Keeping them apart is the only way either answer can be checked.The Theos Method, design principles
Confidence, and what each level licenses
Confidence describes how much interpretation sits between the evidence and the claim. It is a property of the collection path, not a probability we have measured, and it is reported per asset rather than per run.
- High
- The primitive is stated explicitly in material we read directly. A certificate field, a key metadata record, a negotiated handshake, an explicit configuration directive.
- Medium
- The primitive follows from a documented default, or from configuration that a lower layer could override without our seeing it.
- Low
- The primitive is one of several possibilities and the evidence does not narrow it further. Reported as a candidate set, never as a single answer.
- Unresolved
- A cryptographic use is present but its parameters could not be determined. This is a finding about coverage, not an empty row.
Out of scope
A detector will not upgrade its own confidence by inference. If source.crypto-call-site cannot resolve an algorithm because it is read from configuration at runtime, the asset stays unresolved until config.cipher-directive or keystore.object-census supplies the missing evidence. We do not fill the gap with the most likely value.
Aggregate accuracy for classification across the labelled evaluation set is 95.2%, with a macro-F1 of 0.94. Those figures describe the classifier that consumes detector output, not the detectors themselves, and they are broken down in Accuracy, false positives, and how we report error.
Knowing what each detector does is half the picture. The other half is the list of things none of them will ever do.Read the scope boundaries