What the agent collects

With the server profile the agent runs four collectors. The first three report facts, and matching against advisories, lifecycles and the benchmark happens in TigerGate, so a check can be corrected without an agent release. The fourth, custom_audit, judges your own checks on the server and reports only verdicts. The developer-workstation collectors (IDEs, extensions, AI tools, credentials, browser data) do not run with the server profile.

​

Application software

packages_app reports each item under the identity the vulnerability matcher uses, with the real path where it is installed: A runtime installed by the OS package manager, such as Ubuntu’s openjdk-17-jdk or nginx package, is reported by packages_system and matched against the distribution’s advisories, which include the fixes the distribution backports. It is not reported a second time as upstream software. MySQL and Redis are reported only when the installation shows its version (a version header or a versioned directory); a bare binary does not name its version reliably. OpenSSL is read from the version banner in its libraries.

​

Application servers and databases

For these products a version alone says almost nothing. Oracle’s advisories name the base release as affected (WebLogic 12.2.1.4.0, Database 19c), and a quarterly patch leaves that number unchanged. Matching the base release would report every CVE ever published against a fully patched server. So the agent reads the patch level from the files the vendor’s own installer and patch tool wrote into the install, and the version it reports carries it. The agent only reads these files. It never runs opatch, versionInfo or any other program from the install, and it never connects to a database: an Oracle home is recognised from its files, and no listener, instance or account is involved. Each file is read up to a fixed size and a home’s patch directory up to a fixed number of entries. Windows installs use the same layout. When the patch level cannot be read. If the inventory is missing, unreadable by the agent’s account, or lists patches none of which the agent recognises as a quarterly update, the home is still reported, as for example 12.2.1.4.0 (patch level unknown). TigerGate does not assess it: no CVE is raised on the base release and none is closed, and the package shows as Not assessed. The server’s coverage details count these homes. A home with an intact inventory and no applied patch is a different, certain state, and is reported as unpatched. To read an inventory the agent’s account cannot open, install in privileged mode or give the account read access to inventory/. How a CVE is matched. For WebLogic and Oracle Database, TigerGate takes the date of the Oracle advisory that fixes the CVE from the advisory link in its National Vulnerability Database record (oracle.com/security-alerts/cpuapr2023.html) and compares it with the date inside the installed patch’s version (12.2.1.4.230329 is dated 2023-03-29). A patch built up to 50 days before an advisory counts as carrying its fixes, because Oracle builds each quarterly patch before the advisory is published. Oracle Database records that give Release Update numbers (19.3 through 19.31) are matched by number. For WebSphere and JBoss EAP the fix pack or update is compared with the ranges in the record. Limits.

• A WebSphere interim fix (iFix) does not change the product version, and NVD names fix packs, not iFixes, so a CVE fixed on a server by an iFix alone stays open until a fix pack that contains it is installed.
• A monthly Oracle Critical Security Patch Update applied on top of the latest quarterly patch is not recognised, so a CVE fixed only by it stays open until the next quarterly patch.
• Some NVD records for a CVE that Oracle lists in several advisories (a third-party library such as jQuery) are dated at the earliest advisory, which can hide that CVE on a server that is already several quarters behind.
• NVD names some JBoss EAP CVEs against the base release (7.4) without a fixed update. Those match a 7.4.0 install and no later update; a CVE with a fixed update in its record is matched normally.
• Open Liberty (io.openliberty) is a different product and is not read as WebSphere.

​

Third-party applications

Software that no package-manager advisory feed covers is assessed against the National Vulnerability Database for a curated list of widely used products: Chrome, Edge, Firefox, Adobe Acrobat and Reader, Zoom, Oracle Java, Python, Node.js, OpenSSL, MySQL, Redis, 7-Zip, Notepad++, PuTTY, WinRAR, VLC, VMware Tools, Wireshark, Git, FileZilla, WinSCP, TeamViewer, AnyDesk and KeePass. This applies to Windows programs, Chocolatey packages, Mac applications, Homebrew packages, and the server software above. Oracle WebLogic Server, Oracle Database, IBM WebSphere Application Server and Red Hat JBoss EAP are assessed against the same database, by patch level as described above. Anything not on the list shows as Not assessed, never as clean. NVD can take days to analyse a new CVE, so a finding can trail the vendor’s fix by that much.

