What is being watched

What servers do we actually run, and how critical is each one?

ComplianceHub reads the Ansible inventory files the operations team already uses to deploy — the same files that decide where code goes — and records every host in them with its address, environment and deployment group. Using the deployment source rather than a separate list is deliberate: a hand-maintained inventory drifts the moment someone provisions a server without updating it, whereas a host missing from these files would not receive deployments. Each host is given an IS-11 §6.1 business impact tier inferred from its group (production hosts serve customers, so they are Critical), and that inference is applied only when the asset is first discovered — once a person sets a tier, re-running discovery will not overwrite it.

Which public web addresses are inside the SOC 2 audit boundary?

Reads the OBSERVED_DOMAINS setting — the explicit, reviewed list of public domains in scope — and registers each as an asset for the perimeter probes to observe. It is configuration rather than discovery on purpose: what falls inside an audit boundary is a scoping decision, not something to infer. A domain removed from the list is retired rather than deleted, so it stops being probed but its history remains. Domains found by other means, such as a public_url in the deployment inventory, are reported alongside but never retired by this collector.

If someone on the internet scanned our servers, what would answer — and is anything answering that should not be?

For every host in the asset inventory, ComplianceHub tries to open a plain TCP connection to each port on a fixed watch list, from outside the network. The list has two halves: the three ports the firewall baseline permits (22 SSH, 80 HTTP, 443 HTTPS), and seven that must never be reachable because they are databases and admin interfaces — PostgreSQL, Redis, MySQL, MongoDB, Elasticsearch, memcached and the Docker daemon. A port that completes a connection is reachable; one that refuses or times out is not. Nothing is sent after the connection opens, and the list is explicit rather than a range, so this is a check against a stated baseline rather than a scan.

If someone visits our sites over plain HTTP, are they moved to HTTPS and kept there — and which browser-side protections are switched on?

For each in-boundary domain, ComplianceHub makes two ordinary web requests. First to http:// without following the redirect, to record whether the server sends the visitor to https:// . Then to https:// , to read the response headers. It records whether Strict-Transport-Security is set and for how long (which is what keeps a browser on HTTPS after the first visit), and which of the standard hardening headers are present or absent. Header absence is reported but not scored: which headers CiteMed requires is a hardening-standard decision under IT-04 §10, and inventing a pass mark here would make ComplianceHub set policy rather than evidence it.

When an engineer connects to a production server from outside, is that connection encrypted — and is there any other way in that is not?

For every production host in the asset inventory, ComplianceHub opens a connection to the SSH port and performs the opening exchange of the SSH protocol: it reads the server's identification banner, sends its own, and reads the server's list of the cryptographic algorithms it is prepared to use. Every SSH client does this before it authenticates, and the list is the server's own statement of what it will and will not accept. The probe stops there — it does not complete the key exchange, does not offer a username, password or key, and never opens a session. The list that comes back is then checked for the protocol version and for algorithms that provide no real confidentiality: the null cipher, RC4, single and triple DES, Blowfish, CAST, MD5 and truncated-SHA1 message authentication, and the 1024-bit Diffie-Hellman group. Separately, the probe tries to connect to the eight ports used by remote administration protocols that carry no encryption at all — Telnet, FTP, the Berkeley r-services, an unsecured Docker socket, VNC and RDP — because an SSH server configured perfectly is not evidence that SSH is the only route in. Nothing is sent to those ports beyond the connection attempt. Finally it asks each server which authentication methods it would accept, by opening a connection and then explicitly declining to authenticate. The server replies with its own list — typically 'publickey', or 'publickey,password' if a password alone is still enough to open a shell. No username that exists is used and no credential is ever sent; the reply is sshd's own statement about itself.

Is traffic to our public domains actually encrypted with a current protocol, and are the certificates in date?

For each domain declared in the audit boundary, ComplianceHub opens an ordinary HTTPS connection from wherever it is running — the same connection a browser makes — and records what the server negotiated: the TLS version, the cipher suite, the certificate's issuer and subject, and its expiry date. Nothing is sent beyond the handshake and no credentials are used, so this observes exactly what any member of the public would see.

What third-party code do our applications ship, and which of it has a publicly known vulnerability we have not yet picked up?

For every codebase inside the audit scope, ComplianceHub runs Trivy against the lockfiles the application is actually built from — uv.lock, package-lock.json, poetry.lock, requirements.txt and their equivalents — and matches each pinned dependency version against the public vulnerability databases Trivy maintains. Reading the lockfile rather than a maintained list of dependencies is deliberate: the lockfile is what the build resolves, so it cannot drift from what we deploy without the build itself changing. Every vulnerability found is recorded as a finding and scored through the IS-11 §6.2 matrix: its CVSS v3 base score is crossed with the business-impact tier of the system it ships on to produce a P-level and a remediation deadline. Where an advisory publishes no numeric CVSS score, the severity band the advisory did publish is used and the artifact records that no score existed, rather than a number being invented to fill the table. Findings carry a stable fingerprint, so a re-scan updates the ones still present instead of opening duplicates, and one that has been fixed keeps its history. Trivy is run read-only and is never asked to remediate; its secret and misconfiguration scanners are switched off, because a secret scanner's findings are themselves the secret and this evidence store is append-only.

If someone on the internet went looking for a way into our systems today, what would they find?

Nuclei is run from outside our infrastructure against every externally reachable system in the asset inventory — the public domains and the host addresses themselves. It sends unauthenticated requests the way any visitor could, matching each response against a community-maintained template set of known vulnerabilities, exposed panels and dangerous misconfigurations. This is an outside-in scan and it is deliberately run from a workstation rather than from the estate: a scan launched from behind our own firewall cannot demonstrate what an outsider reaches. Where it ran from is recorded on the artifact. Three classes of template are excluded and the exclusions are part of the evidence. Denial-of-service, fuzzing, brute-force and intrusive templates never run, because a scanner that can take production down is not an evidence tool. Out-of-band testing is disabled, because it works by making our servers call out to a third-party server and that would leak our hostnames to someone else. Request and response bodies are not captured, because a vulnerable page is exactly the kind of page that discloses secrets, and this evidence store is append-only. Each finding keeps the curl command that reproduces it, so nothing is taken on trust. Informational templates — technology fingerprinting, header presence — are excluded as noise: they describe no vulnerability and arrive in thousands. Every remaining finding is graded through the §6.2 matrix against the impact tier of the system it was found on, and the scanner's own report is retained alongside a SARIF 2.1.0 rendering.

Which of our servers are running operating-system packages with known vulnerabilities that already have a fix available?

For every host in the asset inventory, ComplianceHub opens an SSH session and runs Trivy against that host's own filesystem, then brings the report back. This is an authenticated internal scan in the sense IS-11 §5.1 means it: the scanner is inside the machine reading its real package database, not guessing from outside what version might be installed. Nothing is installed on the host and nothing is left running. Trivy is a single command that reads the package database, prints a report and exits — not an agent — and it runs from the container image Docker already has on every host, with the host root mounted read-only. The scan is limited to operating-system packages, because application dependencies are scanned from source by the separate composition analysis, and to vulnerabilities that have a fix available, which is the wording IS-11 §7.1 itself uses. Each vulnerability is scored through the §6.2 matrix against the host's business-impact tier, giving it a priority and a remediation deadline, and the scanner's own report is retained alongside the summary together with a software bill of materials in SPDX and CycloneDX.