Skip to main content

File Integrity Module (Beta)

The File Integrity Module monitors critical and sensitive files by adding them to a protected list and preventing any write operations on these files. It is designed to stop attacks similar to the SolarWinds incident, where attackers compromised the build system to modify source code before compilation, thereby bypassing code signing mechanisms. This module is divided into two components:

  • Critical File Monitoring
  • Write Prevention Mechanism

Critical File Monitoring​

This is the core of the module. We are continuously enhancing its capabilities to detect modifications across a wide range of file types using sophisticated detection logic. Currently, we support two primary use cases for detecting critical files:

Source Code​

In response to the SolarWinds scenario, our goal is to prevent unauthorized modifications to source code during CI/CD builds. Although modifying source code during builds can sometimes be legitimate, it is not considered a best practice from a security perspective.

By analyzing process and file system events, we detect key git operations—such as git clone, git checkout, and git fetch, that introduce source code into the build environment. Once these commands create files on the system, those files are immediately marked as critical and monitored for any modifications.

For example, consider the following command executed in a CI/CD pipeline:

git clone git@github.com:myorg/myrepo

This command clones a repository containing multiple files into the working directory. As a result, every cloned file is protected. Therefore, if someone attempts to modify one of these files:

echo "malicious code" >> myrepo/package.json

the operation will be blocked.

Limitation

  • The module currently works with GitHub Actions (e.g., using actions/checkout) but is not yet supported for other runners that clone code outside the CI build environment (such as Jenkins or GitLab).
  • Submodules cloned alongside the main repository are not fully supported at this time.
  • While modifications to an existing file are blocked, completely replacing a file is still permitted. This is a security gap that will be addressed in future updates.

Artifacts​

Another critical use case is the protection of build artifacts. We monitor key processes responsible for creating these artifacts and, when a new artifact is generated, add it to our list of critical files. For example, consider the following command that builds a Golang executable:

go build -o simple-program

Cimon detects that this build process has created an artifact named simple-program and adds it to the monitored files. Consequently, any attempt to modify the artifact:

echo "malicious_byte_code >> simple-program

will be blocked, thereby mitigating a potential supply chain attack.

Write Prevention Mechanism​

To enforce protection, the module monitors all file open operations (e.g., via sys_open and similar syscalls) and verifies two conditions:

  • Whether the file inode is flagged as protected.
  • Whether the operation intends to write to the file.

If both conditions are met, the kernel immediately terminates the process attempting the write operation, similar to how network connections are blocked.