InfoCompromise indicatorsBLWK-FIM-003

Not covered by the file-integrity baseline: ‹path›

What this means

‹path› is present but has no recorded baseline hash, so Bulwark can tell that it exists but not whether it has been tampered with. This fires per-file, on purpose: the previous version keyed on whether a baseline existed at all, which meant that once you had baselined anything, a critical file you had never actually recorded — including one added to the watch list later — read as “verified clean” rather than “never checked”. A file nobody ever baselined is not a file known to be good.

How to fix it

Run bulwark fim baseline now, while you trust this host, to record a known-good hash for this file (add --privileged to also cover /etc/shadow and /etc/sudoers).

Check it yourself

Run a scan and look for BLWK-FIM-003 in the results:

bulwark scan

Installed the standalone CLI package instead of the app? The command is bulwarkctl.

How Bulwark decides

Bulwark reads file_integrity and reports this check when:

in_baseline == false and currently_present == true and unreadable == false

If a value can't be read, Bulwark reports the check as undetermined rather than passing it. View the rule source.

Related checks

• Shell history recording is suppressed · BLWK-EVASION-001
• File modified since baseline: ‹path› · BLWK-FIM-001
• File deleted since baseline: ‹path› · BLWK-FIM-002
• Credential file modified since baseline: ‹path› · BLWK-FIM-004
• Credential file deleted since baseline: ‹path› · BLWK-FIM-005
• Credential file not covered by the baseline: ‹path› · BLWK-FIM-006