Maintainer: Omar Rao — Cybersecurity, Privacy and Resilience Expert · LinkedIn · Substack
Repository: OmarRao/secure-scope
Effective date: 2026-06-12
Policy version: 2.0.0

1. Supported Versions
2. Reporting a Vulnerability
3. Disclosure Policy
4. Scope
5. Out of Scope
6. Severity Classification
7. Response SLA
8. Security Architecture
9. Secure Coding Standards
10. Dependency Management
11. Secret & Credential Handling
12. Ransomware & APT Threat Response
13. Data Protection & Resilience Requirements
14. YARA Rule Governance
15. Incident Response
16. Security Contacts

Only the latest release receives security patches. Older versions are not supported.

Users running any version below v2.0.0 are strongly encouraged to upgrade immediately. Breaking changes between major versions are documented in the Releases page.

Do not open a public GitHub issue for security vulnerabilities. Public disclosure before a patch is available puts all users at risk.

1. GitHub Private Security Advisory (preferred)
   Use the Security Advisories tab in this repository to submit a confidential report. GitHub keeps the details private until a fix is released.

2. Email (alternative)
   Send a detailed report to the maintainer. Include [SECURITY] in the subject line. Encrypt sensitive reports using the maintainer's public PGP key (available on request).

Please provide as much detail as possible to help us reproduce and fix the issue quickly:

• Affected component — which file, module, or endpoint
• Vulnerability type — e.g. RCE, SSRF, path traversal, injection, auth bypass
• Steps to reproduce — minimal, numbered steps from a clean state
• Proof of concept — code snippet, curl command, or screenshot (if safe to share)
• Impact assessment — what an attacker could achieve
• Suggested fix — if you have one
• Your SecureScope version — output of git log --oneline -1
• Environment — OS, Python version, Docker version (if applicable)

Reports submitted without reproduction steps may be deprioritised. We will acknowledge receipt within 48 hours and provide an initial assessment within 5 business days.

SecureScope follows Coordinated Vulnerability Disclosure (CVD):

1. Reporter submits a private report via GitHub Security Advisory or email.
2. Maintainer acknowledges receipt within 48 hours.
3. Maintainer investigates, confirms severity, and assigns a CVE if warranted.
4. A patch is developed and tested in a private branch.
5. A patched release is published.
6. A GitHub Security Advisory is published with full details, credit, and CVE reference.
7. Reporter is credited in the advisory unless they request anonymity.

Maximum embargo period: 90 days from the date of initial report. If a fix is not available within 90 days, the maintainer will coordinate with the reporter on whether to extend the embargo or proceed with partial disclosure.

We will never take legal action against researchers who report in good faith and follow this policy.

The following are in scope for vulnerability reports:

The following are not eligible for vulnerability reports:

• Vulnerabilities in the target repositories being scanned — SecureScope analyses external code; findings in that code are the tool's intended output, not a vulnerability in SecureScope itself.
• Bugs requiring physical access to the host machine.
• Denial of service against the development server (--allow-unsafe-werkzeug) when it is correctly documented as not production-safe.
• Self-XSS (where the attacker can only attack themselves).
• Issues in third-party dependencies that do not affect SecureScope's attack surface — please report those directly to the dependency maintainers.
• Missing security headers on the development server (X-Frame-Options, CSP, etc.) — these are known and documented. SecureScope is not designed to run as a public-facing production service without a reverse proxy.
• Rate limiting on the local development server.
• Vulnerabilities that require the attacker to already have administrator or root access to the host.

SecureScope uses the CVSS v3.1 scoring system for severity classification. Severity determines patch SLA (see Section 7).

If a CRITICAL vulnerability is actively exploited in the wild, the SLA is 48 hours for an emergency patch release regardless of completeness.

┌─────────────────────────────────────────────────────────────┐
│  User Browser                                                │
│  (Untrusted input: GitHub URL, LLM API key, scan options)   │
└───────────────────────┬─────────────────────────────────────┘
                        │ WebSocket + REST (localhost only)