​

Microsoft server products (Windows)

A security update for SQL Server, Exchange, Office or .NET changes the product’s build, not the version shown in Programs and Features. Windows keeps the install-time version there (“SQL Server 2019”, 15.0.2000.5, forever), so packages_app reads each product’s current build from where the product itself records it, and TigerGate compares that build with the fixed build Microsoft publishes for the product’s servicing branch. These are all read-only: registry values under HKLM\SOFTWARE, which ordinary users can read by default, and the version resource of two files. The agent writes nothing, starts no program, and never connects to SQL Server or Exchange, so it needs no database login. If a key is refused, the scan’s coverage says that those products are unknown, not absent, and no finding for them closes until a scan can read them. The build alone does not always tell TigerGate which servicing branch to judge it by, so the branch is part of what is matched:

• SQL Server is judged on its GDR or its cumulative-update branch, told apart by the build ranges Microsoft publishes for each release. A GDR build is never judged by a cumulative-update fix, or the reverse. A build outside the ranges, such as SQL Server 2016 SP2 or earlier, is shown as not assessed.
• Exchange is judged within its cumulative update: a CU14 server against CU14’s security updates, a CU15 server against CU15’s.
• Office is judged against the build its own update channel received. Current Channel and Monthly Enterprise Channel share version numbers and differ in the last part of the build, so the channel decides. Microsoft does not publish a fixed build per channel through MSRC; TigerGate reads Microsoft’s Office security release notes for it. A channel with no published build list (Beta, Preview) is shown as not assessed, and so is a server whose channel change is still pending.
• .NET Framework is judged on its 4.x line and the Windows release it runs on.
• .NET runtimes are judged against Microsoft’s own .NET release metadata. On Windows this replaces the Trivy match for the same install, so one runtime is never reported twice.

Each finding is one install and one update, listing the CVEs the update closes, with the KB (where Microsoft names one), the installed build and the fixed build. Office has no KB: the fixed build is the fix. Not covered: Office 2016 and other Windows Installer (MSI) Office installations. Microsoft publishes their fixes per application as a single suite-level build, and which application a CVE concerns is only in the CVE’s free-text title, so they are not assessed. Office 2016 and 2019 left support in October 2025.

​

Where the agent searches

The agent searches the whole local disk, except the operating system’s and package manager’s own directories. It searches in this order, so that if a scan reaches a limit, what is cut short is the least likely place for server software:

1. Directories you named with --app-path and --runtime-home.
2. Locations found from what the server runs (see below).
3. The usual application directories.
4. The rest of the local disk.
5. Home directories.

The agent also finds applications from what the server runs:

• Running processes: the executable (a JDK at /u01/jdk1.8.0_202 from /u01/jdk1.8.0_202/bin/java), a JVM’s -jar, -cp and -D<name>.home arguments, and a script’s directory (node server.js, python app.py).
• Service definitions: systemd units on Linux, services on Windows, launchd daemons on macOS.
• Environment variables: JAVA_HOME, JRE_HOME, JDK_HOME, CATALINA_HOME, CATALINA_BASE, JBOSS_HOME, WILDFLY_HOME, DOTNET_ROOT, PYTHONHOME, NODE_HOME, WL_HOME, WEBLOGIC_HOME, MW_HOME, ORACLE_HOME, WAS_HOME, WLP_INSTALL_DIR, and the home variables of common Java servers (Kafka, Elasticsearch, Solr, Jenkins, Spark, Hadoop, Jetty, Cassandra and others).
• Application servers and databases: a JVM’s -Dweblogic.home, -Dwls.home and -Dwas.install.root, a Liberty server’s -jar .../bin/tools/ws-server.jar, and an Oracle Database bin/oracle (the OracleService service on Windows) beside an Oracle inventory. On Linux the agent usually cannot read another account’s process details, so an Oracle home owned by an oracle account is found by the disk search or with --runtime-home instead.
• Your options: directories given with --app-path and runtimes given with --runtime-home. See Install the agent on servers.

