Skip to main content
Neo helps you think through security before writing code. It analyzes designs, architectures, and feature specs to generate practical threat models and developer checklists, so security becomes part of your planning and build process instead of an afterthought.

​
How it works

  1. Input analysis: Neo reads your PRD, design docs, architecture diagrams, API specs, or user stories from Files
  2. Asset identification: it identifies what you’re protecting (user data, money, access, availability, trust)
  3. Attack surface mapping: Neo maps entry points, trust boundaries, and external dependencies
  4. Threat identification: it identifies realistic threats based on your specific context (not generic theory)
  5. Checklist generation: Neo produces actionable security requirements for developers to follow during implementation
  6. Review integration: outputs can be added to tickets, PRs, or design review docs

​
Prerequisites

  • Design docs, PRDs, architecture diagrams, or user stories in Files
  • Optional: existing security standards or past threat models in Files for consistency
  • Optional: integration with Jira, Linear, or GitHub for automated checklist delivery

​
Usage

​
For a New Feature

Prompt example: “Review the design doc for the file sharing feature. Generate a threat model and create a security checklist for developers building this feature.” What Neo does:
  • Reads the design doc to understand feature scope and user flows
  • Identifies sensitive assets (files, user permissions, access logs)
  • Maps attack surface (upload endpoints, download links, sharing mechanisms)
  • Generates practical threats (unauthorized access, malicious file uploads, link enumeration)
  • Creates a developer checklist with specific requirements for this feature
  • Optionally posts checklist to Jira ticket or GitHub issue for tracking

​
For a Product or System

Prompt example: “Analyze our payment processing system architecture. Create a threat model and identify security requirements for the next sprint.” What Neo does:
  • Analyzes architecture to identify components, data flows, and trust boundaries
  • Identifies high-risk areas (payment data handling, PCI scope, third-party integrations)
  • Maps realistic attack scenarios based on your specific implementation
  • Generates prioritized security requirements by component
  • Creates actionable tasks that fit into your sprint planning

​
Automated Threat Model Generation

Neo can automatically generate threat models during your planning stage by integrating with your ticketing system. Configure this once in your Neo account, and threat models will be created whenever new feature tickets are opened.

​
Setup

  1. Configure integration in your Neo account settings:
    • Connect Jira, Linear, or GitHub via Environment Variables
    • Enable automatic threat model generation
    • Set trigger conditions (labels, issue types, or project-specific rules)
  2. Define triggers:
    • Auto-generate for tickets labeled security-review, new-feature, or architecture-change
    • Trigger on specific issue types (Epic, Story, Feature Request)
    • Set project or repository filters to scope automation
  3. Customize outputs:
    • Choose where to attach threat models (comment, linked document, or dedicated field)
    • Configure checklist format (inline, attached file, or sub-tasks)
    • Set notification preferences for security team review

​
How It Works

When a new ticket is created:
  1. Neo detects the ticket creation via webhook or polling
  2. Extracts context from ticket description, labels, and linked documents
  3. Reads referenced design docs, PRDs, or specs from Files or ticket attachments
  4. Generates threat model and security checklist based on feature description
  5. Posts results as a comment or attachment to the ticket
  6. Optionally creates sub-tasks for each security requirement
  7. Notifies security team for review and approval

​
Example: Jira Integration

Ticket: PROJ-456 - Implement file sharing feature
Label: new-feature, security-review

Neo automatically:
1. Reads ticket description and acceptance criteria
2. Generates threat model identifying file access, upload, and sharing risks
3. Creates security checklist with 25 specific requirements
4. Posts as comment with header "🔒 Security Threat Model (Auto-generated)"
5. Creates 6 sub-tasks under PROJ-456 for critical security items:
   - PROJ-456-1: Implement cryptographic share token generation
   - PROJ-456-2: Add file type validation using magic bytes
   - PROJ-456-3: Set up malware scanning for uploads
   - PROJ-456-4: Implement rate limiting on upload endpoint
   - PROJ-456-5: Add access logging for audit trail
   - PROJ-456-6: Write security tests for unauthorized access

​
Example: Linear Integration

Issue: ENG-789 - Build OAuth integration with Google
Team: Platform
Label: oauth, integration

Neo automatically:
1. Detects "oauth" label trigger
2. Analyzes issue description for integration details
3. Generates OAuth-specific threat model (token leakage, CSRF, redirect attacks)
4. Posts security checklist as first comment
5. Adds "security-review-required" label
6. Assigns to security team member for validation
7. Creates reminder to review before sprint planning

​
Example: GitHub Integration

Issue: #234 - Add payment processing with Stripe
Repository: backend-api
Labels: feature, payments

Neo automatically:
1. Reads issue body and linked PRD from Files
2. Generates PCI-focused threat model
3. Creates security requirements as task list in issue description
4. Opens draft PR with security checklist template in description
5. Tags @security-team for review
6. Blocks issue from "Ready for Development" until security sign-off

​
Configuration Options

In your Neo account, you can configure:
  • Trigger rules: Which tickets/issues should generate threat models
  • Context sources: Where to pull additional context (Files, wiki, previous tickets)
  • Output format: Comment, attachment, sub-tasks, or custom fields
  • Approval workflow: Require security team review before development starts
  • Update behavior: Auto-update threat model when ticket description changes
  • Notification settings: Who gets notified when threat models are generated

​
Benefits

  • Zero manual effort: Threat models created automatically at ticket creation
  • Consistent coverage: Every new feature gets security consideration
  • Early visibility: Security requirements identified before development starts
  • Developer guidance: Clear checklist available from day one
  • Audit trail: All threat models tracked and versioned with tickets

