How SCA works

Each agent has its own local database where it stores the current state of each check: passed, failed, or not-applicable, allowing agents to only send the differences detected between scans. If there has been no change, only the scan summary event will be sent, thus avoiding unnecessary network traffic while keeping the manager up to date. The manager will then use those updates to issue alerts that will be shown in the Kibana App.

Integrity and alerting flow is depicted in the sequence diagram below.

SCA integrity and alerting flow

Scan Results

Any given check event has three possible results (passed, failed, and not applicable). This result is determined by the set of rules and the rule result aggregator of the check.

Take the following check from policy cis_debian9_L2.yml as an example:

- id: 3511
  title: "Ensure auditd service is enabled"
  description: "Turn on the auditd daemon to record system events."
  rationale: "The capturing of system events provides system administrators [...]"
  remediation: "Run the following command to enable auditd: # systemctl enable auditd"
    - cis: ["4.1.2"]
    - cis_csc: ["6.2", "6.3"]
  condition: all
    - 'c:systemctl is-enabled auditd -> r:^enabled'

After evaluating the aforementioned check, the following event is generated:

  "type": "check",
  "id": 355612303,
  "policy": "CIS benchmark for Debian/Linux 9 L2",
  "policy_id": "cis_debian9_L2",
  "check": {
    "id": 3511,
    "title": "Ensure auditd service is enabled",
    "description": "Turn on the auditd daemon to record system events.",
    "rationale": "The capturing of system events provides system administrators [...]",
    "remediation": "Run the following command to enable auditd: # systemctl enable auditd",
    "compliance": {
      "cis": "4.1.2",
      "cis_csc": "6.2,6.3"
    "rules": [
      "c:systemctl is-enabled auditd -> r:^enabled"
    "command": "systemctl is-enabled auditd",
    "result": "passed"

The result is passed because the rule found "enabled" at the beginning of a line in the output of command systemctl is-enabled auditd.


A check will be marked as not applicable in case an error occurs while performing the check. In such cases, instead of including the field result, fields: status and reason will be included.

Integrity mechanisms

To ensure integrity between agent-side and manager-side states, for that particular agent, two integrity mechanisms have been included in SCA, one for policy files and the second for scan results.

Integrity of policy files

This mechanism is in charge of keeping policy files and scan results aligned. Whenever a change in a policy files is detected, SCA will invalidate the results stored in the database for that policy and request a fresh dump of them.

In a nutshell, whenever the hash of a policy file changes, the recovery steps performed are:

  1. A message appears in the manager log file, e.g:

    INFO: Policy 'cis_debian9_L2' information for agent '002' is outdated. Requested latest scan results.
  2. The manager flushes its stored data for that policy.

  3. The agent sends the scan results for that policy.

  4. The manager updates its database, and fires alerts for the new scan results.


Alerts for every check result of the updated policy will be fired. This way, false negatives are avoided.

Integrity of the scan results

To illustrate how the integrity of scan results is kept, we will use an example in which the agent-side database and the manager-side differ. This scenario could happen due to, for instance, a network issue.

States stores in the Agent and Manager sides

Check ID

Agent-side state

Manager-side state













For those databases, the corresponding SHA256 hashes are:

Agent:   1642AB1DC478052AC3556B5E700CD82ADB69728008301882B9CBEE0696FF2C84
Manager: B43037CA28D95A69B6F9E03FCD826D2B253A6BB1B6AD28C4AE57A3A766ACE610

Given that the two hashes do not match, the manager will request the agent for its latest scan data, and refresh its database with the newly received status information.