Documentation

AWS Certificate & Key Discovery

Discover_AWS — scans AWS Certificate Manager (ACM) and IAM for certificates and keys in a specified region.

Many organizations terminate TLS on AWS load balancers and CDNs using certificates held in ACM, keep older server certificates in IAM, and sign or encrypt with asymmetric keys in AWS KMS. None of these show up in a scan of your servers, so this sensor reads them directly from the AWS APIs and adds them to the inventory next to everything else. Expiry, key algorithm and key size are then scored by policy like any other certificate or key.

It makes read-only API calls only. A typical setup is one task per account and region, run from the CBOM discovery server on a schedule.

What it finds

ACM certificates in the configured region: domain name, issuer, status, key algorithm and size, and expiry date. Where ACM returns the certificate body, its public key fingerprint is recorded too.
IAM server certificates (these are global, not tied to a region). Each one is fully parsed: subject, issuer, validity period, key algorithm and size.
KMS asymmetric keys (RSA, elliptic-curve and ML-DSA): key spec, key usage, key size, the curve for EC keys, enabled or disabled state, and the public key fingerprint.
The AWS resource ID (ARN or certificate name) and region of every item, so you can trace it back to the console.
Not collected: symmetric KMS keys (SYMMETRIC_DEFAULT) and HMAC keys are skipped. No private key material is ever read. The sensor only fetches certificate bodies and KMS public keys.

Requirements

Runs as	Both. Usually runs in the cloud from the CBOM discovery server. It can also run on a networked agent, because the agent package includes the AWS client libraries.
Reaches the target over	The AWS public API endpoints for ACM, IAM and KMS, over HTTPS (port 443).
Credentials and permissions	An IAM access key pair, plus an STS session token if the credentials are temporary. The sensor does not use instance profiles or a local AWS profile, so you must enter the keys explicitly. It needs these read-only permissions: `acm:ListCertificates`, `acm:DescribeCertificate`, `acm:GetCertificate`, `iam:ListServerCertificates`, `iam:GetServerCertificate`, `kms:ListKeys`, `kms:DescribeKey`, `kms:GetPublicKey`. You only need the permissions for the services you select.
Platform	Any.
Prerequisites	Outbound HTTPS from the machine running the sensor to AWS. Nothing needs to be installed in the AWS account.
Required parameters	`aws_access_key_id`, `aws_secret_access_key`, `region`, `services`, `schema`, `scan_name`.
Setup guide	AWS sensor guide

Parameter	Type	Required	Description
`aws_access_key_id`	string	Yes	AWS access key ID for the scanning IAM identity.
`aws_secret_access_key`	string	Yes	Corresponding AWS secret access key.
`aws_session_token`	string	No	Temporary session token. Required only when using STS assumed-role credentials.
`region`	string	Yes	AWS region to scan (e.g. `us-east-1`, `eu-west-1`). One region per task; create multiple tasks for multi-region coverage. IAM server certificates are global and are returned whatever region you choose.
`services`	list	Yes	AWS services to include. Supported values: `acm`, `iam`, `kms`.
`schema`	string	Yes	Output format: `cbom` (CBOM standard) or `clm` (CLM format). The Template wizard always sets `cbom`.
`scan_name`	string	No	Human-readable label for the scan. Default: `AWS Certificate Discovery`.

Required IAM permissions: acm:ListCertificates, acm:DescribeCertificate, acm:GetCertificate, iam:ListServerCertificates, iam:GetServerCertificate.

Use Case 1 — Scan ACM + IAM in us-east-1. Discover all certificates managed by ACM and any server certificates stored in IAM for the primary US region.

Tasks:
  - Name: AWS-East-Scan
    ExtName: Discover_AWS
    Config:
      aws_access_key_id: "AKIAIOSFODNN7EXAMPLE"
      aws_secret_access_key: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
      region: us-east-1
      services:
        - acm
        - iam
      schema: cbom
      scan_name: "AWS-East-Production"

Use Case 2 — Assumed role via STS (cross-account). Use a short-lived STS token to scan a different AWS account without embedding long-lived keys.

Tasks:
  - Name: AWS-CrossAccount-Scan
    ExtName: Discover_AWS
    Config:
      aws_access_key_id: "ASIAIOSFODNN7EXAMPLE"
      aws_secret_access_key: "<sts-secret>"
      aws_session_token: "<sts-session-token>"
      region: eu-west-1
      services:
        - acm
      schema: cbom
      scan_name: "AWS-EU-CrossAccount"

Azure Certificate & Key Discovery

Discover_Azure — discovers certificates and keys across Azure Key Vault, web apps, Application Gateway, API Management, and Front Door using an Entra ID service principal.

In Azure, certificates and keys sit in two kinds of place. Some are stored in Key Vault. Others are bound to the services that terminate TLS for your public endpoints: App Service, Application Gateway and Front Door. This sensor covers both, so the inventory shows the certificates your customers actually see, not only the ones someone remembered to put in a vault.

It reads from Azure Resource Manager and the Key Vault APIs. For the TLS services, it also connects to each public hostname and reads the certificate that endpoint presents. A typical setup is one task per subscription, run from the CBOM discovery server.

What it finds

Key Vault certificates, including pending ones. Each is fully parsed: subject, issuer, validity period, key algorithm and size, and fingerprints.
Key Vault keys of type RSA and EC (software or HSM-backed): key type, size or curve, permitted operations, enabled state, and public key fingerprint.
App Service (web apps): the certificate served on each custom and default hostname. The .scm.azurewebsites.net management hostnames are skipped.
Application Gateway: the certificate served on each gateway's public IP or DNS name. A certificate that fails trust verification, such as a self-signed one, is still recorded and marked as untrusted.
Front Door (classic, and Standard/Premium profiles): the certificate served on each frontend endpoint and custom domain.
The Azure resource ID, region and hostname of every item.
Not collected: Key Vault secrets, private keys and symmetric (oct) keys. Only public certificates and public key components are read.

Requirements

Runs as	Both. Usually runs in the cloud from the CBOM discovery server. It can also run on a networked agent.
Reaches the target over	The Azure Resource Manager and Key Vault (`https://<vault>.vault.azure.net`) APIs over HTTPS (port 443). For App Service, Application Gateway and Front Door, it also makes a direct TLS connection to port 443 of each discovered hostname or public IP. The machine running the sensor must be able to reach those endpoints.
Credentials and permissions	An Entra ID service principal (tenant ID, client ID and client secret). The principal needs read access to the subscription's resources, so it can list web apps, application gateways and their public IPs, Front Door and CDN profiles, API Management instances and key vaults. On each vault it needs List and Get on certificates and keys. No write permission is needed.
Platform	Any.
Prerequisites	Outbound HTTPS to Azure and to the public endpoints being checked.
Required parameters	`client_id`, `tenant_id`, `client_secret`, `subscription_id`, `services`, `schema`.
Setup guide	Azure sensor guide

Parameter	Type	Required	Description
`vault_urls`	list	No	Azure Key Vault base URLs to scan (e.g. `https://myvault.vault.azure.net/`). If omitted, every vault the service principal can list in the subscription is scanned. Set it when the principal has access to the vaults but not read access to the subscription.
`client_id`	string	Yes	Entra ID (Azure AD) service principal application (client) ID.
`tenant_id`	string	Yes	Entra ID tenant ID (directory ID).
`client_secret`	string	Yes	Service principal client secret.
`subscription_id`	string	Yes	Azure subscription ID to scan.
`services`	list	Yes	Azure services to scan. Options: `keyvault`, `web_apps`, `app_gateways`, `frontdoors`, `apim`. `apim` lists API Management instances only; it does not retrieve their certificates.
`schema`	string	Yes	Output format: `cbom` or `clm`. The Template wizard always sets `cbom`.
`scan_name`	string	No	Label stored in scan metadata: 3–100 letters, digits, hyphens or underscores.

Use Case 1 — Key Vault + Web App certificate scan.

ExtName: Discover_Azure
vault_urls:
  - https://prod-vault.vault.azure.net/
  - https://dr-vault.vault.azure.net/
client_id: "<sp-client-id>"
tenant_id: "<tenant-id>"
client_secret: "<sp-secret>"
subscription_id: "<subscription-id>"
include_managed_hsm: false
services:
  - keyvault
  - web_apps
schema: cbom
scan_name: "Azure-Production-Scan"

Use Case 2 — Full perimeter scan including App Gateway & API Management. Scan all TLS termination points in a subscription to identify certificates attached to ingress resources.

ExtName: Discover_Azure
vault_urls:
  - https://corp-keyvault.vault.azure.net/
client_id: "<sp-client-id>"
tenant_id: "<tenant-id>"
client_secret: "<sp-secret>"
subscription_id: "<subscription-id>"
services:
  - keyvault
  - app_gateways
  - frontdoors
  - apim
schema: cbom
scan_name: "Azure-Full-Perimeter"

GCP Cloud KMS Discovery

Discover_GCPKMS — enumerates key rings and crypto keys in Google Cloud KMS, extracting public key material and key metadata.

Google Cloud KMS holds the encryption and signing keys behind many Google Cloud workloads, including customer-managed encryption keys for storage and databases. This sensor adds those keys to the inventory with their algorithm, protection level and rotation schedule. Keys that are software-protected, past due for rotation, or using a weak algorithm then show up next to the rest of your estate.

It makes read-only Cloud KMS API calls for one project and location per task. A typical setup is one task per project and region, run from the CBOM discovery server.

What it finds

Key rings in the project and location: all of them, or one named key ring.
Crypto keys in each key ring, read from the key's primary version: the Cloud KMS algorithm, key purpose, protection level (software, HSM or external), enabled or disabled state, rotation period and next scheduled rotation.
For asymmetric keys, the public key, its size and its fingerprint.
The full resource name of the key and of the key version.
Not collected: private and symmetric key material, which Cloud KMS never releases.

Requirements

Runs as	Both. Usually runs in the cloud from the CBOM discovery server. It can also run on a networked agent.
Reaches the target over	The Cloud KMS API (`cloudkms.googleapis.com`) over HTTPS (port 443).
Credentials and permissions	Google Application Default Credentials on the machine running the sensor. That means either a service-account key file named by `GOOGLE_APPLICATION_CREDENTIALS`, or `gcloud auth application-default login`. The task configuration has no credential field, so every GCP task run from one machine uses the same identity. Read-only permissions needed: `cloudkms.keyRings.list`, `cloudkms.cryptoKeys.list` and `cloudkms.cryptoKeyVersions.viewPublicKey`.
Platform	Any.
Prerequisites	Application Default Credentials configured for the account the sensor runs under, and outbound HTTPS to Google APIs.
Required parameters	`project_id`, `location_id`, `key_ring_id`.
Setup guide	Google Cloud sensor guide

Parameter	Type	Required	Description
`project_id`	string	Yes	GCP project ID (e.g. `my-project-123`).
`location_id`	string	No	KMS location (e.g. `global`, `us-east1`). Default: `global`. The Template wizard requires it and offers a fixed list of locations.
`key_ring_id`	string	No	Target a specific key ring. If omitted, all key rings in the project/location are enumerated. The Template wizard requires it.

Authentication: Authenticate via Application Default Credentials (ADC): run gcloud auth application-default login on the scanning host or set the GOOGLE_APPLICATION_CREDENTIALS environment variable to a service account JSON file path.

Use Case 1 — Scan a specific key ring.

ExtName: Discover_GCPKMS
project_id: "my-project-123"
location_id: "global"
key_ring_id: "production-keyring"

Use Case 2 — Scan all key rings in a regional location.

ExtName: Discover_GCPKMS
project_id: "my-project-123"
location_id: "us-central1"

Active Directory Discovery

Discover_ActiveDirectory — performs a comprehensive multi-phase scan of one or more AD forests, discovering certificates, SSH keys, BitLocker recovery keys, DPAPI secrets, Kerberos keys, and cross-forest trust certificates stored in directory attributes and domain controller stores.

Active Directory is where a Windows estate keeps much of its trust: user and computer certificates, the enterprise CA certificates every domain member trusts, Windows Hello for Business keys, and the keys behind Kerberos, BitLocker, DPAPI and domain trusts. Inventorying the directory shows which of these exist, which algorithms and sizes they use, and how old they are — for example, a krbtgt key that has not been rotated for years, or RSA-1024 certificates still published on user accounts.

The sensor reads the directory over LDAP or LDAPS from wherever it runs; nothing is installed on the domain controllers. It is read-only: secret values such as BitLocker recovery passwords, KDS root key data, trust passwords and DPAPI backup key bytes are never requested — only the metadata that describes them.

What it finds

