Transparency
Scan Methodology
How Sigil analyses packages, what it detects, and what its limitations are. This page exists so that every verdict we publish is traceable to a documented process.
Static Analysis Only
Sigil uses automated static pattern analysis. Code is never executed during scanning. There is no runtime execution, no manual audit, and no penetration testing.
Packages are downloaded, unpacked into a quarantine directory, and analysed against defined detection rules. The quarantine is destroyed after scanning.
Pattern / Signature Detection
Scans match code against defined detection rules targeting known malicious patterns — install hooks, credential access, obfuscation, network exfiltration, and more. Detection rules are maintained internally and updated as new attack techniques are identified.
Point-in-Time Analysis
Each scan represents analysis of a specific version at a specific time. Results do not reflect changes made after scanning. A scan result from January does not speak to the state of a package in February.
No Continuous Monitoring
Sigil does not watch packages for changes. Rescans occur on schedule or on-demand. Between scans, a package may be updated with new code that Sigil has not yet analysed.
False Positive / False Negative Risk
Automated analysis may flag legitimate patterns (false positives) or miss novel attack techniques (false negatives). No scanning tool achieves 100% accuracy.
Sigil is designed to detect known malicious patterns — not to certify safety. A LOW RISK result means no known malicious patterns were detected, not that the package is safe.
Detection Criteria
Sigil scans across six phases. Each phase carries a severity weight that affects the final risk score.
Install Hooks
setup.py cmdclass, npm postinstall, Makefile targets. Install hooks that execute arbitrary code during package installation are the highest-risk vector.
Code Patterns
eval(), exec(), pickle.loads, child_process. Dynamic code execution primitives that can be abused to run arbitrary payloads.
Network / Exfiltration
Outbound HTTP, webhooks, sockets, DNS tunnelling. Network calls in packages that shouldn't need them are strong indicators of data exfiltration.
Credentials
ENV vars, .aws, .kube, SSH keys, API key patterns. Code that reads credential stores or environment variables containing secrets.
Obfuscation
Base64, charCode, hex encoding, minified payloads. Deliberate obfuscation of code logic is a strong indicator of concealed malicious behaviour.
Provenance
Git history, author count, binary files, hidden files. Metadata signals about package trustworthiness and supply chain integrity.
Prompt Injection
AI agent instruction injection, system prompt overrides. Detects attempts to manipulate AI agents through malicious prompt content embedded in packages or tool descriptions.
Skill Security
MCP permission escalation, undeclared tool capabilities. Identifies MCP servers and skills that request excessive permissions or contain undisclosed capabilities.
Verdict Scale
Risk levels indicate detection results only and are not safety ratings or certifications.
Dispute Process
Package authors who believe their package has been incorrectly flagged may request a review by contacting security@sigilsec.ai or opening a dispute through the scan report page.
External Scanner Integration
When available, Sigil integrates results from established open-source security tools to supplement its own detection:
- —Semgrep — custom and community rulesets for code patterns
- —Bandit — Python-specific security analysis
- —TruffleHog — secret and credential detection
- —npm audit — known vulnerability lookups for npm packages
- —Safety — known vulnerability lookups for Python packages
What Sigil Is Not
- —Sigil is not a security certification body
- —Sigil does not perform manual code audits
- —Sigil does not execute code during scanning
- —Sigil does not provide professional security advice
- —Sigil does not assert malicious intent by any author
- —A LOW RISK verdict is not a guarantee of safety