​
Example Outputs

​
Developer Security Checklist

Neo creates a practical, actionable checklist: 
# Security Checklist: File Sharing Feature

Complete these requirements during implementation. Link evidence (PR, test results) when done.

## File Upload
- [ ] Validate file type using magic bytes, not just extension
- [ ] Enforce file size limits (max 100MB per file, 1GB per user)
- [ ] Scan uploaded files for malware before storing
- [ ] Sanitize filenames to prevent path traversal (no ../, absolute paths, null bytes)
- [ ] Generate file IDs using cryptographically secure random (use uuid4 or equivalent)
- [ ] Store files outside web root with non-guessable paths
- [ ] Implement rate limiting: max 10 uploads per user per hour

## File Download & Access Control
- [ ] Verify user owns the file OR has valid share token before serving
- [ ] Use signed, time-limited download URLs (expire in 1 hour)
- [ ] Log all file access attempts with user ID and timestamp
- [ ] Set Content-Disposition: attachment to prevent inline execution
- [ ] Remove or sanitize metadata from files before serving
- [ ] Implement rate limiting on download endpoint

## Share Link Security
- [ ] Generate share tokens using 32+ bytes of cryptographic randomness
- [ ] Set expiration on all share links (default 7 days, max 30 days)
- [ ] Allow file owners to revoke share links at any time
- [ ] Log share link creation and access for audit trail
- [ ] Require authentication for sensitive file types (even with valid token)
- [ ] Prevent share link enumeration with rate limiting

## Data Storage
- [ ] Encrypt files at rest using AES-256
- [ ] Encrypt file metadata in database
- [ ] Use separate S3 bucket with private ACLs
- [ ] Enable S3 versioning for accidental deletion recovery
- [ ] Set lifecycle policies to delete files after retention period

## Testing Requirements
- [ ] Test: unauthorized user cannot access file via ID guessing
- [ ] Test: expired share link returns 403 Forbidden
- [ ] Test: malicious filename (../../etc/passwd) is rejected
- [ ] Test: oversized file upload is rejected with 413
- [ ] Test: revoked share link cannot access file
- [ ] Test: rate limit blocks excessive uploads/downloads

## Before Merge
- [ ] Security review completed by [Security Team]
- [ ] All checklist items verified with evidence
- [ ] Threat model reviewed and updated if design changed

​
Common Use Cases

​
Design Review Integration

“We’re reviewing the architecture for a new multi-tenant dashboard. Generate a threat model focused on tenant isolation and create security requirements for the engineering team.” Neo will:
  • Analyze tenant boundary risks
  • Identify data leakage scenarios between tenants
  • Generate checklist items for query filtering, access control, and testing
  • Flag high-risk areas like shared caches or global search

​
Sprint Planning

“For sprint 23, we’re building OAuth integration with Google. What security threats should we consider and what should developers implement?” Neo will:
  • Identify OAuth-specific risks (token leakage, CSRF, redirect manipulation)
  • Generate checklist for secure token storage, state parameter validation, redirect URI validation
  • Provide testing requirements for authorization code flow

​
Architecture Change Assessment

“We’re migrating from monolith to microservices. Update our threat model to reflect new attack surface and service-to-service communication risks.” Neo will:
  • Compare old vs new architecture
  • Identify new threats from service boundaries and network exposure
  • Generate requirements for service authentication, API gateways, and secrets management
  • Prioritize risks by migration phase

​
Third-Party Integration

“We’re integrating with Stripe for payments. Create a threat model and checklist for PCI compliance and secure payment handling.” Neo will:
  • Map payment data flows and PCI scope
  • Identify risks around API key management, webhook verification, and data handling
  • Generate checklist for tokenization, webhook signature validation, and logging restrictions
  • Link to PCI DSS requirements where applicable

​
Integration with Development Workflow

​
At Design Review

  1. Attach design docs to Files
  2. Prompt: “Generate threat model and security requirements for [feature name]”
  3. Review threat model with team, adjust based on feedback
  4. Add checklist items to Jira epic or GitHub issue template
  5. Store finalized threat model in Files for reference

​
During Sprint Planning

  1. Reference threat model from design phase
  2. Break security requirements into tasks
  3. Assign checklist items to relevant developers
  4. Set acceptance criteria that include security verification
  5. Schedule security review before sprint end

​
At Code Review

  1. Developer marks checklist items as complete in PR description
  2. Reviewer verifies implementation against checklist
  3. Neo can automatically verify certain items (e.g., check for rate limiting, validate token generation)
  4. Security sign-off required before merge

​
Post-Launch

  1. Store final threat model and completed checklist in Files
  2. Use as baseline for future similar features
  3. Update Memory with lessons learned
  4. Schedule periodic re-assessment as architecture evolves

​
Tips for Effective Threat Modeling

​
Be Specific About Your Context

Instead of: “Create a threat model for our API” Better: “Create a threat model for our customer data export API. Users can request CSV exports of their order history. Files are generated async and stored in S3 for 24 hours.”

​
Focus on Realistic Threats

Neo prioritizes threats based on:
  • Your actual attack surface (what’s exposed?)
  • Data sensitivity (what’s worth attacking?)
  • Likelihood (has this happened to similar systems?)
  • Impact (what’s the worst case?)
Not theoretical academic scenarios that don’t apply to your system.

​
Iterate as You Build

Threat models aren’t static documents:
  • Update when architecture changes
  • Add new threats discovered during implementation
  • Refine checklist based on what actually worked
  • Store updates in Files for history