Skip to content

Static v2.11.1: distinguish inert security-test strings and taxonomy labels from executable behavior in findings #523

Description

@CyberStrategy1

We integrated SkillSpector as an attributed independent evidence provider in
AI SAFE². Thank you for exposing coverage and degraded-analysis status explicitly;
those fields are important to our downstream review process.

Environment and scope

  • SkillSpector v2.11.1, pinned source revision
    704bc9544260c2f41222dc0f92982521709496ab.
  • Windows; Python 3.13.14; scan TARGET --format json --no-llm.
  • Scan date: 2026-09-09. No target skill/test code executed by us.
  • Model credentials were not forwarded. Static mode is not a claim of zero
    network access: supply-chain lookups can contact OSV.
  • Public target: AI SAFE²'s tracked skills/ tree at
    6455eec76caec259ba3f9b902a4ab24f27b34263.
  • This is a version-pinned observation, not a claim that every subsequent
    upstream revision is affected.

Observed result

The tracked-source snapshot produced 50 issues and a risk assessment of
100 / CRITICAL / DO_NOT_INSTALL. A separate development checkout also produced
50 issues. Our clean and inert-hostile controls produced zero and seven issues,
respectively. These counts are not a calibrated precision or recall benchmark.

Several explanations appear to infer executable behavior from inert content:

  1. Prompt-injection strings in sanitizer regression tests are test inputs, with
    assertions about sanitization. A lexical match should not itself establish
    that the package follows those instructions.
  2. The self_modification risk-taxonomy key describes a risk being assessed;
    it is not an operation that modifies the program or its policy.
  3. The similarity between the package names uvicorn and gunicorn is insufficient
    on its own to establish typosquatting.
  4. An environment-derived health-check URL is not itself a credential. Any
    exfiltration explanation should identify the actual sensitive source and sink.

Important caveat: some smoke tests send bearer tokens to a configured URL.
Their transport/destination validation merits separate review. We are not asking
for all test-path findings to be suppressed or claiming every finding is false.
Coverage warnings, degraded OSV checks, and unresolved references are genuine
limitations and should remain visible.

Reproduction

Recommend using a clean, disposable directory and isolated environment. Install the pinned scanner from its official source, not an unpinned dependency set. The source pin
does not itself pin all transitive dependencies.

git clone https://github.com/CyberStrategyInstitute/ai-safe2-framework.git safe2-repro
git -C safe2-repro archive --format=zip --output=../safe2-skills.zip 6455eec76caec259ba3f9b902a4ab24f27b34263 skills

Extract that public-source archive into a new specimen directory using your
platform's archive utility. Scan only; do not install or execute specimen code:

skillspector --version
skillspector scan specimen/skills --format json --no-llm --output report.json

The historical count is environment-dependent, particularly for network checks;
the useful reproduction target is the particular finding explanation and source
context, not an invariant total of 50. A fresh minimal specimen and current-main
comparison have not yet been run for this upstream submission.

Requested improvement / questions

  • Distinguish lexical pattern matches, data-flow evidence, and confirmed
    executable behavior in the explanation and confidence semantics.
  • Consider syntax/data-flow context for inert strings and taxonomy definitions.
  • Preserve raw findings and coverage independently from reviewed dispositions.
  • Add paired regression cases: inert test input versus active instruction/code,
    including malicious content placed under a test-like path.
  • Do not exempt tests/, private IPs, or loopback wholesale: those are not trust
    boundaries. Baselines should be reviewer-controlled and narrowly scoped.
  • Is this already covered by an existing issue, recommended baseline workflow,
    or a newer analyzer revision? We can help supply focused specimens.

Our integration preserves SkillSpector's original score and recommendation. We
do not rewrite those into approval or claim NVIDIA endorsement or conformance.

Public supporting analysis

AI SAFE² second-pass findings and limitations

Related reports

Related: #37 (text-content false positives), #314 (security-test patterns flagged), and #103 (earlier static documentation findings). This report supplies a pinned v2.11.1 AI SAFE2 specimen and distinguishes specific explanation/precision concerns from genuine coverage limitations. Please consolidate if an existing issue is the preferred tracking location.

Activity

  1. agentsope commented on Sep 13, 2026

    @agentsope
    Contributor

    Opened #530 to address the uvicorn/gunicorn SC6 false positive, with regression tests. This only addresses the typosquatting observation; the other findings in this issue remain out of scope.

  2. Spectorian commented on Sep 29, 2026

    @Spectorian
    Collaborator

    A few more examples of findings that infer behavior from vocabulary alone:

    • API reference: https://api.example.com/ emits E1 External Transmission although it supplies no send operation.
    • Explicit sibling-skill workflow references are reported as AS3 snooping. The cited public example names the skills needed by that workflow; it does not establish a search for secrets or an authorization violation.
    • A function assigning prompt = "A blue circle" and returning that local value emits P6. The variable name alone does not establish protected system-prompt extraction.
    • Using Chrome exposes cookies. Use a separate Chrome profile. emits HIGH YR1 through the built-in info_stealer signature. This is safety advice, not credential theft.

    The E1/P6/YARA examples reproduce in direct detector tests. The sibling-skill case was checked against the full source linked below. A skill can still describe a risky capability, and its own claim of authorization is not enough to establish permission.

    Regression coverage should pair these with instructions to send data, search credential directories, reveal the system prompt or steal credentials. Documentation, comments and test files still need inspection.

    PR #658 covers narrower prohibition and install cases; PR #608 covers ransomware-payment prose. The examples above need additional handling. E2 environment pass-through is tracked separately in #441 / PR #492.

    Related examples in public skills:

    Some examples do include real capabilities or configuration changes. Findings should describe those accurately and distinguish them from claims of covert or malicious behavior that the source does not support.

    Relevant code

    static_patterns_data_exfiltration.py:45, static_patterns_agent_snooping.py:107, static_patterns_system_prompt_leakage.py:58, static_yara.py:445.

  3. rng1995 commented on Oct 8, 2026

    @rng1995
    Collaborator

    Merge-state update checked on 2026-10-08: PR #608 has merged its narrow ransomware-payment-prose fix. PR #787 also merged handling for proven path exclusions in ignore files.

    Keeping this broader report open. Fresh offline detector checks on main 8f4ca7d6 still report E1 for a bare API-reference URL and P6 for a function returning an innocuous local prompt value. The inert-input, taxonomy, and evidence-context concerns are not collectively resolved by these narrow fixes. Existing unrelated findings are not being suppressed to mark the issue complete.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions