SentriX

A Modern, Open-Source Security Operations Center (SOC) Management Platform

SentriX is a comprehensive Security Operations Center (SOC) management platform built for modern security teams. It streamlines the lifecycle of security incidents from initial alert ingestion to case management, threat intelligence correlation, and final resolution. Designed with a focus on speed, accuracy, and analyst experience, SentriX provides a centralized hub for managing organizational security posture.

Security teams often struggle with disjointed tools, fragmented alert data, and inefficient case tracking. SentriX solves this by offering a unified, opinionated workflow. Instead of overwhelming analysts with noise, SentriX strictly structures the escalation path: Alerts are triaged and optionally escalated into Cases, where deep investigations take place. Paired with integrated Threat Intelligence and Asset Management, analysts have all the context they need in a single pane of glass.

• Alert Queue & Triage: Centralized ingestion of security alerts with immediate contextual data (severity, status, source).
• Case Management: Robust ticketing for security incidents, supporting timeline tracking, evidence logging, and analyst assignments.
• Asset Management: Track organizational endpoints, their criticality, and associated risk factors.
• Threat Intelligence: Maintain a database of known threat actors, campaigns, and Indicators of Compromise (IoCs).
• Detection Engine Rules: Manage detection logic and mapping to the MITRE ATT&CK framework.
• Malware Analysis Tracking: Sandbox integration tracking and malware sample cataloging.
• Knowledge Base: Built-in repository for standard operating procedures (SOPs) and tactical guidance.
• Audit Logging: Immutable tracking of all user actions across the platform for compliance.

(Insert GIF or link to video demonstration here showing an analyst triaging an alert, escalating to a case, and viewing threat intelligence.)

SentriX employs a decoupled, containerized architecture. The frontend is a highly responsive Single Page Application (SPA) communicating via REST API to a stateless backend, which relies on PostgreSQL for persistent storage and Redis for caching and session management.

graph TD
    Client["Web Browser"] -->|REST API / HTTPS| Nginx["Reverse Proxy / Next.js Server"]
    Nginx -->|Proxy| Frontend["Frontend: React / Next.js"]
    Nginx -->|API Route| Backend["Backend: FastAPI"]
    Backend -->|Read/Write| DB[(PostgreSQL)]
    Backend -->|Cache/Session| Cache[(Redis)]

• Frontend: React 19, Next.js 15, Tailwind CSS, Zustand (State Management), React Query, Lucide Icons, Monaco Editor.
• Backend: Python 3.11+, FastAPI, SQLAlchemy (ORM), Alembic (Migrations), Pydantic (Validation), Passlib (Hashing), PyJWT (Authentication).
• Infrastructure: Docker, Docker Compose, PostgreSQL 15, Redis 7.

SentriX is designed around domain-driven modules. The system enforces strict separation of concerns:

• Presentation Layer: React components handling UI and user interactions.
• API Layer: FastAPI routers validating incoming HTTP requests using Pydantic.
• Service Layer: Business logic orchestrating data between domains.
• Data Access Layer: SQLAlchemy repository pattern interacting with the database.

SentriX/
├── backend/
│   ├── alembic/              # Database migration scripts
│   ├── app/
│   │   ├── api/v1/           # FastAPI routers (endpoints)
│   │   ├── core/             # Config, security, exceptions
│   │   ├── db/               # Database and Redis connections
│   │   ├── models/           # SQLAlchemy ORM models
│   │   ├── repositories/     # Database access layer
│   │   ├── schemas/          # Pydantic validation schemas
│   │   └── services/         # Business logic layer
│   ├── scripts/              # DB Seeding utilities
│   └── requirements.txt      # Python dependencies
├── frontend/
│   ├── app/                  # Next.js App Router pages
│   ├── components/           # Reusable React components (UI/Layout)
│   ├── lib/                  # Utility functions, API client, Zustand store
│   ├── public/               # Static assets
│   ├── package.json          # Node dependencies
│   └── tailwind.config.ts    # Tailwind styling configuration
├── docker-compose.yml        # Orchestration
└── Makefile                  # Task automation

