NVIDIA / NVIDIA/SkillSpector

Custom YARA rules that fail to compile are dropped silently: static_yara still reports completed and SAFE

Open
#554 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
17.9k
Forks
1.5k
Avg merge
5d 10h
Merged PRs (30d)
66

Description

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.

Where (at 9749372)
  • 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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in src/skillspector/nodes/analyzers/static_yara.py at lines 356, 383, and 425, then compare the existing rule-size-limit handling that produces a degraded status. Reproduce the malformed-rule command from the issue and trace how skipped files reach the inspection ledger. Done means skipped files are warned about, the analyzer reports degraded with partial completeness, and --fail-on-incomplete exits 1; add tests for the reported compile and decode failures.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
security
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
70/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.