┌───────────────────────▼─────────────────────────────────────┐
│  Flask + Socket.IO Server  (ui/server.py)                    │
│  Validates: URL format, path sanitisation, API key masking   │
└───┬───────────────┬──────────────────┬───────────────────────┘
    │               │                  │
    ▼               ▼                  ▼
┌───────┐    ┌───────────┐    ┌─────────────────┐
│ Git   │    │  Semgrep  │    │ Docker Sandbox  │
│ clone │    │  process  │    │ (--network=none │
│ (tmp) │    │           │    │  --read-only)   │
└───────┘    └───────────┘    └─────────────────┘
    │
    ▼ (cleaned up after scan)
┌──────────────────────────────┐
│  Temp directory (OS-managed) │
│  Auto-deleted after scan     │
└──────────────────────────────┘

All contributions to SecureScope must adhere to the following:

• No shell=True in any subprocess call. Use list form: subprocess.run(["git", "clone", url, dest]).
• No eval() or exec() on any data originating from user input or scanned repositories.
• Use pathlib.Path for all file path operations. Call .resolve() before any file read/write and validate the resolved path is within the expected directory.
• Never log secrets. API keys, tokens, and passwords must be masked in logs (replace with ***).
• Use tempfile.mkdtemp() for all temporary directories. Always clean up in a finally block.
• Validate all external inputs. GitHub URLs must match the pattern https://github.com/<owner>/<repo> before any operation is performed.
• Pin dependency versions in requirements.txt. Use exact versions (==) not ranges (>=).

• Auto-escaping is mandatory. Never use | safe on user-supplied data.
• JSON serialise any data passed from Python to JavaScript using | tojson.
• Never inject raw repository content (commit messages, file names, descriptions) directly into HTML without escaping.

• No innerHTML on untrusted data. Use textContent or createElement/appendChild.
• No eval(). Use JSON.parse() for JSON, not eval().
• Sanitise DOM insertations from API responses using textContent assignments.

• Sandbox containers must always run with:
  • --network=internal (no internet access)
  • --memory=512m
  • --pids-limit=128
  • --read-only (read-only root filesystem)
  • --cap-drop=ALL
  • --security-opt=no-new-privileges

• YARA rules must not use include directives pointing to external or user-supplied paths.
• Rule strings must be reviewed to avoid catastrophic backtracking (ReDoS in regex conditions).
• All new rule files must include a header comment block with: author, date, threat family, and a description of what the rule detects.

• All Python dependencies are pinned in requirements.txt using exact versions.
• pip-audit is run as part of every scan (check_dependency_vulns() in analyzer.py) to detect CVEs in scanned repositories' dependencies.
• SecureScope's own dependencies are audited before each release using:

  pip-audit -r requirements.txt

• Dependencies with known critical or high CVEs will block a release.
• No dependency may be added without a documented justification in the PR description.
• Transitive dependencies are reviewed using pip-audit --fix --dry-run before major releases.

• No unpinned git+ or http+ dependencies are permitted.
• All packages must be sourced from PyPI only (no custom registries).
• The yara-python optional dependency is clearly documented as optional so users who do not need YARA scanning are not exposed to that attack surface.

SecureScope handles several types of secrets at runtime. The following rules apply unconditionally:

Developers must never commit secrets. A .gitignore entry covers .env, *.key, *.pem, and reports/. Pre-commit hooks are recommended:

pip install pre-commit detect-secrets
pre-commit install

As a tool that analyses ransomware indicators, SecureScope itself must be defended against the threats it detects.

1. Isolate immediately. Disconnect from the network. Do not attempt to clean the system in place.
2. Preserve evidence. Take a memory dump and disk image before shutting down.
3. Check scan outputs. Verify that no scanned repository executed malicious code outside the Docker sandbox.
4. Rotate all secrets. Revoke and reissue all LLM API keys, GitHub PATs, and any other credentials that were present in environment variables or in-memory during the session.
5. Review Docker logs. Inspect sandbox container logs for evidence of breakout attempts.
6. Report to maintainer. If the compromise may have affected the tool's integrity (e.g., a supply chain attack on a dependency), notify the maintainer immediately via the private reporting channel.

