We release security updates for the following versions:

Always use the latest version of STRIDE GPT for the best security.

Choose Report a vulnerability on the Security tab for the affected code.

• For a change specific to Nexus, use the Nexus Security tab.
• If the issue also affects upstream STRIDE-GPT, use the upstream Security tab.

Include the affected revision, reproduction steps, impact and any proposed fix in the private report. Keep details out of public branches, commits, issues and pull requests until a fix is released. See the security workflow for how maintainers coordinate fixes.

We will acknowledge receipt of your vulnerability report within 48 hours and will send a more detailed response within 5 business days indicating the next steps in handling your report.

STRIDE GPT requires API keys for various LLM providers. Follow these practices to keep your credentials secure:

1. Never commit API keys to version control

   • Use .env files for local development (already in .gitignore)
   • Use environment variables or secrets management in production

2. Rotate API keys regularly

   • Change keys periodically and after any suspected compromise
   • Use separate keys for development and production environments

3. Limit API key permissions

   • Use provider-specific settings to restrict key capabilities where possible
   • Monitor API usage for anomalies

4. Secure secrets in deployment

   • Use Streamlit Cloud secrets management for cloud deployments
   • Use Docker secrets or environment variables for containerized deployments
   • Never expose .env or secrets.toml files publicly

For a reference architecture (identity-aware proxy with OIDC, TLS 1.3 and mTLS, egress allow-listing, logging, and CI usage), see the Deployment hardening guide. In summary, when deploying STRIDE GPT:

1. Network Security

   • Deploy behind authentication/authorization if hosting publicly
   • Use HTTPS/TLS for all network traffic
   • Consider using a reverse proxy (nginx, Caddy) with security headers

2. Docker Security

   • Run containers with non-root users (already implemented)
   • Scan Docker images for vulnerabilities regularly
   • Keep base images updated

3. Access Control

   • Implement authentication for production deployments
   • Use Streamlit's built-in authentication features or external auth providers
   • Restrict access to authorized users only

4. Data Privacy

   • Be aware that threat model inputs may be sent to third-party LLM providers
   • Review provider privacy policies and data handling practices
   • Consider using local models (LM Studio) for sensitive environments
   • Critical: Avoid including actual sensitive organizational details in threat modeling inputs
   • Use generic descriptions rather than specific system details when possible

1. Dependency Management

   • Regularly update dependencies to patch security vulnerabilities
   • Review pyproject.toml and uv.lock for outdated or vulnerable packages
   • Automated scanning with pip-audit runs on pushes and pull requests targeting main, master, or develop (see Automated Security Scanning section)

2. Input Validation

   • The application validates inputs, but always review user-provided data
   • Be cautious with custom API endpoints and credentials

3. Code Reviews

   • Review pull requests for security implications
   • Pay special attention to changes in authentication, API key handling, or data processing

STRIDE GPT uses comprehensive automated security scanning in our CI/CD pipeline to identify and address vulnerabilities proactively.

Our security workflow runs on pushes and pull requests targeting main, master, or develop, plus scheduled and manual runs, using:

1. Python Code Analysis

   • Bandit: Identifies common security issues in Python code (SQL injection, hardcoded credentials, etc.)
   • CodeQL: GitHub's advanced semantic analysis for security vulnerabilities

2. Dependency Scanning

   • pip-audit: Scans Python dependencies against the OSV vulnerability database
   • Dependabot: Automated dependency updates and security alerts

3. Secret Detection

   • Gitleaks: Scans git history for accidentally committed secrets, API keys, and credentials

4. Container Security

   • Trivy: Scans Docker images for vulnerabilities in OS packages and dependencies

5. Dependency Review

   • Automated review of dependency changes in pull requests
   • Blocks dependencies with moderate or higher severity vulnerabilities
   • Prevents introduction of incompatible licenses (GPL-3.0, AGPL-3.0)

Security scan results are available in multiple locations:

• GitHub Security Tab: View all code scanning alerts, secret scanning alerts, and Dependabot alerts
• Pull Request Checks: Security scans run on PRs targeting main, master, or develop, with results visible in the checks
• Actions Tab: Detailed workflow logs and security reports
• Workflow Artifacts: Downloadable JSON reports (Bandit, pip-audit) for deeper analysis