erDiagram
    ORGANIZATION ||--o{ USER : contains
    ORGANIZATION ||--o{ ALERT : tracks
    ORGANIZATION ||--o{ ASSET : owns
    ORGANIZATION ||--o{ THREAT_INTEL : tracks
    USER ||--o{ CASE : assigned_to
    USER ||--o{ AUDIT_LOG : generates
    ALERT ||--o| CASE : escalated_to
    CASE ||--o{ CASE_ACTIVITY : contains
    CASE ||--o{ INVESTIGATION : includes

The backend uses a layered architecture to ensure maintainability:

graph TD
    Router["FastAPI Routers"] --> Schema["Pydantic Validation"]
    Schema --> Service["Business Logic Services"]
    Service --> Repo["Repository Layer"]
    Repo --> ORM["SQLAlchemy Models"]
    ORM --> DB[(PostgreSQL)]

The frontend leverages Next.js App Router for structural routing and Zustand for global UI/Auth state, while React Query handles server-state synchronization (caching, deduping requests).

• lib/api.ts: Configured Axios client with automatic JWT bearer token injection and interceptors.
• lib/store.ts: Zustand store for Auth state (tokens, user profile) and UI state (sidebar toggles).

sequenceDiagram
    participant User
    participant Frontend
    participant FastAPI
    participant Database

    User->>Frontend: Enter credentials
    Frontend->>FastAPI: POST /api/v1/auth/login
    FastAPI->>Database: Verify User/Password
    Database-->>FastAPI: Verification Success
    FastAPI-->>Frontend: Return JWT Access & Refresh Tokens
    Frontend->>Frontend: Store in Zustand/Local Storage
    Frontend->>FastAPI: API Request + Bearer Token
    FastAPI-->>Frontend: Protected Data

The SentriX workflow is linear and structured to prevent analyst fatigue:

1. Ingestion: Security tools generate Alerts.
2. Triage: Analysts review Alerts. False positives are closed. True positives are escalated.
3. Escalation: Escalated alerts spawn a Case.
4. Investigation: Analysts use the Investigation Timeline to log findings, attach Evidence, and correlate Threat Intel.
5. Remediation: Actions are taken to neutralize the threat.
6. Closure: The Case is documented and closed.

graph LR
    A["New Alert"] --> B{"Triaged by Analyst"}
    B -->|"False Positive"| C["Close Alert"]
    B -->|"True Positive"| D["Escalate to Case"]
    B -->|"Duplicate"| E["Merge to Existing Case"]

stateDiagram-v2
    [*] --> OPEN
    OPEN --> IN_PROGRESS : Analyst Assigned
    IN_PROGRESS --> PENDING_REVIEW : Investigation Complete
    PENDING_REVIEW --> IN_PROGRESS : Revisions Needed
    PENDING_REVIEW --> CLOSED : Approved & Remediated
    CLOSED --> [*]

Tracking endpoints is critical for contextualizing alerts. SentriX tracks:

• Hostnames, IP Addresses, and MAC Addresses.
• Operating System and Agent versions.
• Asset Criticality (Low, Medium, High, Mission Critical).
• Open vulnerabilities and patch status.

The Threat Intel module catalogs external threats:

• Threat Actors: Profiles of known APTs and cybercriminal groups.
• Campaigns: Specific targeted attacks linked to actors.
• Indicators of Compromise (IoCs): IP addresses, domains, and file hashes linked to malicious activity.

Every action (Create, Update, Delete) performed via the API is logged immutably in the audit_logs table. This provides a complete paper trail of analyst actions, configuration changes, and system modifications for compliance and forensic review.

SentriX exposes a RESTful API at http://localhost:8000/api/v1. Interactive Swagger documentation is available at http://localhost:8000/docs when the backend is running.

graph LR
    A[HTTP Request] --> B[Auth Middleware]
    B -->|Invalid JWT| C[401 Unauthorized]
    B -->|Valid JWT| D[FastAPI Router]
    D --> E[Pydantic Validation]
    E -->|Invalid Body| F[422 Unprocessable Entity]
    E -->|Valid Body| G[Service Layer]
    G --> H[Repository Layer]
    H --> I[Database]
    I --> H
    H --> G
    G --> D
    D --> J[200 OK Response]

• Docker & Docker Compose (v2+)
• Git

git clone https://github.com/alive-xd/SentriX.git
cd SentriX

Copy the example environment files for both frontend and backend.

cp backend/.env.example backend/.env
cp frontend/.env.local.example frontend/.env.local

(Ensure DATABASE_URL and REDIS_URL are correctly set in the backend .env if not using the default Docker configuration).

graph TD
    subgraph DockerNetwork [Docker Network]
        Frontend["Frontend Container: 3000"]
        Backend["Backend Container: 8000"]
        Postgres["PostgreSQL: 5432"]
        Redis["Redis: 6379"]
    end
    Frontend --> Backend
    Backend --> Postgres
    Backend --> Redis

Run the entire stack using Docker Compose:

docker compose up --build -d

Access the application at http://localhost:3000.

For active development, run the services natively: Backend:

cd backend
python -m venv venv
source venv/bin/activate  # or `venv\Scripts\activate` on Windows
pip install -r requirements.txt
uvicorn app.main:app --reload --port 8000

Frontend:

cd frontend
npm install
npm run dev

Database schema changes are managed via Alembic. To run existing migrations:

cd backend
alembic upgrade head

To generate a new migration after modifying SQLAlchemy models:

alembic revision --autogenerate -m "Description of changes"

To populate the database with realistic sample data (Admin users, alerts, cases, assets):

# Via docker compose:
docker compose exec backend python scripts/seed_database.py

# Or locally:
cd backend
python scripts/seed_database.py

Default Admin Login:

• Email: admin@sentrix.local
• Password: admin

(Frameworks placeholder - SentriX architecture supports Pytest for the backend and Jest/React Testing Library for the frontend).

# Run backend tests
cd backend
pytest

• Password Hashing: Passlib with bcrypt.
• Authentication: Stateless JWTs with short expiration times.
• CORS Configuration: Strictly controlled origins in FastAPI.
• Environment Isolation: Secrets managed entirely via .env.

• Pagination: Implemented on all list endpoints to prevent massive payload sizes.
• Indexing: Database schema utilizes indexes on frequently queried fields (e.g., status, severity, organization_id).
• React Query: Deduplicates frontend network requests and caches responses to minimize API load.

• No native integration with specific SIEMs (Splunk, Elastic) out-of-the-box (requires API bridging).
• Role-Based Access Control (RBAC) currently supports global Admin vs Analyst roles; granular per-asset scoping is planned.
• No real-time WebSocket updates currently implemented; relies on polling or manual refresh.

• Implement WebSockets for real-time alert notifications.
• Build pre-configured integrations for popular EDRs (CrowdStrike, SentinelOne).
• Add customizable dashboard widgets.
• Granular RBAC and multi-tenancy boundaries.

(Link to YouTube/Vimeo demo video of the platform).

(Link to detailed architectural breakdown on Medium).

Contributions are welcome! Please read CONTRIBUTING.md for details on our code of conduct, and the process for submitting pull requests.

This project is licensed under the MIT License - see the LICENSE file for details.

Created and maintained by alive-xd.

• FastAPI for the incredible backend framework.
• Next.js and React for the robust frontend architecture.
• Tailwind CSS for rapid UI styling.
• Lucide for beautiful iconography.