Certificates on directory objects — the userCertificate attribute on users, computers, service accounts, contacts and devices, with subject, issuer, serial number, validity dates, key algorithm and size, signature algorithm, key usage, extended key usage and subject alternative names.
CA certificates — root, intermediate and AIA certificates published in the configuration partition (cACertificate), and cross-certificate pairs (crossCertificatePair).
Revocation status — base and delta CRLs published in the directory are read first, and certificates whose serial appears in them are marked revoked.
SSH public keys mapped to accounts through altSecurityIdentities.
Windows Hello for Business / NGC keys stored in msDS-KeyCredentialLink.
Key metadata without the key — BitLocker recovery objects (computer, volume and recovery GUIDs, creation date), KDS root keys used for gMSA passwords, domain trust keys, DPAPI domain backup keys (including which one is current) and krbtgt Kerberos keys with their last rotation date. The algorithm and size recorded for these are the ones Windows uses by design; the key values themselves are not read.
Coverage across a forest — Global Catalog servers can be used to find every domain controller in the forest. A Global Catalog itself only serves the certificate phases; the key phases run against domain controllers.
Not collected — AD FS certificates (use the Windows certificate store sensor on the AD FS server), certificate templates, and any private key or secret value.

Requirements

Runs as	Both. Cloud from the discovery server, or Networked from an agent on any host that can reach the domain controllers. Nothing is installed on the domain controllers themselves.
Reaches the target over	LDAPS on port 636 (default) or LDAP on 389 to domain controllers; 3269 (LDAPS) or 3268 (LDAP) to Global Catalog servers. A non-standard port can be set per server. Entries without a server name are located through DNS SRV records, so the scanning host must use the AD DNS servers.
Credentials and permissions	A read-only domain service account, bound with NTLM (default) or a simple bind; anonymous bind is also accepted. Credentials set on a forest are inherited by its domain controllers and can be overridden per controller. Some objects (for example the DPAPI backup key pointer) are readable only by privileged accounts; without that access those phases report fewer or no results rather than failing the scan.
Platform	Not restricted — runs on Linux or Windows.
Prerequisites	Network reachability to each domain controller. To validate a controller's TLS certificate, give the path to its issuing CA certificate in `ca_cert_path`; the path is read on the machine where the sensor runs.
Required parameters	`forests`, and in each forest `name`, `username` and `password` (unless `anonymous`), plus at least one entry under `domains` or `gc_servers` with a `server` or `base_dn`.
Setup guide	Active Directory sensor setup

Global settings

Parameter	Type	Required	Description
`scan_name`	string	No	Label embedded in every emitted record's `scanProperties.config`.
`page_size`	integer	No	LDAP paged-results size (100–10000). Default: `500`.
`connect_timeout_seconds`	integer	No	Seconds before a connection attempt is abandoned. Default: `10`. YAML only.
`search_timeout_seconds`	integer	No	Seconds before an individual LDAP query times out. Default: `30`. YAML only.
`retry_attempts`	integer	No	Retry count on transient failures. Default: `3`. YAML only.
`retry_delay_seconds`	integer	No	Seconds to wait between retries. Default: `5`. YAML only.
`follow_referrals`	boolean	No	Follow LDAP referrals to other forests. Keep `false` to avoid referral loops. Default: `false`. YAML only.

YAML only. The five settings marked above are read from a configuration file but are not in this sensor's schema, so the template wizard offers no field for them — a template built entirely through the web UI gets their defaults. The web form exposes scan_name, page_size and forests.

Forest parameters

Each entry under forests describes one AD forest and inherits the global settings. Any field can be overridden at the domain level.

Parameter	Type	Required	Description
`name`	string	Yes	Forest root DNS name (e.g. `corp.example.com`). Used for labelling, and as the DNS name when a Global Catalog server is located through DNS SRV.
`skip`	boolean	No	Set `true` to keep a forest in the configuration without scanning it. Default: `false`.
`auth_type`	string	No	Authentication method: `ntlm` (default), `simple` or `anonymous`.
`username`	string	*	Service account (UPN or sAMAccountName). Required unless `auth_type` is `anonymous`.
`password`	string	*	Account password. Required unless `auth_type` is `anonymous`.
`domain`	string	No	Pre-Windows-2000 (NetBIOS) domain name. With `ntlm` it is prepended to the username (`CORP\svc_cbom`); leave blank if the username already carries the domain. Ignored by the other methods.
`use_ssl`	boolean	No	Connect over LDAPS (636, or 3269 for a Global Catalog). Default: `true`.
`verify_ssl`	boolean	No	Default: `true`. Setting `false` explicitly disables certificate checking. Note that the domain controller's certificate is only validated when `ca_cert_path` is also set.
`ca_cert_path`	string	No	Path to a PEM CA certificate or bundle on the machine running the sensor. When set, the domain controller's TLS certificate must chain to it or the connection fails.
`port`	integer	No	Default port for every controller in the forest. YAML only. `0` or omitted auto-detects.
`tls_version`	string	No	Intended to force a TLS version (`TLSv1_2` or `TLSv1_3`). Read by nothing — it is absent from the schema and never looked up in the sensor, so the connection negotiates whatever the domain controller offers. It survives only in the shipped example config.
`domains`	list	*	Domain controllers to scan; see the parameters below. A forest needs at least one entry under `domains` or `gc_servers` (the web form requires a domain controller).
`gc_servers`	list	No	Global Catalog servers, used to discover every domain controller in the forest. Each entry takes `server`, `base_dn`, `port` (`0` = auto: 3269 LDAPS / 3268 plain) and `skip`. Omit `server` to locate the Global Catalog through DNS SRV (`_ldap._tcp.gc._msdcs.<forest>`). Global Catalog entries use the forest credentials.

Domain controller parameters

Parameter	Type	Required	Description
`server`	string	*	DC hostname or IP. At least one of `server` and `base_dn` is needed; giving both is the most reliable. With `server` only, the base DN is read from the controller's rootDSE. The web form asks for both.
`base_dn`	string	*	LDAP search base (e.g. `DC=corp,DC=example,DC=com`). With `base_dn` only, the controller is located through DNS SRV (`_ldap._tcp.<domain>`); this needs the scanning host to use the AD DNS servers.
`port`	integer	No	Explicit port. `0` or omitted auto-derives 636 (LDAPS) or 389 (plain).
`auth_type`	string	No	Per-controller authentication override. Blank inherits the forest's method.
`username / password`	string	No	Per-controller credential override. Blank inherits the forest credentials.
`domain`, `ca_cert_path`	string	No	Per-controller overrides of the forest values. YAML only.
`use_ssl`, `verify_ssl`	boolean	No	Per-controller overrides of the forest values. YAML only.
`skip`	boolean	No	Exclude this controller from the scan. Default: `false`.

Use Case 1 — Single forest, simple auth, self-signed DC certificate.

Name: ADScan-Corp
ExtName: Discover_ActiveDirectory
Config:
  scan_name: "Corp-AD-Discovery"
  page_size: 500
  forests:
    - name: "corp.example.com"
      auth_type: simple
      username: "[email protected]"
      password: "<password>"
      use_ssl: true
      verify_ssl: false
      gc_servers:
        - server: "gc01.corp.example.com"
      domains:
        - server: "dc01.corp.example.com"
          base_dn: "DC=corp,DC=example,DC=com"

Use Case 2 — Multi-forest enterprise with Kerberos auth. Scan a primary forest with Kerberos authentication and a trusted partner forest with a corporate CA cert.

Name: ADScan-Enterprise
ExtName: Discover_ActiveDirectory
Config:
  scan_name: "Enterprise-AD-Discovery"
  retry_attempts: 5
  forests:
    - name: "corp.example.com"
      auth_type: kerberos
      username: "[email protected]"
      password: "<password>"
      use_ssl: true
      verify_ssl: true
      ca_cert_path: "/etc/ssl/certs/corp-root-ca.pem"
      tls_version: "TLSv1_3"
      domains:
        - server: "dc01.corp.example.com"
          base_dn: "DC=corp,DC=example,DC=com"

    - name: "partner.example.com"
      auth_type: simple
      username: "[email protected]"
      password: "<password>"
      use_ssl: true
      verify_ssl: true
      ca_cert_path: "/path/to/partner-root-ca.pem"
      domains:
        - server: "dc01.partner.example.com"
          base_dn: "DC=partner,DC=example,DC=com"

LDAP Cryptographic Material Discovery

Discover_LDAP — scans any LDAP or LDAPS directory (AD, OpenLDAP, 389 DS, etc.) for certificates, CRLs, SSH public keys, PKCS#12 bundles, and custom crypto attributes stored in standard and user-defined attributes. Also probes port 636 to capture the server's own TLS certificate.

Many organizations publish certificates and keys in a directory other than Active Directory — OpenLDAP, FreeIPA, 389 Directory Server, Oracle Internet Directory or eDirectory — so that mail clients, VPNs and Linux hosts can find them. Those copies are easy to forget and are often never renewed or removed. This sensor brings them into the inventory alongside the directory server's own TLS certificate.

Use it for any RFC-compliant LDAP directory; for an Active Directory forest the dedicated Active Directory sensor reads far more. The sensor only searches and reads; it never writes to the directory.

What it finds