• Scheduled Scans: Security workflow runs weekly (Mondays at 9 AM UTC) to catch newly disclosed vulnerabilities
• Push-based Scans: Automatic scanning on every push to main, master, and develop
• Pull Request Scanning: Python, secret, CodeQL, dependency and container checks run for PRs targeting these branches. Container builds, import smoke checks and vulnerability scans also run on pushes and manual runs.
• Merge protection: Repository administrators should require Lint (ruff), Type check (mypy), the three Python test matrix checks, Package (installed wheel), Lane guard, and Security Scan Summary in their branch rules. The summary fails for failed or cancelled scans; workflow definitions alone do not configure branch protection. Dependency Review requires GitHub's Dependency graph to be enabled.

The reviewed protection configuration is in .github/branch-protection-main.json. After the updated checks have run on a PR, a repository administrator can apply it with an authenticated GitHub CLI:

gh api --method PUT repos/aisecnomad/Nexus-stride-gpt/branches/main/protection \
  --input .github/branch-protection-main.json
gh api repos/aisecnomad/Nexus-stride-gpt/branches/main/protection

This requires one approving review, current passing checks, and resolved conversations; it also applies to administrators and blocks force pushes and branch deletion. Committing this file does not activate protection. The command requires repository administration permission, which the connected GitHub App does not provide.

When security issues are identified:

1. Critical/High Severity: Addressed immediately with patches
2. Medium Severity: Evaluated and fixed in the next release
3. Low Severity: Reviewed and addressed based on impact and exploitability
4. False Positives: Documented and suppressed with justification

Developers can run security scans locally:

# Install security tools
pip install bandit pip-audit

# Run Bandit
bandit -r . -f txt

# Run pip-audit
pip-audit --desc

STRIDE GPT is designed for legitimate threat modeling and security analysis purposes only. Users should:

1. Use for defensive security purposes

   • Threat modeling to improve application security
   • Security architecture design and review
   • Risk assessment and mitigation planning

2. Follow ethical guidelines

   • Use generated threat models responsibly
   • Do not use threat intelligence for malicious purposes
   • Share findings constructively with development teams

3. Protect sensitive information

   • Avoid inputting confidential system architecture details
   • Use sanitized or generic descriptions when possible
   • Be mindful that inputs are processed by third-party AI services

4. Comply with applicable laws

   • Follow all local, state, and federal laws regarding computer security
   • Respect organizational policies and NDAs

1. LLM Provider Data Sharing

   • Threat model inputs and outputs are sent to third-party LLM providers
   • These providers may log requests for their own purposes
   • Review each provider's data handling policies
   • Recommendation: Use sanitized/generic system descriptions

2. Streamlit Session State

   • Streamlit session state lives on the server; widget values are also sent to the browser
   • Operator-provided environment credentials stay server-side and are never prefilled in password widgets
   • User-entered credentials are held in that user's session and widget; password masking is not a secrecy boundary from the user
   • Clear sensitive information when finished
   • Close browser sessions after use

3. STRIDE Framework Application

   • Generated threat models are AI-generated and should be reviewed by security professionals
   • Use as a starting point, not a complete security analysis
   • Validate threats against your specific system architecture

4. Rate Limiting

   • Implement rate limiting if exposing the application publicly
   • Monitor API usage to prevent abuse

5. Output Sensitivity

   • Generated threat models may contain security-sensitive information
   • Handle downloaded reports with appropriate confidentiality
   • Store threat model outputs securely

Security updates will be released as patch versions and documented in the release notes. Users are encouraged to:

• Watch the repository for security advisories
• Subscribe to release notifications
• Keep installations up to date

• OWASP Top 10
• STRIDE Threat Modeling
• Streamlit Security Documentation
• Docker Security Best Practices

We appreciate the security research community's efforts in responsibly disclosing vulnerabilities. Contributors who report valid security issues will be acknowledged (with permission) in our security advisories.

Agent source reads and evidence verification deny common credential paths, PEM private-key content, and a few recognizable credential formats and use descriptor-relative opens that do not follow replaced symlinks. Reads fail closed on platforms without the necessary primitives. This is not a complete secret detector: credentials can be embedded in ordinary source, and filesystem hard links or mount points are outside pathname confinement. Analyze a private, sanitized checkout in an isolated environment, and do not scan repositories that another principal can concurrently mutate. Provider requests may contain source content; use appropriate provider terms and data-handling controls.