Every discovered location is remembered and searched on later scans until it is removed from disk. A batch job that runs once a night is still covered when it is not running, and its findings do not close and reopen between scans.

​

What is not searched

• The operating system’s own directories: /usr outside /usr/local, /var/lib and the other system directories under /var, /etc, /boot, /lib, /bin and /sbin on Linux; Windows and system folders on Windows; /System and /Library on macOS. Software there belongs to the package manager, whose packages are already assessed against the distribution’s advisories.
• Temporary and runtime directories: /tmp, /run, /proc, /sys and /dev.
• Network file systems (NFS, SMB/CIFS, Ceph, GlusterFS, sshfs and similar), container overlay file systems, and snap images. Container images are covered by container scanning.
• Data directories of databases and message brokers (PostgreSQL, MySQL, MariaDB, MongoDB, Elasticsearch, OpenSearch, Kafka). Outside the usual application directories, a directory with more entries than an application directory would hold is also skipped. Both are counted in the scan’s coverage details.
• Caches, download stores and version-control directories, for example .m2, .gradle, .npm, .cache, .nuget, .pnpm-store and .git. A Maven repository is a download history, not a deployment.

To search one of these, for example applications on an NFS share, name it with --app-path.

​

Directories the agent cannot read

On Linux the agent runs as the account that installed it, not root. A default directory it cannot open, such as /root or another account’s home, is skipped and counted in the scan’s coverage details as a fact. It does not stop findings from closing. A directory you named with --app-path that cannot be read is different: the scan is marked incomplete for application packages, and findings for them stay open until it can be read. For processes owned by another account, Linux shows the agent only the command line, so the agent learns about them from the command line and the service definition.

​

Hardening facts (Linux)

host_config reads kernel parameters, mount options, file permissions and owners, the SSH server configuration, service and kernel-module state, password, lockout and umask policy, audit and logging configuration, and firewall state. See Hardening for the checks. It never reports a secret. The shadow file is read only to count accounts with an empty password, never for a hash. The GRUB configuration is read only for whether a password is set. The sudoers file is read only for its Defaults lines.

​

Hardening facts (Windows)

On Windows, host_config reads Windows registry policy values under HKEY_LOCAL_MACHINE, which any account can read, and, with privileged mode, the local security policy, user rights and audit policy (secedit and auditpol). The registry values are a fixed list compiled into the agent, taken from the DISA STIG rules and Microsoft’s Group Policy reference. host_config never reads a path it is sent; the paths you choose are read only by custom_audit, below. A value that does not exist is not reported, which is what a policy that was never written looks like. A value the account is refused is marked, and only the controls that need it show Not assessed. To tell a server from a client, and a domain controller from a member server, the agent also reports the product type, the installation type, the product name and the build number. A Windows banner is reported only as whether one is set, never its text.

​

Custom audits

custom_audit fetches the audits assigned to the server and evaluates each check locally by reading a file, a registry value, a kernel parameter, a service’s start type or the package inventory the other collectors already built. It starts no process. Credential stores and key material are never read, and the evidence it reports never contains file contents. See Custom audits for the format, the deny-list and the limits.

​

Never collected

• File contents, beyond the version metadata and manifests listed above
• Command lines and environment values other than the paths and variables named above. Both often carry secrets such as -Ddb.password=… or AWS_SECRET_ACCESS_KEY. They are parsed in memory and discarded.
• Password hashes, keys, tokens or certificates
• Application data, logs or database contents

To see exactly what a server would report, run tigergate-agent scan --dry-run --pretty. It prints the full report without contacting TigerGate.