Stored X.509 certificates in userCertificate, cACertificate, crossCertificatePair and userSMIMECertificate (PKCS#7), each with its public key: subject, issuer, serial number, validity dates, algorithm and key size.
Revocation status — CRLs held in certificateRevocationList, authorityRevocationList and deltaRevocationList are read first, and certificates they list are marked revoked.
PKCS#12 bundles in userPKCS12: the certificate and public key, plus a record that a private key exists. Unencrypted bundles are opened automatically; encrypted ones need a password from pkcs12_passwords.
SSH public keys in sshPublicKey (openssh-lpk schema), ipaSshPubKey (FreeIPA) and altSecurityIdentities (Samba / AD).
Custom attributes you name, with the format detected automatically (PEM, DER, base64, OpenSSH, PGP, JWK, PKCS#7, PKCS#12). Raw symmetric key bytes need the secret_key type hint.
The server's own TLS certificate, collected from port 636 even when it is self-signed.
Every naming context — when base_dn is left blank, each naming context the server advertises is scanned.
Not collected — private key values (a PKCS#12 private key is recorded as present only) and the server's LDAP configuration or access controls.

Requirements

Runs as	Both. Cloud from the discovery server, or Networked from an agent on any host that can reach the directory. Nothing is installed on the directory server.
Reaches the target over	LDAP. With `port: 0` (default) it tries LDAPS on 636, then StartTLS on 389, then plain LDAP on 389. The server-certificate phase always connects to port 636.
Credentials and permissions	A bind DN and password with read access to the subtree being scanned (simple or NTLM bind), or anonymous bind where the directory allows it. Read-only.
Platform	Not restricted — runs on Linux or Windows.
Prerequisites	Network reachability to the directory. To verify an internal CA's certificate, put the CA certificate at `ca_cert_path` on the machine running the sensor; otherwise the system trust store is used.
Required parameters	`host`, plus `username` and `password` unless `auth_method` is `anonymous`.
Setup guide	LDAP sensor setup

Connection parameters

Parameter	Type	Required	Description
`host`	string	Yes	LDAP server hostname or IP address.
`port`	integer	No	Set to `0` (default) for auto-detection: tries LDAPS/636 → StartTLS/389 → plain/389. A non-zero port is used exactly as given, with `use_ssl` choosing LDAPS or plain LDAP; StartTLS is only attempted during auto-detection.
`use_ssl`	boolean	No	Ignored when `port: 0`. With a non-zero port, `true` (default) connects with LDAPS and `false` with plain LDAP.
`verify_ssl`	boolean	No	Validate the server's TLS certificate. Default: `true`. Set `false` for self-signed lab certs.
`ca_cert_path`	string	No	Path to a PEM CA certificate or bundle used to verify the server's TLS certificate. Leave blank to use the system trust store — useful for an internal CA you do not want to import into the OS store.
`auth_method`	string	No	Authentication mechanism: `simple` (default), `anonymous` or `ntlm`.
`username`	string	*	Bind DN or username (e.g. `CN=svc-ldap,OU=ServiceAccounts,DC=corp,DC=com`); for NTLM use `DOMAIN\username`. Required unless `auth_method` is `anonymous`.
`password`	string	*	Bind password. Required unless `auth_method` is `anonymous`.
`base_dn`	string	No	Search base (e.g. `DC=corp,DC=example,DC=com`). Leave blank to scan every naming context the server advertises in its rootDSE.
`connect_timeout`	integer	No	Connection timeout in seconds. Default: `10`.
`search_timeout`	integer	No	Search timeout in seconds. Default: `30`.
`page_size`	integer	No	Entries fetched per LDAP round-trip (Simple Paged Results, RFC 2696), 100–5000 in the web form. Default: `1000`. Active Directory enforces a hard cap of 1000, so a higher value has no effect there; drop to 250–500 for a slow or throttled server.
`skip`	boolean	No	Save the configuration but leave it out of the scan. Default: `false`. Use it to park a server temporarily instead of deleting its configuration.

Optional parameters

Parameter	Type	Required	Description
`pkcs12_passwords`	list	No	Password list for encrypted PKCS#12 bundles found in the standard `userPKCS12` attribute. First match wins; unencrypted bundles are always tried first.
`custom_attributes`	list	No	Non-standard LDAP attributes to probe. Each entry has a `name` field. Encoding and type are auto-detected (PEM, DER, base64, OpenSSH, PGP, JWK). For raw symmetric key bytes, add `type: secret_key`, and optionally `algorithm` and `key_size`.
`custom_protected_attributes`	list	No	Like `custom_attributes` but with a `passwords` list for encrypted bundles.

Use Case 1 — Scan an OpenLDAP directory with custom attributes.

ExtName: Discover_LDAP
host: ldap.corp.example.com
port: 0
verify_ssl: true
auth_method: simple
username: "CN=svc-cbom,OU=ServiceAccounts,DC=corp,DC=example,DC=com"
password: "<password>"
base_dn: "DC=corp,DC=example,DC=com"
custom_attributes:
  - name: pgpKey
  - name: sshPublicKey
  - name: myAESKey
    type: secret_key
    algorithm: AES
    key_size: "256"

Use Case 2 — Scan with PKCS#12 bundle decryption.

ExtName: Discover_LDAP
host: ad.corp.example.com
verify_ssl: false
auth_method: ntlm
username: "svc-scanner"
password: "<password>"
base_dn: "DC=corp,DC=example,DC=com"
pkcs12_passwords:
  - "changeme"
  - "corp@2024"
  - ""

HashiCorp Vault Discovery

Discover_HashiCorpVault — discovers certificates from Vault PKI engines, asymmetric/symmetric keys from Transit engines, and secrets from KV stores. Supports token, AppRole, and username/password authentication. Vault Enterprise namespaces are supported.

HashiCorp Vault often acts as an internal certificate authority through its PKI engine and as an encryption-as-a-service key store through its Transit engine. Teams also commonly leave certificates and private keys in KV secrets. This sensor reads all three, so certificates Vault has issued and keys it manages appear in the inventory with their algorithms, sizes and expiry dates.

It talks to the Vault HTTP API using a token, AppRole or username/password login. A typical setup is a dedicated, read-only discovery policy and one task per Vault cluster or namespace.

What it finds

PKI engine: every certificate stored by each PKI mount. Each is fully parsed: subject, issuer, serial number, validity period, key algorithm and size, and fingerprints.
Transit engine: every key and its type. Supported types are RSA 2048/3072/4096, ECDSA P-256/P-384/P-521, Ed25519, AES-128/256-GCM, ChaCha20-Poly1305, HMAC and managed keys. Also recorded: the latest version number, whether the key is exportable, and the public key fingerprint for asymmetric keys.
KV engine: the sensor walks secrets up to five folder levels deep and recognises values that hold a PEM certificate, a public key or an unencrypted private key. It reports the certificate or key it finds (algorithm, size and public key fingerprint) with the mount, path and field it came from.
Works with Vault Enterprise namespaces.
Not collected: Transit key material is never exported. For a private key found in KV, only its public key fingerprint is kept. Other KV secrets, such as passwords and tokens, are inspected but not reported or stored.

Requirements

Runs as	Both. Runs in the cloud from the CBOM discovery server, or on a networked agent that can reach Vault.
Reaches the target over	The Vault HTTP API at `vault_url` (Vault's default port is 8200). Over HTTPS, Vault's server certificate must be trusted by the machine running the sensor. The sensor has no option to skip verification.
Credentials and permissions	A Vault token, an AppRole (role ID and secret ID), or a userpass account. The policy needs read-only access to: `sys/mounts` (unless you name the mounts explicitly); `list` on `<pki>/certs` and `read` on `<pki>/cert/`; `list` on `<transit>/keys` and `read` on `<transit>/keys/`; and for KV, `list` on the metadata paths and `read` on the data paths. The sensor reads KV secret values in order to inspect them, so grant KV access only on mounts you want scanned.
Platform	Any.
Prerequisites	Network reachability from the machine running the sensor to Vault. AppRole or userpass auth methods must be enabled in Vault if you use them.
Required parameters	`vault_url`, `auth_method`, `engines`, `schema`, plus the fields for your auth method: `token`; or `role_id` and `secret_id`; or `username` and `password`.

Parameter	Type	Required	Description
`vault_url`	string	Yes	Vault server address (e.g. `https://vault.example.com:8200`).
`namespace`	string	No	Vault Enterprise namespace. Leave empty for OSS Vault.
`auth_method`	string	Yes	Authentication type: `token`, `approle`, or `userpass`.
`token`	string	*	Vault token. Required when `auth_method: token`.
`role_id`	string	*	AppRole role ID. Required when `auth_method: approle`.
`secret_id`	string	*	AppRole secret ID. Required when `auth_method: approle`.
`username`	string	*	Vault username. Required when `auth_method: userpass`.
`password`	string	*	Vault password. Required when `auth_method: userpass`.
`engines`	list	Yes	Secret engine types to scan. Supported: `pki`, `transit`, `kv`.
`pki_mounts`	list	No	Explicit PKI mount paths (e.g. `pki`, `pki_int`). When set, these mounts are scanned and `sys/mounts` is not consulted for PKI. YAML only; not available in the Template wizard.
`transit_mounts`	list	No	Explicit Transit mount paths. Same behaviour as `pki_mounts`. YAML only.
`kv_mounts`	list	No	Explicit KV mount paths. Set this when your Vault policy does not permit listing `sys/mounts`; naming the mounts bypasses that lookup. YAML only.
`kv_version`	string	No	KV secrets engine version for the mounts in `kv_mounts`: `"1"` or `"2"`. Default: `"2"`. Ignored when `kv_mounts` is not set, because each mount's version is then read from Vault. YAML only.
`timeout`	integer	No	Vault request timeout in seconds. Default: `30`. YAML only.
`schema`	string	Yes	Output format: `cbom` or `clm`. The Template wizard always sets `cbom`.
`scan_name`	string	No	Label stored in scan metadata: 3–100 letters, digits, hyphens or underscores.

Use Case 1 — AppRole with PKI + Transit engines.

Tasks:
  - Name: VaultPKIScan
    ExtName: Discover_HashiCorpVault
    Config:
      vault_url: "https://vault.corp.example.com:8200"
      auth_method: approle
      role_id: "<role-id>"
      secret_id: "<secret-id>"
      engines:
        - pki
        - transit
      schema: cbom
      scan_name: "Vault-Prod-Scan"

Use Case 2 — Vault Enterprise with namespace, token auth.

Tasks:
  - Name: VaultEnterpriseScan
    ExtName: Discover_HashiCorpVault
    Config:
      vault_url: "https://vault-enterprise.corp.com:8200"
      namespace: "prod/team-a"
      auth_method: token
      token: "hvs.LhpAmY0voCH6PMW6z95oHd6i"
      engines:
        - pki
        - kv
      kv_mounts:
        - "secret"
      kv_version: "2"
      schema: cbom
      scan_name: "Vault-Enterprise-TeamA"

KMIP Key Management Discovery

Discover_KMIP — connects to any KMIP-compliant key server (Thales, Vormetric, IBM SKLM, nCipher, etc.) over mutual TLS and enumerates symmetric keys, asymmetric key pairs, and certificates by type and lifecycle state.

Enterprise key managers hold the keys that protect databases, storage arrays, tape libraries and virtualization platforms. Most of them speak the OASIS KMIP standard. Examples include Thales CipherTrust, IBM SKLM, Entrust KeyControl and HashiCorp Vault Enterprise's KMIP engine. One sensor can therefore list what each of these appliances manages, along with each key's lifecycle state and activation dates. Those dates are what rotation and retirement policies are measured against.

It connects as a KMIP client over mutual TLS. A typical setup is a dedicated discovery client certificate with read-only rights on the key manager.

What it finds

Symmetric keys: algorithm (AES, 3DES, DES, HMAC-SHA256/384/512) and length.
Public and private keys: algorithm (RSA, DSA, ECDSA with its curve, Ed25519, Ed448), key size and public key fingerprint.
Certificates: fully parsed (subject, issuer, serial, validity, key algorithm). Each certificate's public key is also recorded as a linked key.
For every object: its KMIP unique identifier and name, lifecycle state (Pre-Active, Active, Deactivated, Compromised), and initial, activation and deactivation dates.
Active objects only by default. Pre-Active, Deactivated and Compromised objects are added on request. Destroyed objects are never reported.
Not collected: key material. To fingerprint an object, the sensor retrieves it with a KMIP Get. A private key is reduced to its public part, and a symmetric key to a SHA-256 fingerprint. The raw key value is never stored or sent to CBOM. If the server refuses the Get, the object is still reported, identified by its unique ID.

Requirements

Runs as	Both. Runs in the cloud from the CBOM discovery server, or on a networked agent that can reach the key manager.
Reaches the target over	KMIP over TLS, port 5696 by default.
Credentials and permissions	A client certificate and private key that the KMIP server accepts for mutual TLS. Some servers also require a username and password (`auth_type: certificate_credential`). The client needs permission for Locate, Get Attributes and Get on the objects to be inventoried. No create, modify or destroy rights are needed.
Platform	Any.
Prerequisites	The CA certificate, client certificate and client key as PEM files on the machine that runs the sensor: the discovery server for a cloud task, or the target host for a networked one. The paths in the configuration are local file paths on that machine.
Required parameters	`host`, `port`, `auth_type`, `ca_cert`, `client_cert`, `client_key`, `object_types`, plus `username` and `password` when `auth_type: certificate_credential`.
Setup guide	HashiCorp Vault KMIP guide

Parameter	Type	Required	Description
`host`	string	Yes	KMIP server hostname or IP.
`port`	integer	Yes	KMIP port. The standard KMIP port is `5696`, which the Template wizard pre-fills.
`auth_type`	string	Yes	`certificate` — mutual TLS only. `certificate_credential` — mutual TLS plus username/password (for servers requiring both).
`ca_cert`	string	Yes	Path to the CA certificate that signed the KMIP server's TLS certificate, on the machine running the sensor.
`client_cert`	string	Yes	Path to the client certificate (PEM) for mutual TLS.
`client_key`	string	Yes	Path to the client private key (PEM) for mutual TLS.
`username`	string	*	Required when `auth_type: certificate_credential`.
`password`	string	*	Required when `auth_type: certificate_credential`.
`object_types`	list	Yes	KMIP object types to retrieve. Options: `SymmetricKey`, `PublicKey`, `PrivateKey`, `Certificate`.
`include_inactive`	boolean	No	Include Pre-Active, Deactivated, and Compromised objects. Destroyed objects are never returned. Default: `false`.
`batch_size`	integer	No	Objects per Locate request (pagination). Default: `100`.
`schema`	string	No	Output format: `cbom` or `clm`. Default: `cbom`.
`scan_name`	string	No	Label stored in scan metadata. Default: `KMIP Discovery`.

Use Case 1 — Scan a Thales KMS for active keys only.

ExtName: Discover_KMIP
host: "thales-kms.corp.example.com"
port: 5696
auth_type: certificate
ca_cert: "/etc/pki/tls/certs/thales-ca.pem"
client_cert: "/etc/pki/tls/certs/cbom-client.pem"
client_key: "/etc/pki/tls/private/cbom-client.key"
object_types:
  - SymmetricKey
  - Certificate
include_inactive: false
batch_size: 200
schema: cbom
scan_name: "Thales-KMS-Production"

Use Case 2 — Full lifecycle audit including deactivated keys. Useful for compliance audits that require visibility into all key states.

ExtName: Discover_KMIP
host: "kmip.example.com"
port: 5696
auth_type: certificate_credential
ca_cert: "/path/to/ca.pem"
client_cert: "/path/to/client-cert.pem"
client_key: "/path/to/client-key.pem"
username: "discovery_user"
password: "s3cr3t!"
object_types:
  - SymmetricKey
  - PublicKey
  - PrivateKey
  - Certificate
include_inactive: true
schema: cbom
scan_name: "KMIP-Full-Audit"

PKCS#11 HSM / Token Discovery

Discover_PKCS11 — connects to a PKCS#11-compatible hardware security module (HSM) or software token via its native library and enumerates cryptographic objects (certificates, public keys, private keys, and symmetric keys) stored on the token.

Hardware security modules guard the most valuable keys an organization has: CA signing keys, code-signing keys, payment and database master keys. They are also the hardest to see into. Almost every HSM and smart-card token ships a PKCS#11 library, including Thales Luna, Entrust nShield, SafeNet, YubiKey and SoftHSM. This sensor loads that library and lists what a partition or token holds, so the keys and certificates in your HSMs are inventoried and policy-checked like any others.

It runs on a host where the vendor's HSM client is already installed and configured, and logs in with a partition or token PIN. A typical setup is the HSM client host with a dedicated, read-only crypto-user credential.

What it finds

Certificates stored on the token. Each is fully parsed: subject, issuer, serial number, validity period, key algorithm and size, key usage, and fingerprints.
Public keys: algorithm (RSA, DSA, EC), RSA key size, and a public key fingerprint calculated from the RSA modulus or the EC point and curve.
Private keys: algorithm and RSA key size, recorded as HSM-protected keys.
Each object's label (CKA_LABEL) and ID (CKA_ID), plus the token manufacturer, PKCS#11 library and host.
Not collected: private and secret key values are never exported.

Requirements

Runs as	A networked agent on the HSM client host. It is not available as a cloud task. It can also be run off-grid on an isolated HSM client host, with the results imported afterwards.
Reaches the target over	The local PKCS#11 library. Any network connection to a network HSM (for example Luna NTLS or the nShield hardserver) is made by the vendor client, not by the sensor.
Credentials and permissions	The token or partition PIN. The sensor logs in as a normal user (`CKU_USER`). Use a credential that can read objects but not create or delete them. If the PIN is left empty, no login is attempted and only public objects are visible.
Platform	Windows or Linux: wherever the vendor's PKCS#11 library (`.dll` / `.so`) is installed. Automatic library detection covers nCipher (Windows) and SoftHSM (Windows and Linux). For other vendors, give the path explicitly.
Prerequisites	The HSM vendor client installed and configured on the host, with the token or partition visible to it (slot present). The PKCS#11 Python bindings are included in the agent.
Required parameters	`library_path`, `slot`, `pin` (the key must be present, even if empty).
Setup guide	Thales Luna HSM guide, Entrust nShield HSM guide

Parameter	Type	Required	Description
`library_path`	list	Yes	One or more paths to the PKCS#11 shared library (`.dll` / `.so`). The first path that exists is used. An entry of `Auto` tries vendor-based detection at that point in the list; detection is available for nCipher and SoftHSM.
`vendor`	string	No	Vendor hint used only by `Auto` library detection (e.g. `nCipher`, `SoftHSM`).
`slot`	integer	Yes	Position of the token in the list of slots that have a token present, starting at `0`. This is not the PKCS#11 slot ID.
`pin`	string	Yes	Token PIN or partition password. The sensor logs in as a normal user (`CKU_USER`). Leave empty to skip login; only public objects are then visible.
`object_types`	list	No	PKCS#11 object classes to retrieve: `1` = Certificate, `2` = Public Key, `3` = Private Key. Default: `[1, 2, 3]`.

Use Case 1 — nCipher HSM.

ExtName: Discover_PKCS11
vendor: nCipher
library_path:
  - Auto
  - C:\Program Files\nCipher\nfast\toolkits\pkcs11\cknfast.dll
slot: 0
pin: "<token-pin>"
login_type: user
object_types: [2, 3, 5]

Use Case 2 — SoftHSM2 on Linux.

ExtName: Discover_PKCS11
vendor: SoftHSM2
library_path:
  - /usr/lib/softhsm/libsofthsm2.so
  - /usr/local/lib/softhsm/libsofthsm2.so
slot: 0
pin: "1234"
login_type: user
object_types: [2, 3, 4, 5]

GPG Keyring Discovery

Discover_GPGKeyrings — walks specified directories to discover GnuPG public and secret keyrings (pubring.kbx, pubring.gpg, secring.gpg) and imports key metadata without requiring an unlocked GPG agent.

OpenPGP keys sign software releases, package repositories, backups and commits, and encrypt files exchanged with partners. They usually live in per-user GnuPG directories that no central system tracks. This sensor finds where that material sits on a host, so you know which servers, build agents and user accounts hold signing or encryption keys that need an owner and a review.

It is a location finder. It records where keyrings and key files are, without opening them. A typical use is to run it on build servers, CI/CD runners and shared jump hosts.

What it finds

GnuPG keyring files: pubring.kbx, secring.gpg and trustdb.gpg.
Any file ending in .gpg, .key or .rev, including legacy pubring.gpg keyrings and revocation certificates.
GnuPG key directories: private-keys-v1.d and openpgp-revocs.d.
For each one: its full path, the scan root it was found under, the host, and whether it looks like secret or public material, judged from its file or folder name.
Not collected: the sensor does not open or parse keyrings. It reports no key IDs, user IDs, algorithms, key sizes or expiry dates, and it never reads private key contents. GnuPG and an unlocked agent are not needed.

Requirements

Runs as	A networked agent on the host being scanned. It is not available as a cloud task. It can also be run off-grid, with the results imported afterwards.
Reaches the target over	Local file system access only.
Credentials and permissions	Read access to the directories being searched. To cover every user's home directory, the agent must run as `root` or Administrator; folders it cannot read are skipped.
Platform	Linux, Windows and macOS.
Prerequisites	None. GnuPG does not need to be installed.
Required parameters	`directories`.

Parameter	Type	Required	Description
`directories`	list	No	Directories to search recursively for GnuPG keyrings and key files (e.g. `/home/<user>`, `/root`, `/var/lib/jenkins`; on Windows `%APPDATA%\gnupg`). Directories that do not exist are skipped. If omitted, the sensor searches every user home directory plus `/root` on Linux, every user under `/Users` on macOS, and every drive on Windows.

Use Case 1 — Scan all user home directories on a Linux server.

ExtName: Discover_GPGKeyrings
directories:
  - /home
  - /root

Use Case 2 — Scan mounted shares and CI/CD agent homes.

ExtName: Discover_GPGKeyrings
directories:
  - /home
  - /mnt/nas-share
  - /var/lib/jenkins
  - /var/lib/gitlab-runner

SQL Server TDE Key Discovery

Discover_TDEKeys_MSSQL — queries SQL Server system views to discover Transparent Data Encryption (TDE) database encryption keys, their algorithm, key length, encryption state, and the certificates or asymmetric keys protecting them.

Transparent Data Encryption protects SQL Server database files at rest with a database encryption key, which is in turn protected by a certificate held in the master database. Those keys sit inside the database engine rather than on disk or in a key vault, so they are easy to miss in a cryptographic inventory. This sensor brings each TDE key into the inventory with the algorithm it uses and the certificate that protects it, so it is scored, policy-checked and tracked over time like any other key.

Typical use: one configuration per SQL Server instance that runs TDE, using a read-only login created for CBOM.

What it finds

One key record for each database that has a TDE database encryption key, with its algorithm and key length (for example AES 256).
The encryption state: the key is reported Active when the database is fully encrypted, and Inactive for every other state (encryption or decryption in progress, or a key with no encryption).
The protecting certificate’s name, thumbprint and expiry date, recorded on the key record.
The database name and the SQL Server instance it came from.

It does not collect:

Key material. Nothing is exported from the database.
Details of a key protected by an asymmetric key or an EKM/HSM provider. The protector is looked up only among certificates in master, so for any other protector the certificate fields read N/A.
Always Encrypted column keys, backup encryption, or the service and database master keys.
A separate certificate record for the TDE certificate. Its details appear only as properties of the key.

Requirements

Runs as	Both. As a Cloud sensor from the discovery server, or from a Networked agent on any host that can reach the SQL Server. Nothing is installed on the database server.
Reaches the target over	The SQL Server network protocol through ODBC, default TCP port `1433`. A named instance (`HOST\INSTANCE`) is found through the SQL Server Browser service (UDP `1434`). Enter the server as a host name or `HOST\INSTANCE`, without a port.
Credentials and permissions	A SQL Server authentication login (username and password; Windows integrated authentication is not used). The sensor connects to `master` and reads `sys.dm_database_encryption_keys`, `sys.databases` and `sys.certificates`, which needs `VIEW SERVER STATE` and permission to see the TDE certificates. The setup guide lists the exact grants.
Platform	Any platform the agent or discovery server runs on.
Prerequisites	Microsoft ODBC Driver 17 for SQL Server installed on the machine that runs the sensor (on Linux, with unixODBC). The driver is not bundled with the agent, and the Template form has no field to choose a different driver.
Required parameters	`server`, `username`, `password`, `target_db`.
Setup guide	Microsoft SQL Server Setup Guide for CBOM Database TDE Sensor

Parameter	Type	Required	Description
`server`	string	Yes	SQL Server host, optionally with an instance name (e.g. `SQLSERVER01\INSTANCE` or `192.168.1.50`). Letters, digits, dots, hyphens and underscores; no port suffix.
`username`	string	Yes	SQL Server authentication login (1–128 characters). See the setup guide for the required permissions.
`password`	string	Yes	Login password (up to 128 characters).
`target_db`	string	Yes	Report only the database with this name (case-insensitive exact match).
`config_name`	string	No	Label for this scan configuration (3–100 letters, digits, hyphens or underscores).
`driver`	string	No	ODBC driver string. Default: `{ODBC Driver 17 for SQL Server}`. Set in a hand-written task file.

Use Case 1 — Scan all TDE-protected databases on an instance.

ExtName: Discover_TDEKeys_MSSQL
config_name: "prod-mssql-scan"
server: "SQLPROD01\MSSQLSERVER"
username: "cbom_scanner"
password: "<password>"

Use Case 2 — Target a specific database.

ExtName: Discover_TDEKeys_MSSQL
config_name: "finance-db-tde"
server: "192.168.10.50"
username: "cbom_scanner"
password: "<password>"
target_db: "FinanceDB"

MySQL / InnoDB TDE Key Discovery

Discover_TDEKeys_MySQL — queries information_schema.INNODB_TABLESPACES_ENCRYPTION to enumerate tablespace encryption keys, keyring IDs, encryption schemes, and key versions across InnoDB tablespaces.

InnoDB data-at-rest encryption protects tablespace files with keys held by the server’s keyring or key-management plugin. Which tablespaces are encrypted, and under which key and key version, is visible only from inside the database. This sensor reads that information so encrypted MySQL-compatible databases appear in the inventory next to your other encryption keys, and so unrotated key versions can be spotted.

Typical use: one configuration per database server, using a read-only account created for CBOM.

What it finds

One key record for each row of information_schema.INNODB_TABLESPACES_ENCRYPTION, reported as a secret key.
For each: the tablespace name, keyring (key) identifier, encryption scheme, encryption version and minimum key version.
The database server the record came from.

It does not collect:

Key material, or the keyring plugin’s configuration.
A key size. The algorithm field carries the encryption scheme value reported by the server, not a cipher name and length.
Redo log, undo log or binary log encryption settings, or the server’s TLS certificates.

Requirements

Runs as	Both. As a Cloud sensor from the discovery server, or from a Networked agent on any host that can reach the database. Nothing is installed on the database server.
Reaches the target over	The MySQL client protocol, TCP port `3306`. The Template form has no port field, so a template built in the UI always uses 3306.
Credentials and permissions	A database account (username and password) that can read `information_schema.INNODB_TABLESPACES_ENCRYPTION`, which requires the `PROCESS` privilege.
Platform	Any platform the agent or discovery server runs on. The database server must expose `information_schema.INNODB_TABLESPACES_ENCRYPTION`.
Prerequisites	None on the scanning machine; the MySQL Connector/Python driver is bundled with the agent.
Required parameters	`server`, `username`, `password`, `target_db`.

Parameter	Type	Required	Description
`server`	string	Yes	Database host name or IP address. Do not append a port; use `port`.
`port`	integer	No	Database port. Default: `3306`. Set in a hand-written task file.
`username`	string	Yes	Database account with the `PROCESS` privilege (1–32 characters).
`password`	string	Yes	Account password (up to 256 characters).
`target_db`	string	Yes	Report only tablespaces whose name contains this text (case-insensitive).
`config_name`	string	No	Label for this scan configuration (3–100 letters, digits, hyphens or underscores).

Use Case 1 — Scan all encrypted tablespaces.

ExtName: Discover_TDEKeys_MySQL
config_name: "mysql-prod-tde"
server: "mysql-prod.corp.example.com"
username: "cbom_scanner"
password: "<password>"

Use Case 2 — Non-standard port, filtered by database.

ExtName: Discover_TDEKeys_MySQL
config_name: "app-db-scan"
server: "192.168.5.20"
port: 3307
username: "cbom_scanner"
password: "<password>"
target_db: "app_production"

Oracle TDE Key Discovery

Discover_TDEKeys_Oracle — connects to an Oracle database via its JDBC/Python driver and queries multiple TDE-related system views: active DB encryption key info, wallet status, encrypted tablespaces, and column-level encryption details.

Oracle Transparent Data Encryption encrypts whole tablespaces or individual columns, with every key protected by a master encryption key held in a keystore (wallet). An inventory that stops at certificates and key vaults does not see these keys, or whether the keystore is open, or that a sensitive column is still encrypted with an older algorithm. This sensor reports all of that from the database’s own TDE views.

Typical use: one configuration per Oracle service, using a read-only account with access to the data dictionary.

What it finds

The database master encryption key: its algorithm, master key ID and whether it has been activated (V$DATABASE_KEY_INFO).
The keystore (wallet) location and status, for example OPEN or CLOSED (V$ENCRYPTION_WALLET).
Encrypted tablespaces: name, encryption algorithm and master key ID (V$ENCRYPTED_TABLESPACES).
Encrypted columns: owner, table, column, encryption algorithm, integrity algorithm and whether salt is used (DBA_ENCRYPTED_COLUMNS).

Each item is reported as a key record. The four queries run independently: if the account cannot read one view, that part is skipped with a warning and the rest is still reported.

It does not collect:

Key material, wallet contents or the wallet password.
A separate key length; where Oracle includes it in the algorithm name, it appears there.

Requirements

Runs as	Both. As a Cloud sensor from the discovery server, or from a Networked agent on any host that can reach the database listener. Nothing is installed on the database server.
Reaches the target over	Oracle Net to the listener, default TCP port `1521`, connecting by service name.
Credentials and permissions	A database account with `CREATE SESSION` and `SELECT` on `V$DATABASE_KEY_INFO`, `V$ENCRYPTION_WALLET`, `V$ENCRYPTED_TABLESPACES`, `SYS.TS$` and `DBA_ENCRYPTED_COLUMNS`. `SELECT ANY DICTIONARY` covers all five.
Platform	Any platform the agent or discovery server runs on.
Prerequisites	None on the scanning machine. The sensor uses the bundled python-oracledb driver in Thin mode, so no Oracle Client or Instant Client is needed.
Required parameters	`server`, `username`, `password`, `service_name`, `port`, `target_db`.

Parameter	Type	Required	Description
`server`	string	Yes	Oracle database host (hostname or IP).
`port`	integer	Yes	Listener port. Default: `1521`.
`username`	string	Yes	Database account (1–30 letters, digits, `_`, `#` or `$`) with `SELECT` on the views listed under Requirements.
`password`	string	Yes	Account password (up to 256 characters).
`service_name`	string	Yes	Oracle service name (e.g. `ORCLPDB1`). A SID is accepted only if it is also a registered service name.
`target_db`	string	Yes	Name of the database being scanned.
`config_name`	string	No	Label for this scan configuration (3–100 letters, digits, hyphens or underscores).

Use Case 1 — Scan an Oracle 19c PDB.

ExtName: Discover_TDEKeys_Oracle
server: oracle-prod.corp.example.com
port: 1521
username: "cbom_dba"
password: "<password>"
service_name: ORCLPDB1
config_name: "oracle-prod-scan"

Use Case 2 — Multi-tenant CDB, target specific PDB.

ExtName: Discover_TDEKeys_Oracle
server: 192.168.1.100
port: 1521
username: "c##cbom_scanner"
password: "<password>"
service_name: ORCL
target_db: "FINPDB"
config_name: "oracle-fin-scan"

HTTPS / TLS Endpoint Discovery

Discover_HTTPS — performs TLS handshakes against a list of hosts, capturing the server's presented certificate chain and negotiated cipher suites. Supports TLS 1.2 and 1.3 cipher suite probing and IPv6 hosts.

Every HTTPS service presents a certificate and accepts some set of protocol versions and cipher suites. Weak settings — TLS 1.0, RC4 or 3DES suites, an expired or self-signed certificate — are among the most common findings in a crypto inventory, and they are visible from the network without touching the server. Use this sensor to inventory web servers, APIs, load balancers and any other TLS listener by host name or IP address and port.

The scan is a series of ordinary TLS handshakes; nothing is installed on the target and no credentials are needed.

What it finds

The server certificate — subject, issuer, serial number, validity dates, key algorithm and size, signature algorithm, and whether it is self-signed or already expired.
Accepted cipher suites — each suite the server agreed to, with its protocol version (SSLv3 to TLS 1.2, as far as the scanning host's OpenSSL can still offer them) and key strength, found by offering the suites one at a time.
TLS 1.3 suites — the three standard TLS 1.3 cipher suites are probed separately.
Not collected — intermediate and root certificates in the chain (only the server's own certificate is recorded), certificate trust or hostname validation results, client-certificate requirements, and HTTP-level settings such as HSTS.

Requirements

Runs as	Both. Cloud from the discovery server, or Networked from an agent — useful for listeners that are only reachable from inside a network segment.
Reaches the target over	TLS over TCP to each listed `host:port`; port 443 by default. One connection is made per cipher suite tested.
Credentials and permissions	None.
Platform	Not restricted. Which legacy protocols and suites can be tested depends on the OpenSSL build of the host running the sensor: a suite that build cannot offer is never tested.
Prerequisites	Network reachability to each host and port. The scan makes many short connections per host, which an intrusion detection system or rate limiter may notice.
Required parameters	`Hosts`.

Parameter	Type	Required	Description
`Hosts`	list	Yes	List of hosts to probe in `host:port` format. IPv6 addresses must use bracket notation: `[::1]:443`. Port defaults to `443` if omitted. Note the capital H.
`CipherSuite`	string	No	Shown in the web form (`ALL`, `HIGH`, `DEFAULT`, `TLSv1.2`, `TLSv1.3`; default `ALL`).
`timeout_seconds`	integer	No	Per-connection timeout in seconds. Default: `10`.

Use Case 1 — Scan internal and external web endpoints.

ExtName: Discover_HTTPS
Hosts:
  - intranet.corp.example.com:443
  - api.corp.example.com:8443
  - www.encryptionconsulting.com
CipherSuite: "ALL"
timeout_seconds: 15

Use Case 2 — Probe specific cipher suite support. Limit the offered cipher suites to check whether a server still accepts weak ciphers.

ExtName: Discover_HTTPS
Hosts:
  - legacy-app.corp.example.com:443
CipherSuite: "AES128-SHA:DES-CBC3-SHA:RC4-SHA"
timeout_seconds: 10

SSH Server Discovery

Discover_SSH — probes SSH servers over the network in four phases: the version banner, the algorithm lists the server offers, the host key it presents, the authentication methods it accepts, and finally what an authenticated session negotiates. Nothing is installed on the target.

SSH is how most servers, network devices and Git hosts are administered, and its configuration decides which key-exchange, cipher and MAC algorithms protect that access. Legacy algorithms such as diffie-hellman-group1-sha1, CBC ciphers or ssh-rsa host keys linger for years on older systems. This sensor inventories what each SSH server offers and the host keys it uses, so weak or non-quantum-safe configurations can be found and tracked fleet-wide.

What it finds

Server identity — the version banner, the SSH software and version it reports, and the protocol version.
Offered algorithms — the server's key-exchange, host-key, cipher and MAC algorithm lists.
Host keys — one per key family the server offers (RSA, ECDSA, Ed25519 and so on), each with its algorithm and size.
Host certificates — where the server uses an OpenSSH certificate authority, the host certificate's serial number, validity, principals, signing CA key and extensions.
Authentication methods (needs a username) — which methods the server accepts, and whether it allows login with no authentication at all. No password is sent for this check.
Session behaviour (needs a username and credential) — whether the server honours a re-key request and allows agent, X11 and TCP forwarding.
Not collected — nothing is read from the server's filesystem: user keys, authorized_keys and the sshd_config file itself are out of scope (use the file system sensor through an agent for those).

Requirements

Runs as	Both. Cloud from the discovery server, or Networked from an agent — useful for SSH servers that are only reachable from inside a network segment.
Reaches the target over	SSH over TCP, port 22 by default. Host keys are collected over one short connection per key family.
Credentials and permissions	None for the banner, algorithm and host key checks. A username adds the authentication methods check; a password or an unencrypted PEM private key as well adds the session checks. Any ordinary account is enough — no privileges are needed.
Platform	Not restricted — runs on Linux or Windows, against any SSH-2 server.
Prerequisites	Network reachability to each host and port. The plain `host:port` spelling cannot express an IPv6 address; use a host name instead.
Required parameters	`Hosts`.

How far a scan gets depends on what you give it. With hosts alone it runs phases 1 and 2 — banner, algorithm lists and host key, which is everything an unauthenticated prober can see. Adding a username enables phase 3, the authentication methods probe. Adding a credential as well enables phase 4, the session checks.

Parameter	Type	Required	Description
`Hosts`	list	Yes	One entry per SSH server. Two spellings are accepted and can be mixed in one list — see below. Note the capital H.
`timeout_seconds`	integer	No	TCP connect and read timeout per host, 1–120. Default: `10`.
`username`	string	No	Default username, used by any host that does not name its own. Setting it enables phase 3.
`credential`	string	No	Default password or PEM private key, used by any host that does not carry its own. Setting it together with a username enables phase 4. The form is auto-detected: a value starting `-----BEGIN` is treated as a private key, anything else as a password.

Two spellings for a host

A plain host or host:port string is what the web form produces, and the port defaults to 22. Only the object spelling can carry per-host overrides — its own username and credential, or skip: true to leave a host out without removing it from the list.

Use Case 1 — Fleet scan with one shared credential. The simple case, and what the web form builds.

ExtName: Discover_SSH
Hosts:
  - "192.168.1.10"
  - "192.168.1.11"
  - "git.internal:2222"
timeout_seconds: 10
username: "scanner"
credential: "<password>"

Use Case 2 — Mixed estate: per-host credentials, a key-authenticated host, and an unauthenticated DMZ probe.

ExtName: Discover_SSH
Hosts:
  # Uses the global defaults at the bottom
  - host: "192.168.1.10"
    port: 22

  # Its own credentials
  - host: "192.168.1.11"
    port: 22
    username: "root"
    credential: "<other-password>"

  # Private key auth
  - host: "git.internal"
    port: 2222
    username: "git"
    credential: |
      -----BEGIN OPENSSH PRIVATE KEY-----
      b3BlbnNzaC1rZXktdjEAAAAA...
      -----END OPENSSH PRIVATE KEY-----

  # No credentials anywhere -- phases 1 and 2 only
  - host: "untrusted.dmz.local"
    port: 22

  # Parked
  - host: "old-server.internal"
    port: 22
    skip: true

timeout_seconds: 10
username: "scanner"
credential: "<fleet-password>"

File System Cryptographic Material Discovery

Discover_Files — recursively walks configured filesystem paths looking for PEM, DER, JKS, PKCS#12, PGP, and other cryptographic file types. Extracts certificate chains, public/private keys, and keystores.

Much of an organisation’s cryptographic material lives in plain files: web server certificates and keys, CA bundles and trust stores, application key files and SSH keys. These are copied between servers, forgotten, and left in place long after they expire. This sensor walks the folders you name on the host where the agent runs and reports every certificate and key it can parse, with its location, so file-based material can be found, rated and renewed.

Typical use: system trust stores and certificate folders such as /etc/ssl, /etc/pki or C:\ProgramData, plus the configuration directories of web servers and applications. Files are recognised by their content, not their extension.

What it finds

X.509 certificates in PEM or DER encoding, whatever the file is called (.pem, .crt, .cer, .der …).
PEM certificate blocks embedded in other text files, such as configuration files.
PEM-encoded PKCS#7 certificate bundles.
PKCS#12 / PFX files that are not password-protected: the certificate, its private key and any additional certificates.
Unencrypted PEM private keys (RSA, EC, DSA, Ed25519, Ed448) and PEM public keys.
OpenSSH private keys. A passphrase-protected key is reported as found, without algorithm details.
Certificate signing requests, recorded as a note with the request’s subject.
Executables (Windows PE, Linux ELF, macOS Mach-O), when Discover_Binary is not in the same task: a light record with the file hash and any crypto markers found, plus the code signature of Windows executables (Authenticode) and of Linux executables with a detached .sig / .asc GPG signature, including the signing certificate.

Private keys are reported by algorithm, size and public-key hash; the key material itself is not sent to CBOM.

It does not collect:

PGP keys. Use the GPG sensor for PGP keyrings.
DER-encoded private or public keys, or DER-encoded PKCS#7 bundles.
Files larger than max_file_size, files the agent’s account cannot read, or anything reached only through a symbolic link to a directory.

Requirements

Runs as	Networked agent on the target host, or an Off-Grid bundle. Not available as a Cloud sensor.
Reaches the target over	The local file system of the host the agent runs on.
Credentials and permissions	Read access, for the account the agent runs as, to every folder and file in `paths`. Files it cannot open are skipped, so private keys readable only by `root` or Administrators are missed under a less privileged account.
Platform	Linux, macOS and Windows. `/proc`, `/sys`, `/dev` and `/run/user` are always skipped on Linux, and `/dev` and `/private/var/vm` on macOS.
Prerequisites	None beyond the agent. Checking detached GPG signatures on Linux executables needs `gpg` on the `PATH`.
Required parameters	`paths` (at least one), `max_file_size`.
Setup guide	Linux System Trust Store Setup Guide for CBOM Files Sensor

Parameter	Type	Required	Description
`paths`	list	Yes	One or more directories to scan (e.g. `/etc` or `C:\ProgramData`). Paths that do not exist are skipped with a warning.
`recursive`	boolean	No	Recurse into subdirectories. Default: `true`. Symbolic links to directories are not followed.
`max_file_size`	integer	Yes	Files larger than this many bytes are skipped. Default: `10485760` (10 MB).
`exclude_paths`	list	No	Paths to skip, together with everything below them (e.g. `/var/log`, `/tmp`). Added to the platform’s built-in exclusions. Must sit inside the `Config:` block in a task file.
`config_name`	string	No	Label recorded in every result under `scanProperties.config`. Form default: `FileDiscovery_Default`.
`manifest_path`	string	No	Where to write the list of executables found during the scan.

Use Case 1 — Scan common certificate store paths on Linux.

ExtName: Discover_Files
Config:
  config_name: "linux-certs-scan"
  paths:
    - /etc/ssl
    - /etc/pki
    - /opt/apps
  recursive: true
  max_file_size: 10485760
exclude_paths:
  - /etc/ssl/certs/ca-certificates.crt
  - /tmp
  - /var/log

Use Case 2 — Scan Windows certificate folders.

ExtName: Discover_Files
Config:
  config_name: "windows-certs-scan"
  paths:
    - C:\ProgramData\certificates
    - C:\inetpub
    - C:\Program Files\Apache
  recursive: true
  max_file_size: 52428800

Binary / Executable Cryptographic Library Detection

Applications carry their own cryptography in the libraries they link or bundle. An outdated OpenSSL shipped inside a vendor product, or an in-house tool calling Windows CNG, never shows up in a certificate or key scan. This sensor inspects the executables and libraries on the host where the agent runs, identifies the cryptographic libraries they use and, where it can, their versions and code signatures. That gives you the application layer of the inventory: which software depends on which crypto library, for vulnerability tracking and post-quantum migration planning.

Typical use: application install directories such as C:\Program Files, /opt or /usr/lib, run alongside the Files sensor on the same host.

What it finds

Windows PE files (.exe, .dll, .sys …) and Linux ELF files (executables and .so libraries), recognised by file header rather than extension.
Built-in detection of OpenSSL, BoringSSL, AWS-LC, libsodium, GnuPG, OpenSSH, Windows CNG (bcrypt.dll / ncrypt.dll) and Windows CryptoAPI (crypt32.dll), plus generic AES / RSA / SHA256 strings. Evidence comes from imported libraries, imported and exported symbols, embedded strings and the file name, combined into a confidence score. You can add your own signatures.
Library version strings for OpenSSL, OpenSSH, GnuPG, BoringSSL and AWS-LC; on Windows, the file’s version resource.
Known vulnerabilities for a detected library version, when you supply CVE data in cve_db.
Code signatures: Authenticode on Windows files (signed, verified and signer); on Linux, a detached .sig / .asc GPG signature or the RPM or Debian package signature. The signing certificate and its chain are reported as certificate records, linked to the binary by a signature record.
A rough application category (web server, database, browser, VPN …) from the file name.

It does not collect:

Java archives and class files, scripts, or source code. Use the Source Code sensor for code.
Certificates and keys stored as files. Use the Files sensor.

Requirements

Runs as	Networked agent on the target host, or an Off-Grid bundle. Not available as a Cloud sensor.
Reaches the target over	The local file system of the host the agent runs on.
Credentials and permissions	Read access, for the account the agent runs as, to the files under `paths`.
Platform	Windows and Linux.
Prerequisites	Windows: nothing beyond the agent (PE parsing and Authenticode checking are bundled; PowerShell is used as a fallback). Linux: `readelf` (binutils) on the `PATH` — without it, imported libraries and symbols cannot be read and only string and file-name signatures match. `gpg`, and `rpm` or `dpkg` / `debsig-verify`, are needed for the corresponding signature checks.
Required parameters	`paths` (at least one).

Discover_Binary — scans compiled executables and libraries (EXE, DLL, SYS, ELF, SO, DYLIB) to detect embedded cryptographic libraries via dependency analysis, symbol inspection, and string pattern matching. Optionally extracts version strings and correlates with known CVEs.

Parameter	Type	Required	Description
`paths`	list	Yes	Directories to scan for binary files. Walked recursively; every file is checked for a PE or ELF header, so there is no pattern filter to configure.
`config_name`	string	No	Label for this scan configuration. Form default: `BinaryDiscovery_Default`.
`crypto_signature_file`	string	No	Path, on the scanned host, to a JSON signature file with a top-level `signatures` key, merged over the built-in signatures by `id`. The file must exist: a path that cannot be found stops this configuration from producing any results.
`additional_signatures`	list	No	Inline signatures merged over the built-in set by `id`. Each entry requires `id`, `type` (`dependency` \| `symbol` \| `string` \| `filename`), a non-empty `patterns` list and `family`; `weight` (0–1) is optional, default `0.5`. An invalid entry, or a value that is not a list, rejects the whole configuration.
`cve_db`	map	No	Inline CVE data, keyed `family` → `version` → list of vulnerabilities. Omit it and version strings are still extracted, but nothing is correlated. Set in a hand-written task file.

Detection is not configurable. Dependency, symbol and string analysis all run on every scan, as does version-string extraction — there are no detection, version_extraction, performance or logging sections to set.

Use Case 1 — Scan Windows System32 for outdated crypto libraries.

ExtName: Discover_Binary
config_name: windows_system_scan
paths:
  - C:\Windows\System32
  - C:\Program Files

Use Case 2 — Linux scan with CVE lookup and custom signature.

ExtName: Discover_Binary
config_name: linux_apps_scan
paths:
  - /usr/bin
  - /usr/lib
  - /opt/apps
additional_signatures:
  - id: internal_crypto
    type: string
    patterns:
      - ACME-CryptoLib
    family: "ACME Internal Crypto"
    weight: 0.85
cve_db:
  "ACME Internal Crypto":
    "1.2.3":
      - id: CVE-2026-0001
        severity: HIGH

Windows Certificate Store Discovery

Discover_WinCerts — reads the Windows certificate stores (Personal, Root, CA, TrustedPublisher, AuthRoot, TrustedPeople, Machine) via the Windows CryptoAPI and optionally scans ADFS Token Signing / Decrypting certificates via PowerShell. Supports filtering by thumbprint, issuer, and subject. Can load a PFX file to supply a private key for decryption.

On Windows, most certificates are not files: they live in the system certificate stores, where IIS, Remote Desktop, client authentication and code-signing trust all find them, and where the trusted root and intermediate CAs are kept. A file scan does not see them. This sensor reads those stores on the machine where the agent runs, so every certificate a Windows host trusts or presents is in the inventory with its store, thumbprint and validity.

Typical use: Windows servers and workstations, filtered by issuer to focus on your own or your public CAs. On an AD FS server it can also collect the federation service’s token-signing and token-decrypting certificates.

What it finds

Certificates in the Personal (MY), Trusted Root (ROOT), Intermediate (CA), TrustedPublisher, AuthRoot and TrustedPeople stores, each with its store name, SHA-1 thumbprint, subject, issuer and full certificate details.
The stores are opened as the system stores of the Windows account the agent runs as.
With scan_adfs: the certificates returned by Get-AdfsCertificate (token-signing, token-decrypting and service-communication), each with a public-key record and a private-key record that notes the key exists.

It does not collect:

Private keys from the stores; nothing is exported. The AD FS private-key record states only that the key exists.
Certificates in stores not listed above (for example Remote Desktop or WebHosting), or in other users’ stores.
Certificate files on disk. Use the Files sensor.

Requirements

Runs as	Networked agent on the Windows host, or an Off-Grid bundle. Not available as a Cloud sensor.
Reaches the target over	The local Windows CryptoAPI certificate stores. For AD FS, a local PowerShell call to `Get-AdfsCertificate`; no WinRM or remote connection.
Credentials and permissions	The account the agent runs as must be able to open the certificate stores. For AD FS, the account must be permitted to run `Get-AdfsCertificate` on that server.
Platform	Windows only.
Prerequisites	None beyond the agent (`wincertstore` and `oscrypto` are bundled). For AD FS, the AD FS PowerShell module: run on the AD FS server, or on a host with RSAT-ADFS installed.
Required parameters	None. Every parameter is an optional filter or switch.
Setup guide	Windows Certificate Stores Setup Guide for CBOM WinCerts Sensor

Parameter	Type	Required	Description
`thumbprint`	string	No	Filter: return only the certificate with this SHA-1 thumbprint — 40 hex characters, with or without colons between byte pairs.
`target_issuers`	list	No	Filter: return only certificates whose issuer name contains one of these strings (case-insensitive). E.g. `DigiCert`, `Microsoft`.
`subject_match`	string	No	Filter: return only certificates whose subject contains this text (case-insensitive). Set in a hand-written task file.
`pfx_path`	string	No	Path to a `.pfx` / `.p12` file on the scanned host.
`pfx_passphrase`	string	No	Passphrase for `pfx_path`.
`scan_adfs`	boolean	No	Also collect AD FS certificates by running `Get-AdfsCertificate` locally. The sensor must run on the AD FS server or a host with RSAT-ADFS. Default: `false`.
`adfs_ps_timeout`	integer	No	Timeout in seconds for the AD FS PowerShell call (5–120 on the form). Default: `30`.
`config_name`	string	No	Label for this scan configuration (3–100 letters, digits, hyphens or underscores).

Platform requirement: this sensor runs on Windows only. It requires the wincertstore and oscrypto Python packages.

Use Case 1 — Scan all stores, filter by CA issuer.

ExtName: Discover_WinCerts
config_name: "windows-prod-scan"
target_issuers:
  - DigiCert
  - Sectigo
  - "Corp Internal CA"

Use Case 2 — Retrieve a specific certificate by thumbprint, include ADFS.

ExtName: Discover_WinCerts
config_name: "adfs-cert-audit"
thumbprint: "A1:B2:C3:D4:E5:F6:07:08:09:0A"
scan_adfs: true
adfs_ps_timeout: 60

Source Code Cryptographic API Scanner

Discover_SourceCode — a multi-language static analysis sensor using tree-sitter AST parsing to detect cryptographic API usage across C/C++, Python, Java, Go, JavaScript/TypeScript, Rust, and C#. Resolves algorithm parameters via variable backtracking, classifies risk severity (SAFE / MEDIUM / HIGH / CRITICAL), detects PQC usage, and builds a directed call graph tracing crypto usage back to application entry points. Supports local directories, ZIP archives, and GitHub repositories (public and private).

The cryptography an application uses is decided in its source code: which algorithm, which key size and mode, whether an IV is reused or a key is hard-coded. None of that is visible to a scan of servers, key stores or binaries. This sensor reads source code and reports each call into a cryptographic library with the algorithm and parameters it uses and a severity, which is where most quantum-vulnerable RSA and elliptic-curve usage has to be found for post-quantum migration.

Typical use: a checkout on a build server or file share, a ZIP of a release, or a repository cloned from GitHub, Bitbucket, GitLab or any Git host. The same sensor can also run as a step in a CI/CD pipeline through the separate src_CI runner, which fails the build when a finding breaks a rule you set.

What it finds

Calls into cryptographic libraries in fifteen languages: C, C++, Objective-C, Python, Java, Kotlin, Scala, Go, JavaScript, TypeScript, Rust, C#, Swift, Ruby and PHP.
For each call: the algorithm and the parameters recovered from the code — key size, curve, cipher mode, padding, digest, iteration count, IV and nonce — and how each value was determined (a literal, a constant, a traced variable, or unresolved).
A severity of SAFE, LOW, MEDIUM, HIGH or CRITICAL. Raised for deprecated or weak algorithms, ECB mode, a missing IV or nonce, short keys, low key-derivation iteration counts and keys or IVs traced to hard-coded values. Quantum-vulnerable algorithms (RSA, ECDSA, ECDH, DH, DSA, Ed25519 …) are tagged; ML-KEM, ML-DSA, SLH-DSA and other post-quantum algorithms are recognised as safe.
Optional heuristic matches for crypto-named functions that belong to no known library, and recognisable algorithm constants that suggest a home-grown implementation.
A document per source file, a project summary, and a call graph tracing each crypto call back to the application’s entry points, viewable in the Source Code Visualizer.
The repository URL, the branch actually checked out and the short commit hash, recorded on every document.

It does not collect:

Cryptography inside compiled dependencies. Use the Binary sensor.
Certificate, key or keystore files committed to the repository. Use the Files sensor on the checkout.
Algorithms chosen at run time from configuration that is not in the code, or code in branches that were not scanned.

Requirements

Runs as	Both. As a Cloud sensor from the discovery server (typically for repository sources), or from a Networked agent to scan code on the target host. It also runs Off-Grid, and inside CI/CD pipelines through `src_CI`.
Reaches the target over	The local file system for `directory` and `zip`. For repository sources, a shallow `git clone` over HTTPS (or SSH, using the machine’s own SSH keys) to the Git host.
Credentials and permissions	Read access to the directory or ZIP file. For a private repository, an access token with read access to repository contents: a GitHub personal access token, a GitLab token, or a Bitbucket access token (or an App Password together with `git_username`). No write access is needed.
Platform	Any platform the agent or discovery server runs on.
Prerequisites	The `git` command-line client on the `PATH` for repository sources. The language grammars and call-graph library are bundled with the agent; a grammar missing from a source-run installation causes that language to be skipped.
Required parameters	`source`, plus `path` for `directory` / `zip`, or `github_repo` for repository sources.

Core parameters

Parameter	Type	Required	Description
`ExtName`	string	Yes	Must be `Discover_SourceCode`.
`source`	string	Yes	Source type: `directory`, `zip`, `github`, `github_action` or `bitbucket` on the form; a task file may also use `gitlab` or `git` for any other HTTPS Git host. Default: `directory`.
`path`	string	*	Path to the local directory or ZIP file. Required for `source: directory` or `zip`.
`github_repo`	string	*	Clone URL of the repository on any Git host (GitHub, Bitbucket, GitLab …). Required for every repository source.
`branch`	string	No	Branch or tag to clone. The form pre-fills `master`; if the branch does not exist the repository’s default branch is scanned instead, and the branch actually scanned is recorded.
`github_token`	string	No	Access token for a private repository on any host. Injected into the HTTPS clone URL in the form each host expects; never written to logs.
`git_username`	string	No	Username paired with the token. Needed only for Bitbucket App Passwords or a self-hosted server — GitHub, GitLab and Bitbucket access tokens work on their own.
`local_cache`	string	No	Keep the clone at this path and update it with a fast-forward pull on later runs, instead of cloning each time. An existing cache is not switched to a different `branch`.
`max_workers`	integer	No	Parallel scanning processes. Default: `5`. Clamped to the machine’s core count — asking for 50 on an 8-core host quietly gives 8, not oversubscription — and to 61 on Windows, a hard limit of its process pool.
`no_graph`	boolean	No	Skip call-graph construction. Default: `false`. Findings are still reported; what you lose is the trace from a crypto call back to an application entry point, and with it the Source Code Visualizer’s call-graph view.

Scan options

Parameter	Type	Required	Description
`snippet_context`	integer	No	Lines of source code captured above and below each finding. Default: `4`.
`heuristic`	boolean	No	Heuristic fallback: patterns catch crypto-named functions not matched by any known library definition. Increases recall at the cost of precision. The Template form turns it on by default; in a task file that omits the key it is off.
`project_id`	string	No	Identifier written to every document’s `sourceProperties.projectID`.
`origin`	string	No	Logical origin label written to `sourceProperties.origin`. Default: `"local"`.
`exclude_paths`	list	No	Paths to skip. A pattern without a `/` matches a folder or file name at any depth (`test` skips `src/test/`); a pattern with a `/` is anchored at the project root (`src/gen/**`). Case-insensitive. Supplying a list replaces the built-in defaults (tests, examples, vendor, build output …), which the form pre-fills.

Supported languages & libraries

The scanner covers 15 languages — 10 languages plus 5 dialects (C++, TypeScript, Kotlin, Scala and Objective-C) that share their parent language’s library catalogue — and close to 100 cryptographic libraries, including post-quantum algorithms (ML-KEM / FIPS 203, ML-DSA / FIPS 204, SLH-DSA / FIPS 205). A .h header is read as C++ when its content uses C++ constructs, and as C otherwise.

Language	Extensions	Notable libraries
`C / C++`	.c .h .cpp .cc .cxx .c++ .hpp .hh .hxx .h++ .ipp .tpp .inl	OpenSSL (EVP + PQC 3.5), GnuTLS, mbedTLS, libsodium, WolfSSL, Windows CNG/BCrypt, liboqs, PKCS#11
`Python`	.py .pyi	cryptography (PyCA), PyCryptodome, hashlib, PyNaCl, bcrypt, argon2-cffi, pyOpenSSL, Paramiko, liboqs-python
`Java`	.java	JCE/JCA, Bouncy Castle (classic + PQC 1.77+), Apache Commons Crypto, SunPKCS11
`Go`	.go	crypto/* stdlib, crypto/mlkem (1.24+), golang.org/x/crypto
`JavaScript / TypeScript`	.js .mjs .cjs .jsx .ts .tsx .mts .cts	Node.js crypto, Web Crypto API, @noble/post-quantum, jsonwebtoken, bcryptjs
`Rust`	.rs	ring, openssl crate, RustCrypto (aes/chacha20/sha2), rustls, oqs-rust
`C#`	.cs .csx	System.Security.Cryptography (BCL), BouncyCastle.Cryptography (PQC), ASP.NET Core DataProtection, Pkcs11Interop
`Kotlin / Scala`	.kt .kts .scala .sc	The same JVM libraries as Java: JCE/JCA, Bouncy Castle
`Objective-C`	.m .mm	The same C libraries as C, such as OpenSSL
`Swift`	.swift	CryptoKit, CommonCrypto, Security framework
`Ruby`	.rb .rake .gemspec	OpenSSL, Digest, SecureRandom
`PHP`	.php .php3 .php4 .php5 .phtml	OpenSSL extension, hash, password_hash, sodium, mcrypt

Use Case 1 — Scan a local C# microservice repository.

ExtName: Discover_SourceCode
source: directory
path: "C:\\Projects\\PaymentService"
project_id: "payment-service-v3"
origin: "local"
snippet_context: 5
heuristic: false
exclude_paths:
  - "tests/**"
  - "vendor/**"
  - "build/**"

Use Case 2 — Scan a public GitHub repository.

ExtName: Discover_SourceCode
source: github
github_repo: "https://github.com/openssl/openssl"
branch: "master"
local_cache: "/var/cache/repos/openssl"
project_id: "openssl-upstream"
heuristic: false

Use Case 3 — Scan a private GitHub repo with heuristic fallback.

ExtName: Discover_SourceCode
source: github
github_repo: "https://github.com/myorg/core-platform"
branch: "main"
github_token: "ghp_xxxxxxxxxxxxxxxxxxxxxx"
local_cache: "/tmp/core-platform-cache"
project_id: "core-platform"
origin: "github-ci"
heuristic: true
snippet_context: 6
exclude_paths:
  - "node_modules/**"
  - ".git/**"
  - "__pycache__/**"

Use Case 4 — Scan a ZIP archive from an artifact store.

ExtName: Discover_SourceCode
source: zip
path: "/artifacts/release-3.2.0.zip"
project_id: "core-platform-release-3.2.0"
origin: "release-artifact"

Microsoft AD CS Discovery

Discover_ADCS — inventories a Microsoft Active Directory Certificate Services CA over WinRM, reading the CA's own certificates, its CRLs and the certificates it has issued. Nothing is installed on the CA server.

Microsoft AD CS is the issuing CA behind most Windows estates, and its database is the authoritative record of every certificate it has issued — including certificates that were never published to Active Directory or installed anywhere a network scan can see. Reading the CA directly gives a complete, issuer-side inventory: which templates are in use, who requested what, which key sizes and algorithms were issued, and how the CA's own signing key is protected.

The sensor runs certutil on the CA server through a remote PowerShell (WinRM) session. It only reads; it never issues, revokes or changes anything on the CA.

What it finds

The CA signing certificate, with its algorithm, key size, validity and issuer.
The CA private key's profile — algorithm, size and the key storage provider, classified as software or HSM. The key itself is never read.
Issued certificates from the CA database, fully parsed (subject, issuer, serial number, validity, algorithm and key size), together with the requester and the certificate template used.
Revocation details — revoked certificates carry their revocation reason and date, taken from the CA database.
Filtering by template, requester, key algorithm or key length, so a scan can target, for example, only RSA-1024 certificates.
Not collected — pending, failed and denied requests are not read; certificate template definitions are not inventoried.

Requirements

Runs as	Both. Cloud from the discovery server, or Networked from an agent on a host that can reach the CA. Nothing is installed on the CA server.
Reaches the target over	WinRM to the CA server itself: HTTP on 5985 (default) or HTTPS on 5986. Authentication is NTLM.
Credentials and permissions	A domain account (`DOMAIN\user` or UPN) allowed to open a WinRM session on the CA server. Enumerating issued certificates needs the Manage CA right; with read access only, the CA certificate and key phase still runs.
Platform	The target must be a Windows Server running AD CS with WinRM enabled (`winrm quickconfig`). The sensor itself runs on Linux or Windows.
Prerequisites	WinRM enabled and its port open from the scanning host. Over HTTPS the WinRM server certificate is not validated, so traffic is encrypted but the server's identity is not checked; plain HTTP should be used only on a trusted management network. A large CA database may need a higher `timeout_seconds` and `max_issued_certs`.
Required parameters	`host`, `username`, `password`.
Setup guide	Microsoft AD CS sensor setup

The account needs Manage CA to enumerate the issued certificate database, or read access alone for the CA information and CRL phases.

Connection

Parameter	Type	Required	Description
`host`	string	Yes	Hostname or IP of the AD CS server. WinRM must be enabled on it.
`ca_name`	string	No	The CA's common name as `certutil` shows it. Leave blank and the sensor reads it from the server's registry.
`username`	string	Yes	Domain account, as `DOMAIN\user` or a UPN.
`password`	string	Yes	Password for that account.
`winrm_port`	integer	No	Default: `5985` (HTTP). 5986 is HTTPS. Left at 5985 with `winrm_ssl: true`, the sensor switches to 5986 for you.
`winrm_ssl`	boolean	No	Use HTTPS WinRM. Default: `false`; recommended for production. The server certificate is not validated, so the network still has to be trusted.
`timeout_seconds`	integer	No	Per-command WinRM timeout. Default: `60`. Raise it for a large CA database, where `certutil -view` can be slow to return.
`scan_name`	string	No	Label attached to every document from the run.

Scope and filtering

Parameter	Type	Required	Description
`discover_issued_certs`	boolean	No	Enumerate the issued certificates from the CA database. Default: `true`. Needs Manage CA.
`include_revoked`	boolean	No	Keep revoked certificates in the inventory. Default: `true`. The revocation reason and date are always populated from the CA database.
`max_issued_certs`	integer	No	Hard cap per CA. Default: `10000`. Processing stops at the cap and logs a warning, so raise it for a large estate rather than assuming a full scan.
`include_filters`	list	No	Restrict which certificates are emitted. Empty (the default) includes everything. Each entry is a `column` plus a list of `values`; see the columns below.
`include_match_mode`	string	No	`any` (default) emits a certificate matching at least one filter; `all` requires every filter to match.
`exclude_filters`	list	No	Drop certificates matching these rules. Applied after the include filters.
`exclude_match_mode`	string	No	`any` (default) drops a certificate matching at least one rule; `all` drops it only when every rule matches.

A filter's column is one of CertificateTemplate, Request.RequesterName, PublicKeyAlgorithm or PublicKeyLength. The three string columns match partially and case-insensitively; PublicKeyLength matches the integer exactly.

Use Case 1 — Whole CA over plain WinRM.

ExtName: Discover_ADCS
host: ca-server.corp.com
username: "CORP\\svc-cbom"
password: "<password>"
winrm_port: 5985
winrm_ssl: false
discover_issued_certs: true
include_revoked: true
max_issued_certs: 10000
scan_name: "Corp-Issuing-CA-2"

Use Case 2 — Large CA over HTTPS, web-server templates only, RSA-1024 dropped.

ExtName: Discover_ADCS
host: ca-server.corp.com
ca_name: "Corp Issuing CA 2"
username: "[email protected]"
password: "<password>"
winrm_ssl: true
timeout_seconds: 300
max_issued_certs: 250000
include_match_mode: any
include_filters:
  - column: CertificateTemplate
    values:
      - WebServer
      - ComputerAuth
exclude_match_mode: all
exclude_filters:
  - column: PublicKeyAlgorithm
    values:
      - RSA
  - column: PublicKeyLength
    values:
      - "1024"

EJBCA REST API Discovery

Discover_EJBCA — inventories an EJBCA PKI through its REST API in four independently switchable phases: the CA signing certificates, every end-entity certificate ever issued, the SSH CA public keys, and the key-pair algorithm and size held in each crypto token.

EJBCA (Keyfactor) is a widely deployed open-source and enterprise PKI. Reading it through its REST API gives the issuer's view of the estate: every CA it runs, every certificate those CAs have issued, and — on EJBCA Enterprise — the algorithm and size of each signing key and the hardware or cloud service that holds it. That last layer answers a central post-quantum migration question: are the CA signing keys themselves still RSA-2048?

The sensor only calls read endpoints of the REST API; it never issues, revokes or changes anything in EJBCA.

What it finds

CA certificates — root and subordinate CA signing certificates, each with its public key.
Issued certificates for the selected statuses (active, revoked, about to expire, and optionally archived), with subject, issuer, serial number, validity, algorithm and key size. OpenSSH certificates issued by EJBCA SSH CAs are picked up as well.
SSH CA public keys for CAs running in SSH mode.
Crypto token key pairs (EJBCA Enterprise only) — for each token, every key pair's alias, algorithm (including post-quantum algorithms such as ML-DSA), size or curve, key usage, and what backs it: soft token, PKCS#11 HSM, Azure Key Vault or AWS KMS.
Not collected — private key material of any kind (the crypto token phase reads configuration metadata only), and end-entity profiles or certificate profiles.

Requirements

Runs as	Both. Cloud from the discovery server, or Networked from an agent on a host that can reach the EJBCA server. Nothing is installed on EJBCA.
Reaches the target over	HTTPS to the EJBCA REST API (typically `https://<host>/ejbca/ejbca-rest-api`). Plain HTTP is rejected.
Credentials and permissions	A client certificate and private key for mutual TLS, pasted into the configuration either as a base64 PKCS#12 bundle or as separate PEM certificate and key. The certificate must belong to an EJBCA role with REST API access; the crypto token phase requires the SuperAdmin role.
Platform	Not restricted — runs on Linux or Windows. Crypto token discovery needs EJBCA Enterprise (it uses the configdump REST API, which Community Edition does not provide); the other three phases work on both editions.
Prerequisites	The REST API enabled on EJBCA and reachable from the scanning host. To verify EJBCA's own server certificate, enable `verify_ssl` and paste the issuing CA certificate into `server_ca_content` (or rely on the OS trust store).
Required parameters	`base_url`, `auth_mode`, and either `client_p12_base64` (for `certificate_p12`) or `client_cert_content` and `client_key_content` (for `certificate_inline`).

EJBCA requires mutual TLS, so a client certificate is not optional. Both credential forms are pasted straight into the configuration — no files are read from disk. Phase 4 needs the SuperAdmin role; the crypto token phase reports algorithms and sizes only and never touches private key material.

Connection and authentication

Parameter	Type	Required	Description
`base_url`	string	Yes	Full base URL of the REST API, no trailing slash (e.g. `https://ejbca.example.com/ejbca/ejbca-rest-api`).
`auth_mode`	string	Yes	`certificate_p12` (default) to paste a base64 P12 bundle, or `certificate_inline` to paste the PEM certificate and key separately.
`client_p12_base64`	string	*	Base64 of the `.p12`. Required for `certificate_p12`. Produce it with `base64 superadmin.p12`, or `certutil -encode superadmin.p12 out.b64` on Windows.
`client_p12_password`	string	No	The password the P12 was created with.
`client_cert_content`	string	*	PEM certificate. Required for `certificate_inline`.
`client_key_content`	string	*	PEM private key. Required for `certificate_inline`.
`verify_ssl`	boolean	No	Verify the EJBCA server's own TLS certificate. Default: `false`. Enable it for production; disable only for a self-signed lab instance.
`server_ca_content`	string	No	PEM certificate of the CA that signed the server's TLS certificate, used to verify it. Only relevant when `verify_ssl: true`; left blank there, the OS trust store is used instead.
`timeout_seconds`	integer	No	Per-request timeout. Default: `30`.
`scan_name`	string	No	Label attached to every CM-Doc from the run.

Discovery scope

Parameter	Type	Required	Description
`discover_ca_certs`	boolean	No	Phase 1 — the CA signing certificates, root and subordinate. Default: `true`.
`discover_issued_certs`	boolean	No	Phase 2 — every end-entity certificate ever issued. Default: `true`. Also picks up OpenSSH certificates from EJBCA SSH CAs.
`discover_ssh_ca_keys`	boolean	No	Phase 3 — SSH CA public keys. Default: `true`. CAs without SSH mode are skipped.
`discover_crypto_tokens`	boolean	No	Phase 4 — key-pair algorithm and size per HSM or token. Default: `true`. Requires the SuperAdmin role; no private key bytes are read.
`ca_filter`	list	No	Restrict phase 2 to specific CAs by their EJBCA name. Empty scans every CA.
`status_filter`	list	No	Which certificate statuses to collect. Default: `CERT_ACTIVE`, `CERT_REVOKED`, `CERT_NOTIFIEDABOUTEXPIRATION`. `CERT_ARCHIVED` is also available, and is skipped without error on an EJBCA version that does not support the filter.
`page_size`	integer	No	Certificates per API request in phase 2, 1–1000. Default: `100`.

Use Case 1 — Lab instance, P12 credential, all four phases.

ExtName: Discover_EJBCA
base_url: "https://ejbca.lab.local/ejbca/ejbca-rest-api"
auth_mode: certificate_p12
client_p12_base64: "MIIJQQIBAzCC..."
client_p12_password: "<p12-password>"
verify_ssl: false
discover_ca_certs: true
discover_issued_certs: true
discover_ssh_ca_keys: true
discover_crypto_tokens: true
page_size: 100
scan_name: "EJBCA-Lab"

Use Case 2 — Production, PEM credential, verified server, two CAs, active certificates only.

ExtName: Discover_EJBCA
base_url: "https://ejbca.corp.example.com/ejbca/ejbca-rest-api"
auth_mode: certificate_inline
client_cert_content: |
  -----BEGIN CERTIFICATE-----
  MIID...
  -----END CERTIFICATE-----
client_key_content: |
  -----BEGIN PRIVATE KEY-----
  MIIEv...
  -----END PRIVATE KEY-----
verify_ssl: true
server_ca_content: |
  -----BEGIN CERTIFICATE-----
  MIIF...
  -----END CERTIFICATE-----
ca_filter:
  - "Corp Issuing CA 1"
  - "Corp Issuing CA 2"
status_filter:
  - CERT_ACTIVE
page_size: 1000
timeout_seconds: 60
discover_crypto_tokens: false
scan_name: "EJBCA-Prod"

CertSecure CLM Discovery

Discover_CertSecure — connects to an Encryption Consulting CertSecure Certificate Lifecycle Management (CLM) server via its REST API and paginates through its certificate inventory. Supports scanning by certificate status (active, expired, revoked, etc.) or by certificate template, and can handle inventories of hundreds of thousands of certificates efficiently.

CertSecure already tracks certificates across the CAs it manages. Importing that inventory gives CBOM Secure the certificate estate without scanning each CA or endpoint separately, so certificate data from the lifecycle platform can be scored, policy-checked and reported alongside keys, protocols and code findings discovered elsewhere.

The sensor uses CertSecure's REST API with an API key and only reads; nothing is changed in CertSecure.

What it finds

Certificate records for each CA CertSecure manages: subject, serial number, validity dates, public key algorithm and size, signing algorithm, key usage, certificate and public key fingerprints, and the template the certificate was issued from.
Lifecycle status as CertSecure records it — active, expired, revoked, failed or denied — and the CA type.
Scope by CA, status or template — or every CA and status when no targets are given.
Not collected — the certificate itself is not downloaded, so values come from CertSecure's inventory record rather than from parsing the certificate; the issuer is recorded as the CA name (CN=<CA name>), not the full issuer DN. Keys and private key material are not collected.

Requirements

Runs as	Both. Cloud from the discovery server, or Networked from an agent on a host that can reach CertSecure.
Reaches the target over	HTTPS (or HTTP) to the CertSecure API at `base_url`, using its `/ca` and `/inventory` endpoints.
Credentials and permissions	A CertSecure API key, sent in the `Authorization` header, with read access to the CA list and certificate inventory.
Platform	Not restricted — runs on Linux or Windows.
Prerequisites	Network reachability to CertSecure, and a server certificate trusted by the scanning host unless `verify_ssl` is turned off. Every CA and template named in `targets` must exist on the server: an unknown name stops the whole scan before any inventory is fetched, and the error lists the names that are available.
Required parameters	`base_url`, `api_key`.

Parameter	Type	Required	Description
`base_url`	string	Yes	CertSecure API base URL (e.g. `https://certsecure.example.com`).
`api_key`	string	Yes	API key for authentication against the CertSecure server.
`verify_ssl`	boolean	No	Validate the CertSecure server's TLS certificate. Default: `true`.
`fallback_page_size`	integer	No	Records per API page, 10–20,000 in the web form. Increase for faster scans on reliable connections. Default: `2000`. Tested up to `10000` with 670k+ certificates.
`inventory_timeout`	integer	No	HTTP read timeout (seconds) per inventory page, 10–600. Default: `180`.
`max_retries`	integer	No	Attempts before a page fetch is abandoned, with exponential backoff between them, 1–10. Default: `3`.
`max_pages`	integer	No	Limit the pages fetched per status or template. Useful for test runs. Omit for a full scan.
`scan_name`	string	No	Label embedded in every result's `scanProperties`. The web form accepts 3–100 letters, digits, spaces, hyphens and underscores.
`targets`	list	No	List of CA scan targets. If empty or omitted, every CA and status is auto-enumerated. A CA name the server does not know stops the whole scan before any inventory is fetched.

Target parameters (per item in targets)

Parameter	Type	Required	Description
`ca`	string	Yes	Certificate Authority name as registered in CertSecure (e.g. `EC Internal MSCA`).
`scan_mode`	string	Yes	`status` — paginate by certificate lifecycle status. `template` — paginate by certificate template name.
`statuses`	list	No	When `scan_mode: status`. Certificate statuses to fetch. Options: `active`, `expired`, `revoked`, `failed`, `denied`. Leave empty to fetch all statuses that have certificates.
`templates`	list	No	When `scan_mode: template`. Template names to fetch. Leave empty to fetch all templates that have certificates.

Performance note: in benchmarks, 210,000 active certificates were fetched at page size 10,000 in approximately 11.6 minutes. The sensor uses on-disk spill (via EC_Libs.Utils) rather than in-memory accumulation, so it handles millions of certificates without memory pressure.

Use Case 1 — Full inventory scan by status.

Name: CertSecureDiscovery
ExtName: Discover_CertSecure
Config:
  base_url: "https://certsecure.corp.example.com"
  api_key: "<api-key>"
  fallback_page_size: 5000
  verify_ssl: true
  scan_name: "CertSecure-Full-Scan"
  targets:
    - ca: "Corp Internal MSCA"
      scan_mode: status
      statuses:
        - active
        - expired
        - revoked

Use Case 2 — Target specific certificate templates.

Name: CertSecureTemplateScan
ExtName: Discover_CertSecure
Config:
  base_url: "https://certsecure.corp.example.com"
  api_key: "<api-key>"
  fallback_page_size: 2000
  verify_ssl: true
  scan_name: "CertSecure-Templates-Scan"
  targets:
    - ca: "Corp Internal MSCA"
      scan_mode: template
      templates:
        - "WebServerSSL"
        - "UserAuthentication"
        - "CodeSigning"

Use Case 3 — Test run (limited pages).

Name: CertSecureTestRun
ExtName: Discover_CertSecure
Config:
  base_url: "https://certsecure.corp.example.com"
  api_key: "<api-key>"
  fallback_page_size: 100
  max_pages: 2
  verify_ssl: true
  scan_name: "CertSecure-Test"

CBOM Secure

Discovery Sensors Reference

AWS Certificate & Key Discovery

Azure Certificate & Key Discovery

GCP Cloud KMS Discovery

Active Directory Discovery

LDAP Cryptographic Material Discovery

HashiCorp Vault Discovery

KMIP Key Management Discovery

PKCS#11 HSM / Token Discovery

GPG Keyring Discovery

SQL Server TDE Key Discovery

MySQL / InnoDB TDE Key Discovery

Oracle TDE Key Discovery

HTTPS / TLS Endpoint Discovery

SSH Server Discovery

File System Cryptographic Material Discovery

Binary / Executable Cryptographic Library Detection

Windows Certificate Store Discovery

Source Code Cryptographic API Scanner

Microsoft AD CS Discovery

EJBCA REST API Discovery

CertSecure CLM Discovery

On this Page: