Sentinel

File integrity monitoring CLI for financial compliance.

Sentinel tracks file changes across your infrastructure by computing cryptographic hashes and maintaining a baseline. When files are added, deleted, modified, or have their permissions changed, Sentinel detects it and generates audit-ready reports.

Built for environments requiring SOX, PCI-DSS, or HIPAA compliance, where file integrity monitoring (FIM) is a mandatory control.

Why File Integrity Monitoring?

Regulatory frameworks require organizations to detect unauthorized changes to critical system files:

• PCI-DSS Requirement 11.5 mandates file integrity monitoring for cardholder data environments
• SOX Section 404 requires controls over financial reporting systems, including change detection
• HIPAA Security Rule requires audit controls to track access and modifications to ePHI systems
• NIST SP 800-53 SI-7 specifies file integrity verification as a security control

Sentinel provides a lightweight, auditable solution without the complexity of enterprise FIM tools.

Features

• Dual hashing: SHA-256 (FIPS 140-2 compliant) and BLAKE3 (high performance)
• Change detection: Identifies additions, deletions, content modifications, and permission changes
• Compliance reports: JSON, HTML, and plain text output formats
• Ignore rules: .sentinelignore files (gitignore-style syntax) to exclude paths
• Single binary: No runtime dependencies, no agents, no daemons
• Audit trail: Timestamped baselines with cryptographic verification

Installation

From source

git clone https://github.com/stabrea/sentinel.git
cd sentinel
cargo build --release
cp target/release/sentinel /usr/local/bin/

Prerequisites

• Rust 1.70+ (curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh)

Usage

Initialize monitoring

Create a baseline of the current directory state:

# Default SHA-256
sentinel init /path/to/monitor

# Use BLAKE3 for faster hashing on large datasets
sentinel init /path/to/monitor --algorithm blake3

Scan for changes

Compare current state against the baseline:

sentinel scan /path/to/monitor

# Update baseline after reviewing changes
sentinel scan /path/to/monitor --update

Generate compliance reports

# Plain text (terminal)
sentinel report /path/to/monitor

# JSON (for SIEM integration)
sentinel report /path/to/monitor --format json -o audit-report.json

# HTML (for compliance documentation)
sentinel report /path/to/monitor --format html -o report.html

Verify a single file

sentinel verify /path/to/monitor/config.yml --base /path/to/monitor

Ignore files

Create a .sentinelignore file in the monitored directory:

# Logs and temp files
*.log
*.tmp
tmp/

# Build artifacts
target/
node_modules/

# Keep this specific log
!audit.log

Example Output

ALERT 3 change(s) detected:

  [+] config/database.yml    New file (2048 bytes)
  [~] config/app.yml         Content changed: b94d27b99345 -> a1b2c3d4e5f6 (512 -> 518 bytes)
  [-] tmp/cache.db           File removed (was 4096 bytes)

  1 added, 1 deleted, 1 modified, 0 permission changes, 47 unchanged

Architecture

src/
  main.rs       CLI entry point (clap)
  scanner.rs    Directory traversal and file hashing
  baseline.rs   Baseline storage, loading, and diff comparison
  report.rs     Report generation (JSON, HTML, text)
  ignore.rs     .sentinelignore pattern matching

Baselines are stored as JSON in .sentinel/baseline.json within the monitored directory. Each entry records the file path, cryptographic hash, size, Unix permissions, and modification timestamp.

Integration

Cron job for continuous monitoring

# Scan every hour, alert on changes
0 * * * * /usr/local/bin/sentinel scan /critical/path 2>&1 | grep -q "ALERT" && mail -s "FIM Alert" security@company.com

CI/CD pipeline check

- name: Verify file integrity
  run: sentinel scan /deployed/app --format json

License

MIT