Summary
A rule file passed through --yara-rules-dir that YARA cannot compile, or that SkillSpector cannot decode as UTF-8, is dropped whole and nothing is printed at the default log level. The report still says static_yara: completed and analysis_completeness: complete, the recommendation stays SAFE, and --fail-on-incomplete exits 0. Anyone gating a pipeline on their own detections gets a green scan from rules that never ran.
Environment
- SkillSpector 2.11.2 built from source at
9749372 (current main)
- Windows 10 19045, CPython 3.12.4, yara-python 4.5.4, console code page cp950
- Same result on Ubuntu 24.04 (WSL2), CPython 3.12.3, yara-python 4.5.4, clean non-editable install of the same commit
Reproduction
mkdir -p demo-skill rules-ok rules-typo
printf -- '---\nname: demo-skill\ndescription: demo skill for a custom YARA rule\n---\nThis skill body contains ACME_CANARY_TOKEN_123.\n' > demo-skill/SKILL.md
cat > rules-ok/acme.yar <<'EOF'
rule acme_canary
{
meta:
category = "malware"
description = "custom canary"
strings:
$a = "ACME_CANARY_TOKEN_123"
condition:
$a
}
EOF
sed 's/^ \$a$/ $a and/' rules-ok/acme.yar > rules-typo/acme.yar # breaks line 9; YARA reports it at line 10, the closing brace
skillspector scan demo-skill --no-llm --fail-on-incomplete --yara-rules-dir rules-ok --format json -o ok.json; echo "ok exit=$?"
skillspector scan demo-skill --no-llm --fail-on-incomplete --yara-rules-dir rules-typo --format json -o typo.json; echo "typo exit=$?"
Output (identical on Windows and Linux; fields read back from the JSON reports):
ok exit=0
typo exit=0
ok CAUTION [('YR1', 'CRITICAL')] static_yara=completed completeness=complete
typo SAFE [] static_yara=completed completeness=complete
The only trace is below the default log level:
SKILLSPECTOR_LOG_LEVEL=DEBUG skillspector scan demo-skill --no-llm --yara-rules-dir rules-typo ...
DEBUG [skillspector.nodes.analyzers.static_yara] static_yara: skipping acme: line 10: syntax error, unexpected '}'
INFO [skillspector.nodes.analyzers.static_yara] static_yara: compiled 5 YARA rule file(s) (1 skipped)
Expected vs actual
Expected: a rule file that does not load is reported at the default log level, and the scan does not claim the YARA analyzer completed.
Actual: no output at all, static_yara: completed, complete, SAFE, exit 0.
Two more triggers with the same outcome:
- A UTF-8 BOM at the start of the rule file. YARA rejects it (
line 1: non-ascii character), and Set-Content -Encoding UTF8 in Windows PowerShell 5.1 (5.1.19041.6456) writes ef bb bf, so this is easy to hit when authoring rules on Windows.
- A non-UTF-8 byte in a comment, for example cp1252
ü. yara.compile(filepath=...) accepts that file, SkillSpector discards it and logs skipping malformed encoded rule <path>: 'utf-8' codec can't decode byte 0xfc .... That message names encoded rules but also fires for a plain .yar.
For contrast, other rule-load problems are visible: a missing --yara-rules-dir warns at the default level, and a rule file over 1 MiB yields static_yara: degraded, completeness: partial, exit 1.
src/skillspector/nodes/analyzers/static_yara.py:383 per-source compile failure goes to logger.debug
src/skillspector/nodes/analyzers/static_yara.py:356 decode failure goes to logger.debug
src/skillspector/nodes/analyzers/static_yara.py:425 the skipped count is only an INFO total and never reaches the ledger or the analyzer status
Proposed fix
Log each skipped rule file at WARNING with its path and reason, and record the skip in the inspection ledger with LedgerOutcome.PARTIAL so static_yara reports degraded and --fail-on-incomplete exits 1, matching what the rule size limit already does (that status follows from any PARTIAL/SKIPPED event regardless of reason code). Either reuse the existing LedgerReason.RULES_UNAVAILABLE, or add a more precise reason if its message ("rules were unavailable before execution") reads wrong for a single skipped file among several that loaded fine.
One design question: should any skipped rule file degrade the scan, or only files from --yara-rules-dir? Happy to open the PR with tests if you agree with the approach.
Summary
A rule file passed through
--yara-rules-dirthat YARA cannot compile, or that SkillSpector cannot decode as UTF-8, is dropped whole and nothing is printed at the default log level. The report still saysstatic_yara: completedandanalysis_completeness: complete, the recommendation stays SAFE, and--fail-on-incompleteexits 0. Anyone gating a pipeline on their own detections gets a green scan from rules that never ran.Environment
9749372(currentmain)Reproduction
Output (identical on Windows and Linux; fields read back from the JSON reports):
The only trace is below the default log level:
Expected vs actual
Expected: a rule file that does not load is reported at the default log level, and the scan does not claim the YARA analyzer completed.
Actual: no output at all,
static_yara: completed,complete, SAFE, exit 0.Two more triggers with the same outcome:
line 1: non-ascii character), andSet-Content -Encoding UTF8in Windows PowerShell 5.1 (5.1.19041.6456) writesef bb bf, so this is easy to hit when authoring rules on Windows.ü.yara.compile(filepath=...)accepts that file, SkillSpector discards it and logsskipping malformed encoded rule <path>: 'utf-8' codec can't decode byte 0xfc .... That message names encoded rules but also fires for a plain.yar.For contrast, other rule-load problems are visible: a missing
--yara-rules-dirwarns at the default level, and a rule file over 1 MiB yieldsstatic_yara: degraded,completeness: partial, exit 1.Where (at 9749372)
src/skillspector/nodes/analyzers/static_yara.py:383per-source compile failure goes tologger.debugsrc/skillspector/nodes/analyzers/static_yara.py:356decode failure goes tologger.debugsrc/skillspector/nodes/analyzers/static_yara.py:425the skipped count is only an INFO total and never reaches the ledger or the analyzer statusProposed fix
Log each skipped rule file at WARNING with its path and reason, and record the skip in the inspection ledger with
LedgerOutcome.PARTIALsostatic_yarareportsdegradedand--fail-on-incompleteexits 1, matching what the rule size limit already does (that status follows from anyPARTIAL/SKIPPEDevent regardless of reason code). Either reuse the existingLedgerReason.RULES_UNAVAILABLE, or add a more precise reason if its message ("rules were unavailable before execution") reads wrong for a single skipped file among several that loaded fine.One design question: should any skipped rule file degrade the scan, or only files from
--yara-rules-dir? Happy to open the PR with tests if you agree with the approach.