SecureScope's threat intelligence database (threat_intel.py) tracks APT groups known to target development environments and CI/CD pipelines. If SecureScope detects any of the following in a scanned repository, treat the finding as potentially indicative of a targeted attack rather than opportunistic malware:

• Volt Typhoon, APT29/Cozy Bear, Lazarus Group, Scattered Spider

See THREAT_DB in threat_intel.py for full TTPs and IOCs.

SecureScope processes sensitive data (code, API keys, security findings). The following data protection requirements apply to anyone operating SecureScope in an enterprise environment:

For any environment where SecureScope report outputs are retained:

• 3 copies of report data
• 2 different storage media types
• 1 copy offsite or in a separate cloud region
• 1 copy air-gapped or offline
• 0 errors verified by automated restore testing

• SecureScope is designed for local or intranet use only. Do not expose port 5001 directly to the internet.
• If deploying behind a reverse proxy (nginx, Caddy), enforce TLS 1.2+, HSTS, and rate limiting.
• Restrict access to the reports/ directory. Reports may contain sensitive code and vulnerability details.
• Enable OS-level audit logging on the machine running SecureScope.
• Review YARA scanner target path inputs — only scan paths within expected backup directories.

SecureScope ships with 6 predefined YARA rule sets in the yara_rules/ directory. The following governance rules apply:

A YARA rule will be accepted into the official rule set if it meets all of the following:

1. Header block present — includes rule name, author, date, threat family, and description.
2. No external includes — rules must be self-contained.
3. No ReDoS-prone regex — all regex conditions reviewed for catastrophic backtracking.
4. Tested against known-clean samples — the rule must not fire on common benign files (false positive rate < 0.1%).
5. Tested against known-malicious samples — the rule must fire on at least one confirmed sample of the target threat.
6. Referenced to a public threat report — a link to a public malware analysis (e.g., CISA advisory, vendor report) must be included in the rule comment.
7. Severity assigned — CRITICAL, HIGH, or MEDIUM meta field present.

• YARA rules are reviewed and updated with each SecureScope minor release (v2.x.0).
• Emergency rule updates for actively exploited threats may be shipped as patch releases (v2.0.x).
• Rules for a threat actor that has been inactive for more than 24 months may be deprecated but are never deleted.

If a YARA rule produces false positives in your environment:

1. Open a GitHub Issue with the rule name, file type, and a sanitised sample of the matching content (no sensitive data).
2. Label the issue yara-fp.
3. A rule update will be prioritised in the next patch release.

• Take the service offline immediately if externally exposed
• Preserve all logs and memory artifacts
• Rotate all credentials and revoke all tokens
• Notify all known users via GitHub Security Advisory
• Begin root cause analysis
• Publish emergency patch release
• Publish post-incident report within 7 days

• Assess whether active exploitation is occurring
• Develop and test a patch in a private branch
• Coordinate disclosure with reporter
• Publish patched release
• Publish Security Advisory with CVE

• Confirm and reproduce the issue
• Schedule fix for next regular release
• Update Security Advisory after patch ships

For P1/P2 incidents requiring immediate attention, report via GitHub Security Advisories. Include [P1-INCIDENT] or [P2-INCIDENT] in the advisory title.

We thank all security researchers who responsibly disclose vulnerabilities. Contributors who report valid security issues will be credited by name (or pseudonym, if preferred) in the Security Advisory for the patched release.

This security policy is reviewed and updated with each major SecureScope release. Significant changes to the policy will be communicated via the Releases page and noted in the commit history of this file.

SecureScope Security Policy — maintained by Omar Rao, Cybersecurity, Privacy and Resilience Expert.
LinkedIn · Substack