Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 23 additions & 0 deletions .github/workflows/go-release.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
name: Release // Go Module & Binary
on:
workflow_dispatch:
push:
tags: ['v*']
jobs:
build-go:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Set up Go
uses: actions/setup-go@v4
Comment on lines +10 to +12
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

cat .github/workflows/go-release.yml

Repository: abdulraheemnohri/AIP-HSD

Length of output: 609


🌐 Web query:

GitHub Actions actions/checkout latest version 2026

💡 Result:

The latest version of the GitHub Actions actions/checkout is v6.0.2, released on January 9, 2026.

Citations:


🌐 Web query:

GitHub Actions actions/setup-go latest version 2026

💡 Result:

The latest version of the GitHub Actions actions/setup-go is v6.3.0, released on 2026-02-26.

Citations:


🌐 Web query:

GitHub Actions actions/upload-artifact latest version 2026

💡 Result:

The latest version of the GitHub Actions actions/upload-artifact is v7.0.0, released on February 26, 2026.

Citations:


🌐 Web query:

GitHub Actions actions/checkout v3 deprecation end of life

💡 Result:

actions/checkout v3 has no official deprecation or end-of-life date announced by GitHub. It remains available and usable as of 2026-04-04, with the v3 tag still pointing to the latest v3.x release (v3.6.0 from changelog). GitHub's policy for actions is to maintain major versions indefinitely for compatibility, providing security fixes and critical updates without breaking changes. v3 uses Node.js 16, which reached end-of-life in the Actions runner on 2024-11-12; workflows may show deprecation warnings or fail on newer runners without Node 16 support unless env vars like ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true are set. Users are strongly encouraged to upgrade to v4 (Node 20), v5 (Node 24), or latest v6 for ongoing feature support and compatibility with current runners. No workflow failures occur solely from using v3 on supported runners; the tag will not be removed.

Citations:


🌐 Web query:

GitHub Actions actions/setup-go v4 v5 deprecation end of life

💡 Result:

The actions/setup-go GitHub Action follows a major version release strategy where older major versions (v4 and v5) are not formally deprecated but receive no new features or breaking changes. They continue to receive security updates via dependency patches as needed. Current status as of 2026-04-04: - Latest version: v6.4.0 (released 2026-03-30), featuring Node.js 24 runtime, improved Go toolchain handling (support for both 'go' and 'toolchain' directives in go.mod), and cache key based on go.mod by default. - v5 branch: Actively maintained with recent releases like v5.6.0 (2025-12-16), including fixes like fallback to go.dev/dl downloads. Uses Node.js 20 runtime. - v4: Last significant release v4.0.1 (around 2023), enabled caching by default. Older Node.js runtime (pre-node20). No explicit deprecation notices or end-of-life dates found for v4 or v5 in official documentation, releases, or issues. GitHub Actions major versions are generally supported indefinitely for security, but users are encouraged to upgrade to the latest (v6) for new features, performance improvements, and compatibility with newer runners (requires runner v2.327.1+ for v6 due to Node 24). Node.js runtime deprecations affect older versions indirectly: - v3/v4 used Node 16 (deprecated in workflows since ~2023-2024). - v5 uses Node 20. - v6 uses Node 24. Recommendation: Update workflows to uses: actions/setup-go@v6 for optimal support. Pin to major version (e.g., @v6) to avoid breaking changes from patches.

Citations:


🌐 Web query:

GitHub Actions actions/upload-artifact v3 deprecation end of life

💡 Result:

actions/upload-artifact@v3 was deprecated on January 30, 2025. As of today (2026-04-04), it is past the deprecation date and using v3 will cause workflow failures on GitHub.com (though tags remain available and it does not affect GitHub Enterprise Server). Users must migrate to v4 or later (current latest is v7.0.0). Key changes include immutable artifacts (no overwriting same name without delete), job-scoped instead of workflow-scoped, up to 98% faster uploads/downloads, and new features like overwrite option and merge sub-action. See MIGRATION.md for details: https://github.com/actions/upload-artifact/blob/main/docs/MIGRATION.md

Citations:


Update action versions urgently—upload-artifact@v3 is deprecated and will cause workflow failures.

  • Line 10: actions/checkout@v3 uses Node 16 (EOL Nov 2024); upgrade to v4 or later
  • Line 12: actions/setup-go@v4 is outdated; upgrade to v5 or later
  • Line 20: actions/upload-artifact@v3 has been deprecated since January 30, 2025 and will cause workflow failures on GitHub.com; must upgrade to v4 or later
Proposed fix
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v4
@@
-        uses: actions/setup-go@v4
+        uses: actions/setup-go@v5
@@
-        uses: actions/upload-artifact@v3
+        uses: actions/upload-artifact@v4
🧰 Tools
🪛 actionlint (1.7.12)

[error] 10-10: the runner of "actions/checkout@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue

(action)


[error] 12-12: the runner of "actions/setup-go@v4" action is too old to run on GitHub Actions. update the action's version to fix this issue

(action)

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.github/workflows/go-release.yml around lines 10 - 12, Update the GitHub
Actions step versions to supported releases: replace actions/checkout@v3 with
actions/checkout@v4 (or later), replace actions/setup-go@v4 with
actions/setup-go@v5 (or later), and replace actions/upload-artifact@v3 with
actions/upload-artifact@v4 (or later); locate the workflow steps using those
action identifiers (e.g., the checkout, setup-go, and upload-artifact steps) and
update their version specifiers accordingly so the workflow runs on supported
Action releases.

with:
go-version: '1.21'
- name: Build Binary
run: |
cd backend/go
go build -o aiphsd-go cmd/main.go
- name: Upload Artifact
uses: actions/upload-artifact@v3
with:
name: aiphsd-go-binary
path: backend/go/aiphsd-go
19 changes: 19 additions & 0 deletions .github/workflows/nodejs-release.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
name: Release // Node.js Package (NPM/GHCR)
on:
workflow_dispatch:
push:
tags: ['v*']
jobs:
build-node:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Update outdated GitHub Actions to v4.

actions/checkout@v3 and actions/setup-node@v3 are deprecated. Update to v4.

🔧 Proposed fix
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v4
       - name: Set up Node
-        uses: actions/setup-node@v3
+        uses: actions/setup-node@v4
         with:
           node-version: '18'

Also applies to: 12-12

🧰 Tools
🪛 actionlint (1.7.12)

[error] 10-10: the runner of "actions/checkout@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue

(action)

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.github/workflows/nodejs-release.yml at line 10, Update the workflow to use
the v4 versions of the GitHub Actions referenced: replace uses:
actions/checkout@v3 and uses: actions/setup-node@v3 with actions/checkout@v4 and
actions/setup-node@v4 respectively; ensure any options previously passed to
checkout (e.g., fetch-depth) and setup-node (e.g., node-version, cache) are
preserved or adjusted per v4 compatibility, and run/validate the CI workflow to
confirm no behavioral changes.

- name: Set up Node
uses: actions/setup-node@v3
with:
node-version: '18'
- name: Build and Publish
run: |
cd backend/nodejs
npm install
# npm publish # Actual publish
19 changes: 19 additions & 0 deletions .github/workflows/python-release.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
name: Release // Python Package (PyPI/GHCR)
on:
workflow_dispatch:
push:
tags: ['v*']
jobs:
build-python:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Set up Python
uses: actions/setup-python@v4
Comment on lines +10 to +12
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

actions/checkout current recommended version 2024 2025

💡 Result:

The current recommended version of the GitHub Actions actions/checkout is v6.0.2, released on January 9, 2026. Official documentation and the GitHub Marketplace explicitly show usage examples with uses: actions/checkout@v6 and list v6.0.2 as the latest version. This supersedes v5 (Node.js 24 runtime, August 2025) and v4 branches. Pin to a full version tag like @v6.0.2 for stability, as recommended in the repository README. Example usage: - uses: actions/checkout@v6.0.2 with: # Optional inputs like ref, fetch-depth, etc. Key recent releases: - v6.0.2 (2026-01-09): Fixed tag handling and fetch-tags support. - v6.0.1 (2025-12-02): Clarified v6 README. - v6.0.0 (2025-11-20): Improved credential security with separate file storage under $RUNNER_TEMP; Node.js 24 support. - v5.0.0 (2025-08): Updated to Node.js 24 runtime (requires runner v2.327.1+). As of 2026-04-04, v6 is the actively recommended major version across official sources.

Citations:


🌐 Web query:

actions/setup-python current recommended version 2024 2025

💡 Result:

There is no single "current recommended version" for actions/setup-python. The action (latest v6.2.0 as of Jan 2026) requires specifying the python-version input explicitly for reproducibility, as the default falls back to runner PATH (which varies and changes, e.g., Ubuntu 24.04 has Python 3.12.* as default per recent runner updates). Official docs strongly recommend always setting python-version (e.g., '3.13' for latest stable minor, matching examples throughout README and advanced-usage.md). Using major.minor like '3.13' selects the latest patch from toolcache or downloads from actions/python-versions (supports up to 3.15.0-alpha as of Mar 2026). For 2024-2025, examples shifted from '3.12' to '3.13'. Use check-latest: true for newest patch.

Citations:


🌐 Web query:

actionlint deprecated github actions v3 v4

💡 Result:

actionlint is not deprecated. It is the actively maintained official static checker for GitHub Actions workflow files from https://github.com/rhysd/actionlint. Latest release v1.7.12 on 2026-03-30, with last commit on 2026-04-02. It supports checking deprecated inputs in actions (e.g., reports errors for deprecated inputs like fail_on_error in reviewdog/action-actionlint@v1) and detects outdated popular actions using old Node runtimes like node16 or node12. No evidence of deprecation; instead, it lints for deprecations in workflows and actions. There was a 2025 maintenance concern (issue #563), but recent releases and commits confirm ongoing development. Use latest version via go install github.com/rhysd/actionlint/cmd/actionlint@latest or downloads. For GitHub Actions v3 vs v4 (e.g., actions/checkout@v3 to @v4), actionlint's outdated action detection flags v3 if based on deprecated runtimes, recommending upgrade to v4.

Citations:


Upgrade deprecated GitHub Action versions to current major versions.

Lines 10 and 12 use outdated action versions. actions/checkout@v3 and actions/setup-python@v4 are now flagged by actionlint for deprecated runtimes and should be upgraded to their current major versions.

Proposed fix
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v6
@@
-        uses: actions/setup-python@v4
+        uses: actions/setup-python@v6
🧰 Tools
🪛 actionlint (1.7.12)

[error] 10-10: the runner of "actions/checkout@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue

(action)


[error] 12-12: the runner of "actions/setup-python@v4" action is too old to run on GitHub Actions. update the action's version to fix this issue

(action)

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.github/workflows/python-release.yml around lines 10 - 12, Update the GitHub
Actions usages to their current major releases: change the action identifier
"actions/checkout@v3" to the latest major (e.g., "actions/checkout@v4") and
change "actions/setup-python@v4" to the latest major (e.g.,
"actions/setup-python@v5"); locate these exact "uses:" lines in the workflow and
replace the version tags so actionlint no longer flags deprecated runtimes.

with:
python-version: '3.12'
- name: Build and Publish
run: |
cd backend/python
python setup.py sdist bdist_wheel
# twine upload dist/* # Actual publish
Comment on lines +15 to +19
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Release workflow does not actually publish.

Line 19 comments out publish logic, so tagged releases won’t be uploaded despite the workflow’s release intent.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.github/workflows/python-release.yml around lines 15 - 19, The "Build and
Publish" job currently builds distributions but never uploads them because the
twine upload command is commented out; update the "Build and Publish" step (the
step named "Build and Publish") to actually run twine upload (for example
un-comment or replace the commented line with a twine upload invocation) and
ensure it uses GitHub Secrets (e.g., PYPI_USERNAME/PYPI_PASSWORD or API token)
and only runs on tagged releases or the intended release trigger so artifacts
are published to PyPI after the python setup.py sdist bdist_wheel step.

21 changes: 21 additions & 0 deletions .github/workflows/rust-release.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
name: Release // Rust Crate & Binary
on:
workflow_dispatch:
push:
tags: ['v*']
jobs:
build-rust:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Update outdated GitHub Actions to v4.

actions/checkout@v3 and actions/upload-artifact@v3 are deprecated and may fail on newer GitHub runners. Update to v4.

🔧 Proposed fix
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v4
-        uses: actions/upload-artifact@v3
+        uses: actions/upload-artifact@v4

Also applies to: 18-18

🧰 Tools
🪛 actionlint (1.7.12)

[error] 10-10: the runner of "actions/checkout@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue

(action)

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.github/workflows/rust-release.yml at line 10, Update the GitHub Actions
steps that reference deprecated actions by changing actions/checkout@v3 to
actions/checkout@v4 and actions/upload-artifact@v3 to
actions/upload-artifact@v4; locate the workflow entries that contain the strings
"uses: actions/checkout@v3" and "uses: actions/upload-artifact@v3" and replace
the version suffixes to "@v4" to ensure compatibility with newer runners.

- name: Set up Rust
uses: dtolnay/rust-toolchain@stable
- name: Build
run: |
cd backend/rust_server
cargo build --release
- name: Upload Artifact
uses: actions/upload-artifact@v3
with:
name: aiphsd-rust-binary
path: backend/rust_server/target/release/aiphsd-backend-rust
29 changes: 29 additions & 0 deletions .gitignore
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
# Python
__pycache__/
*.py[cod]
*$py.class
dist/
build/
*.egg-info/

# Node.js
node_modules/
npm-debug.log*
yarn-debug.log*
yarn-error.log*
.next/
out/

# Go
bin/
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Make the bin/ pattern more specific.

The pattern bin/ is unrooted and will match any bin/ directory anywhere in the repository, potentially ignoring unintended directories. Since the Go binaries are in backend/go/bin/ (per the PR objectives), make the pattern more specific to avoid accidentally hiding files.

🎯 Proposed fix to scope the pattern
-bin/
+backend/go/bin/

Alternatively, if you want a repository-root bin/ directory:

-bin/
+/bin/
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
bin/
backend/go/bin/
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.gitignore at line 18, The .gitignore entry "bin/" is too broad and will
ignore any bin/ anywhere; update the pattern to specifically target the Go
binary directory by replacing the unanchored "bin/" with the scoped path
"backend/go/bin/" (or, if you intentionally mean the repository-root bin
directory, replace it with "/bin/") so only the intended directory is ignored;
modify the .gitignore entry accordingly.

aiphsd-go

# Rust
target/
**/*.rs.bk

# Misc
.DS_Store
*.log
audit_log.txt
maintenance.log
69 changes: 33 additions & 36 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,63 +1,60 @@
# 🛡️ AI-Powered Hybrid Security Dashboard (AIP-HSD)
# 🛡️ AIP-HSD // UNIVERSAL POLYGLOT SENTINEL

![Version](https://img.shields.io/badge/version-v1.1.0-blue.svg)
![Status](https://img.shields.io/badge/status-enterprise--ready-brightgreen.svg)
![Build](https://img.shields.io/badge/CI--CD-modular-orange.svg)
![Release](https://img.shields.io/badge/deployment-GHCR--Native-blueviolet.svg)
![Architecture](https://img.shields.io/badge/Architecture-Polyglot--Universal-orange.svg)
![Packages](https://img.shields.io/badge/Release-Universal--Packages-blueviolet.svg)

**AIP-HSD** is an elite, self-evolving security intelligence ecosystem. It integrates real-time OSINT (Open Source Intelligence) with internal deep-telemetry to provide SOC-level insights, autonomous threat hunting, and automated remediation.
**AIP-HSD** is the world's most versatile AI-driven security dashboard. It is a full-spectrum intelligence platform implemented across every major programming language, allowing you to choose the stack that fits your organization's expertise and performance requirements.

---

## 🖥️ Modern HUD Interface
## 🌎 Choose Your Stack

### 🌐 Global Sentinel Map
High-precision, interactive world projection visualizing global threat vectors and regional hotspots.
AIP-HSD is available in multiple implementations. You can mix and match any Backend with any Frontend.

![Main Dashboard](https://lh3.googleusercontent.com/aida/ADBb0uiEcp0V-9oDjzOxFO6vuLgPN8sb2bivNeWL5lIfJtxBmA3L0n63jvkfxBbLm5YIp9SudY-HTEI6ysy-XRohlwiQ3dXdMyFsuah4DrsmhSDV5GY93tEnnkHMwfyvTLjmfX3zZ_vmrqL85M91lSTzr5XA2sE1tfgsAX2viSOUMe7uaD_aBokj7PXgWBAKOEIfrwTVS2sq6gf1MamcSSmnBiu7-fQkMsZ1i-Bo7CvM5rHrqkVUfhc66ffwZpo)

### 🤖 AI Query & Malware Reports
Advanced natural language interface for deep intelligence extraction and detailed behavioral malware analysis.
### ⚙️ Backends
| Language | Framework | Package / Link |
| :--- | :--- | :--- |
| **Python** | FastAPI | `pip install aiphsd-python` |
| **Node.js** | Express | `npm install aiphsd-backend-nodejs` |
| **Go** | Gin | `go get github.com/yourusername/aiphsd-go` |
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Placeholder yourusername should be replaced with actual repository path.

The Go package path contains a placeholder that users would copy verbatim. Update this to the actual GitHub repository path.

📝 Suggested fix
-| **Go** | Gin | `go get github.com/yourusername/aiphsd-go` |
+| **Go** | Gin | `go get github.com/abdulraheemnohri/AIP-HSD/backend/go` |
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
| **Go** | Gin | `go get github.com/yourusername/aiphsd-go` |
| **Go** | Gin | `go get github.com/abdulraheemnohri/AIP-HSD/backend/go` |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@README.md` at line 20, Replace the placeholder module path in the README
table entry so users can copy a working go get command: update the string `go
get github.com/yourusername/aiphsd-go` to the actual repository path (e.g., `go
get github.com/<actual-org-or-user>/aiphsd-go`) so the table row for Go / Gin
contains the real GitHub module path; ensure the change is made where the README
line with the exact backticked package string appears.

| **Rust** | Axum | `cargo install aiphsd-backend-rust` |

![AI Query Results](https://lh3.googleusercontent.com/aida/ADBb0uhUfLKdpnEQdoJBYKnENYAmPvUL2Gn2DU559ZA8e_JQvwuLtDqmaMkuIj-VzcOfXdF54YciX89AYoVkOIbtGvD_GE7r1H_HKdSHYTNZMTo_Gkxr7QaKXphI2r1xG4gL15z6-dzwCtPgKa3FxmuJIZ53T3naYD4RjaVF41W4PipXyTMTzDc7Lz4GZcieFRexhTBinTHJeyAPkXY9B_b1E62DUDdAj2dfcrxAoRLN-FnM7YYgDMXRY3hGKk4)
### 🖥️ Frontends
| Framework | Edition | Best For |
| :--- | :--- | :--- |
| **React-TS** | Enterprise | Complex, type-safe security HUDs. |
| **Next.js** | Modern | SSR-capable, ultra-fast analytics views. |
| **Static HTML** | Portable | Zero-dependency, lightweight deployments. |

---

## 🚀 Key Enterprise Features

- **🔄 GitHub Auto-Updater**: Automated platform lifecycle management via integrated GitHub Release API.
- **🏢 Multi-Tenant Core**: Strict data isolation for complex organizational hierarchies.
- **📈 Historical Trends**: D3.js powered visualization of long-term security metrics (30/90/365 days).
- **🧪 Malware Sandbox**: Behavioral analysis engine with MITRE ATT&CK mapping and risk scoring.
- **🛡️ Hardened Defense**: JWT-based authentication, RBAC, and centralized Audit Logging.
- **🧩 Polyglot Architecture**: High-performance core in **Rust**, native agents in **Go**, and AI logic in **Python**.
## 🪟 Windows Standalone Installer
For Windows users, we provide a unified **Universal Setup (.exe)**. During installation, you can select your preferred backend and frontend components, and the installer will configure the environment for you.

---

## ⚙️ Modular CI/CD Pipeline
Our GitHub Action workflows are segmented for maximum reliability and control:

| Workflow | Trigger | Description |
| :--- | :--- | :--- |
| **🚀 Windows Release** | Manual / Tag | Builds standalone `.exe` binaries with PyInstaller. |
| **🐧 Linux Release** | Manual / Tag | Generates statically-linked ELF binaries. |
| **🐳 Docker (GHCR)** | Manual / Tag | Pushes multi-arch images to GitHub Container Registry. |
| **🧪 Test Suite** | PR / Main | Executes full backend and intelligence functional tests. |
## 🚀 Key Multi-Stack Features
- **🔄 Universal AI Orchestrator**: Logic remains consistent across Python, Go, and Rust implementations.
- **📈 Polyglot Agent Network**: Unified telemetry via Go, C++, and Python agents.
- **🛡️ Hardened Security**: JWT & RBAC parity across all backend implementations.
- **🧪 Advanced Sandbox**: Behavior analysis logic ported for high-performance Rust and Node systems.

---

## 🚦 Deployment & Lifecycle
## 🚦 Getting Started (Universal)

### 🏁 Quick Start
### 🐳 Docker (Multi-Stack)
```bash
# Default (Python + React-TS)
docker-compose -f docker/docker-compose.yml up --build
```
Comment on lines +47 to 51
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check if there are multiple docker-compose files or backend selection mechanisms
fd -t f "docker-compose" --exec cat {}

Repository: abdulraheemnohri/AIP-HSD

Length of output: 528


🏁 Script executed:

# Find all docker-compose files
git ls-files | grep -i docker-compose

Repository: abdulraheemnohri/AIP-HSD

Length of output: 112


🏁 Script executed:

# Check if there are other docker files or backend-specific configurations
fd -t f "docker" -x file {} \; | head -20

Repository: abdulraheemnohri/AIP-HSD

Length of output: 175


🏁 Script executed:

# Check the Dockerfile to understand what backend it configures
cat docker/Dockerfile | head -50

Repository: abdulraheemnohri/AIP-HSD

Length of output: 701


🏁 Script executed:

# Read the full README around the Docker section for context about backends
head -80 README.md | tail -40

Repository: abdulraheemnohri/AIP-HSD

Length of output: 1490


🏁 Script executed:

# Check the root-level docker-compose.yml
cat docker-compose.yml 2>/dev/null || echo "File not found or error"

Repository: abdulraheemnohri/AIP-HSD

Length of output: 50


🏁 Script executed:

# Search for all docker-compose files including variants
fd -t f "docker-compose" -o "docker-compose*"

Repository: abdulraheemnohri/AIP-HSD

Length of output: 217


🏁 Script executed:

# Check for other backend-specific docker files
fd -t f "Dockerfile*" docker/

Repository: abdulraheemnohri/AIP-HSD

Length of output: 85


🏁 Script executed:

# Check root docker-compose.yml with file size
ls -lah docker-compose.yml && echo "---" && wc -l docker-compose.yml

Repository: abdulraheemnohri/AIP-HSD

Length of output: 157


🏁 Script executed:

# Search for docker-compose files properly
fd -t f "docker-compose"

Repository: abdulraheemnohri/AIP-HSD

Length of output: 112


🏁 Script executed:

# Search for any Dockerfile variants
fd -t f "Dockerfile"

Repository: abdulraheemnohri/AIP-HSD

Length of output: 85


🏁 Script executed:

# Check if there are separate backend directories with their own configs
fd -t d "backend" | head -10

Repository: abdulraheemnohri/AIP-HSD

Length of output: 76


🏁 Script executed:

# Check backend directory structure to understand available backends
ls -la backend/

Repository: abdulraheemnohri/AIP-HSD

Length of output: 403


Docker setup only supports Python backend despite README advertising multi-stack Docker support.

While the README claims "Docker (Multi-Stack)" capability and mentions Python, Go, Node.js, and Rust backends, the actual Docker configuration (docker/docker-compose.yml and docker/Dockerfile) only builds and runs the Python backend with React-TS frontend. The backend code for Go, Node.js, and Rust exists in backend/, but users attempting to select alternative backends via Docker will find no corresponding compose configurations or Dockerfiles. Either add docker-compose files for each backend or clarify in the documentation that Docker currently supports only the Python backend.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@README.md` around lines 47 - 51, The README's "### 🐳 Docker (Multi-Stack)"
section advertises multi-backend Docker support but the repo only builds the
Python backend; update either the docs or add missing compose/Dockerfile
entries. Fix option A: modify the README text under "### 🐳 Docker
(Multi-Stack)" to clearly state that Docker currently supports only the Python +
React-TS stack and list steps to run other backends manually. Or fix option B:
add Docker assets that actually support other backends by creating per-backend
Dockerfiles and services in docker-compose (reference the existing
docker/docker-compose.yml and docker/Dockerfile as templates) to build/run
Go/Node/Rust backends located in backend/* and update README to document how to
select each backend when running docker-compose.


### 🆙 Auto-Update Logic
The platform includes an internal `GitHubAutoUpdater` module. To manually trigger an update to the latest release:
### 🛠️ Manual Build (Example: Go Backend + Static HUD)
```bash
curl -X POST http://localhost:8000/api/updater/apply -H "Authorization: Bearer <TOKEN>"
cd backend/go && go build -o aiphsd-go cmd/main.go && ./aiphsd-go
# Open frontend/html-static/index.html in browser
```

---
*Architected by Jules // Powered by Global Security Intelligence.*
*Architected by Jules // The Universal Polyglot Sentinel.*
30 changes: 30 additions & 0 deletions backend/go/cmd/main.go
Original file line number Diff line number Diff line change
@@ -0,0 +1,30 @@
package main

import (
"github.com/gin-gonic/gin"
"net/http"
)

func main() {
r := gin.Default()

api := r.Group("/api")
{
api.GET("/threats", func(c *gin.Context) {
c.JSON(http.StatusOK, []gin.H{
{"id": 301, "name": "Go-Exploit-Delta", "risk_score": 88.2, "type": "exploit"},
})
})
api.GET("/alerts", func(c *gin.Context) {
c.JSON(http.StatusOK, []gin.H{
{"id": 401, "title": "Go Alert: Kernel Anomaly", "severity": "critical"},
})
})
}
Comment on lines +11 to +23
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Missing /api/compliance and /api/ai endpoints for feature parity.

The Node.js backend exposes /api/compliance/status and /api/ai/query, but the Go backend only has /api/threats and /api/alerts. This breaks the stated goal of feature parity across polyglot implementations.

Would you like me to generate the Go implementations for these missing endpoints?

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@backend/go/cmd/main.go` around lines 11 - 23, Add the missing
/api/compliance/status and /api/ai/query routes to the existing router group
created by r.Group("/api"); implement handlers (similar to the existing inline
handlers for /threats and /alerts) that return http.StatusOK JSON payloads
matching the Node.js responses: for /api/compliance/status return a JSON object
with compliance status fields (e.g., overall status, last_scanned, passing
boolean) and for /api/ai/query accept a POST or GET as in Node.js and return a
JSON response containing a query and ai_response fields; add these routes in the
same block where api.GET("/threats", ...) and api.GET("/alerts", ...) are
defined so they live under the same router group and use gin.Context to write
the JSON response.


r.GET("/", func(c *gin.Context) {
c.JSON(http.StatusOK, gin.H{"message": "AIP-HSD Go Universal API is live."})
})

r.Run(":8000")
}
8 changes: 8 additions & 0 deletions backend/go/go.mod
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
module github.com/yourusername/aiphsd-backend-go

go 1.21

require (
github.com/gin-gonic/gin v1.9.1
github.com/google/uuid v1.3.0
)
15 changes: 15 additions & 0 deletions backend/nodejs/package.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
{
"name": "aiphsd-backend-nodejs",
"version": "1.0.0",
"main": "src/index.js",
"scripts": {
"start": "node src/index.js"
},
"dependencies": {
"express": "^4.18.2",
"cors": "^2.8.5",
"jsonwebtoken": "^9.0.1",
"bcryptjs": "^2.4.3",
"dotenv": "^16.3.1"
}
}
24 changes: 24 additions & 0 deletions backend/nodejs/src/index.js
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
const express = require('express');
const cors = require('cors');
const threatsRouter = require('./routes/threats');
const alertsRouter = require('./routes/alerts');
const complianceRouter = require('./routes/compliance');
const aiRouter = require('./routes/ai');

const app = express();
app.use(cors());
app.use(express.json());

app.use('/api/threats', threatsRouter);
app.use('/api/alerts', alertsRouter);
app.use('/api/compliance', complianceRouter);
app.use('/api/ai', aiRouter);

app.get('/', (req, res) => {
res.json({ message: "AIP-HSD Node.js Universal API is live." });
});

const PORT = process.env.PORT || 8000;
app.listen(PORT, () => {
console.log(\`Node.js Backend running on port \${PORT}\`);
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
python - <<'PY'
from pathlib import Path
p = Path("backend/nodejs/src/index.js")
for i, line in enumerate(p.read_text(encoding="utf-8").splitlines(), 1):
    if 21 <= i <= 24:
        print(i, repr(line))
PY

Repository: abdulraheemnohri/AIP-HSD

Length of output: 219


Remove backslashes from template literal backticks and fix interpolation syntax.

Line 23 has escaped backticks in the template literal string, causing a JavaScript parse error that prevents the server from starting. The backticks and interpolation syntax must be unescaped.

Fix
-  console.log(\`Node.js Backend running on port \${PORT}\`);
+  console.log(`Node.js Backend running on port ${PORT}`);
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
console.log(\`Node.js Backend running on port \${PORT}\`);
console.log(`Node.js Backend running on port ${PORT}`);
🧰 Tools
🪛 Biome (2.4.10)

[error] 23-23: unexpected token \

(parse)


[error] 23-25: unterminated template literal

(parse)

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@backend/nodejs/src/index.js` at line 23, The console.log call is using
escaped backticks which breaks the template literal; update the console.log
invocation that prints the PORT (the line referencing console.log and the PORT
variable) to use an unescaped template literal with proper interpolation
(${PORT}) instead of escaped backticks so the string parses correctly and the
server can start.

});
12 changes: 12 additions & 0 deletions backend/nodejs/src/routes/ai.js
Original file line number Diff line number Diff line change
@@ -0,0 +1,12 @@
const express = require('express');
const router = express.Router();

router.post('/query', (req, res) => {
res.json({
query: req.body.query_text,
ai_response: "Node.js AI Module: Analysis identifies pattern match in Segment 4.",
confidence: 0.92
});
});
Comment on lines +4 to +10
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Missing input validation for query_text.

If req.body is empty or query_text is missing, the response will contain query: undefined. Add basic validation to return a 400 error for invalid requests.

🛡️ Proposed fix
 router.post('/query', (req, res) => {
+  const { query_text } = req.body || {};
+  if (!query_text) {
+    return res.status(400).json({ error: "query_text is required" });
+  }
   res.json({
-    query: req.body.query_text,
+    query: query_text,
     ai_response: "Node.js AI Module: Analysis identifies pattern match in Segment 4.",
     confidence: 0.92
   });
 });
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@backend/nodejs/src/routes/ai.js` around lines 4 - 10, The POST /query route
handler (router.post('/query', (req, res) => { ... })) lacks input validation
and will return query: undefined when req.body or req.body.query_text is
missing; update this handler to check that req.body exists and that
req.body.query_text is a non-empty string, and if not respond with
res.status(400).json({ error: 'query_text is required' }) (or similar) before
building the success response so only valid requests reach the AI response
logic.


module.exports = router;
10 changes: 10 additions & 0 deletions backend/nodejs/src/routes/alerts.js
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
const express = require('express');
const router = express.Router();

router.get('/', (req, res) => {
res.json([
{ id: 201, title: "Node Alert: Unusual Traffic", severity: "high", message: "Detected on Segment 4", timestamp: new Date() }
]);
});

module.exports = router;
14 changes: 14 additions & 0 deletions backend/nodejs/src/routes/compliance.js
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
const express = require('express');
const router = express.Router();

router.get('/status', (req, res) => {
res.json({
timestamp: new Date(),
standards: [
{ name: "ISO 27001", status: "COMPLIANT", score: 99.1 },
{ name: "PCI-DSS", status: "VULNERABLE", score: 68.5 }
]
});
});

module.exports = router;
10 changes: 10 additions & 0 deletions backend/nodejs/src/routes/threats.js
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
const express = require('express');
const router = express.Router();

router.get('/', (req, res) => {
res.json([
{ id: 101, name: "Node-Ransom-Alpha", type: "ransomware", source: "OSINT", risk_score: 92.5, location: "USA", timestamp: new Date() }
]);
});
Comment on lines +4 to +8
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Threat response schema inconsistent with Go backend.

The PR states "feature parity across all polyglot backend implementations," but the Node.js /api/threats response includes fields (source, location, timestamp) that the Go backend omits (see backend/go/cmd/main.go:13-17). This inconsistency will cause issues if frontends are enhanced to consume specific fields.

Align all backends on a common schema, or define a shared schema contract.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@backend/nodejs/src/routes/threats.js` around lines 4 - 8, The Node.js route
handler router.get('/') is returning extra fields (source, location, timestamp)
that don't match the Go backend schema; update the response in the router.get
callback to match the agreed canonical threat schema used by the Go
implementation (include only the same fields such as id, name, type, risk_score)
or replace the hardcoded object with a shared schema/contract, removing
source/location/timestamp so the NodeJS response aligns with the Go backend's
shape.


module.exports = router;
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
10 changes: 10 additions & 0 deletions backend/python/setup.py
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
from setuptools import setup, find_packages

setup(
name="aiphsd-python",
version="1.1.0",
packages=find_packages(),
install_requires=[
"fastapi", "uvicorn", "pydantic", "sqlalchemy", "python-jose", "passlib"
],
Comment on lines +7 to +9
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

What version pinning strategy is currently recommended for setuptools install_requires in published Python packages, and what compatible version ranges should be used for FastAPI + Pydantic + SQLAlchemy + python-jose + passlib?

💡 Result:

The currently recommended version pinning strategy for setuptools install_requires in published Python packages is to specify minimal lower bounds (e.g., >=X.Y.Z) with known upper bounds only when necessary to avoid breaking changes (e.g., >=X.Y.Z,<X+1), rather than pinning to exact versions (e.g., ==X.Y.Z). Exact pinning is discouraged as it is overly restrictive and prevents users from benefiting from dependency upgrades and bug fixes. Pinning is reserved for requirements.txt files for reproducible environments, while install_requires should declare abstract minimal runtime requirements per the Python Packaging User Guide and setuptools documentation. For the specified packages, compatible version ranges suitable for install_requires (assuming a modern FastAPI app as of 2026 with Pydantic v2, SQLAlchemy 2.0+ async support) are: - FastAPI: >=0.135.0,<1.0.0 (current latest ~0.135.x; follows semver-like pinning to next major) - Pydantic: >=2.9.0,<3.0.0 (FastAPI requires >=2.9.0; compatible release up to next major) - SQLAlchemy: >=2.0.0 (stable 2.0 series; no upper bound needed as it's stable/evolving) - python-jose: python-jose[cryptography]>=3.3.0 (latest 3.5.0; common FastAPI JWT extra; >=3.3.0 safe) - passlib: passlib[bcrypt]>=1.7.0 (stable 1.7.4; bcrypt extra common for FastAPI security) Example in pyproject.toml or setup.cfg: dependencies = [ "fastapi>=0.135.0,<1.0.0", "pydantic>=2.9.0,<3.0.0", "sqlalchemy[asyncio]>=2.0.0", "python-jose[cryptography]>=3.3.0", "passlib[bcrypt]>=1.7.0", ] These ranges allow bug fixes/patches while preventing major breaking changes, aligned with official packaging guidance. Test your specific versions, as compatibility depends on app code (e.g., SQLAlchemy async requires extras).

Citations:


Add version constraints to all dependencies using semantic versioning.

Line 8 declares unbounded dependencies, which prevents reproducible installs and may introduce breaking changes when users install the package. Use semantic versioning ranges (e.g., >=X.Y.Z,<X+1) for each dependency to allow patches and minor updates while preventing major breaking changes.

Example:

install_requires=[
    "fastapi>=0.135.0,<1.0.0",
    "uvicorn>=0.27.0,<1.0.0",
    "pydantic>=2.9.0,<3.0.0",
    "sqlalchemy>=2.0.0",
    "python-jose[cryptography]>=3.3.0",
    "passlib[bcrypt]>=1.7.0",
],
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@backend/python/setup.py` around lines 7 - 9, The install_requires list in
setup.py currently pins no versions; update the install_requires entry to use
semantic version ranges for each package (e.g., for functionally critical deps
in the install_requires array: "fastapi", "uvicorn", "pydantic", "sqlalchemy",
"python-jose", "passlib") so installs are reproducible — use >=MINOR.PATCH and a
<MAJOR upper bound (for example fastapi>=0.135.0,<1.0.0; uvicorn>=0.27.0,<1.0.0;
pydantic>=2.9.0,<3.0.0), include appropriate extras where used (e.g.,
python-jose[cryptography], passlib[bcrypt]), and choose sensible lower bounds
for sqlalchemy (or other libs) while preventing automatic major version
upgrades; update the install_requires list accordingly.

)
11 changes: 11 additions & 0 deletions backend/rust_server/Cargo.toml
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
[package]
name = "aiphsd-backend-rust"
version = "0.1.0"
edition = "2021"

[dependencies]
axum = "0.7"
tokio = { version = "1.0", features = ["full"] }
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"
tower-http = { version = "0.5", features = ["cors"] }
31 changes: 31 additions & 0 deletions backend/rust_server/src/main.rs
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
use axum::{
routing::{get, post},
Json, Router,
};
use serde::{Deserialize, Serialize};
use tower_http::cors::CorsLayer;

#[derive(Serialize)]
struct Threat {
id: u32,
name: String,
risk_score: f64,
}

#[tokio::main]
async fn main() {
let app = Router::new()
.route("/", get(|| async { Json(serde_json::json!({ "message": "AIP-HSD Rust Universal API is live." })) }))
.route("/api/threats", get(get_threats))
.layer(CorsLayer::permissive());
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

CorsLayer::permissive() is overly permissive for production.

This allows any origin with any method and headers. While acceptable for local development, this should be restricted in production deployments to prevent CSRF and other cross-origin attacks.

🔒 Suggested approach for production-ready CORS
use tower_http::cors::{Any, CorsLayer};
use http::Method;

let cors = CorsLayer::new()
    .allow_origin(["http://localhost:3000".parse().unwrap()])
    .allow_methods([Method::GET, Method::POST])
    .allow_headers(Any);

Consider making allowed origins configurable via environment variables.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@backend/rust_server/src/main.rs` at line 20, Replace the overly-broad
CorsLayer::permissive() usage with a restricted CorsLayer configuration: create
a CorsLayer via CorsLayer::new(), call allow_origin(...) with a controlled list
of origins (parsed from env vars), call allow_methods(...) with only needed
methods (e.g., Method::GET, Method::POST) and call allow_headers(Any) or specify
headers as required; update the server setup that currently uses
CorsLayer::permissive() to use this new cors variable and ensure origin list is
read from configuration/environment so production origins are not wide-open.


let listener = tokio::net::TcpListener::bind("0.0.0.0:8000").await.unwrap();
println!("Rust Backend running on 0.0.0.0:8000");
axum::serve(listener, app).await.unwrap();
}

async fn get_threats() -> Json<Vec<Threat>> {
Json(vec![
Threat { id: 501, name: "Rust-ZeroDay-Alpha".to_string(), risk_score: 99.9 },
])
}
Loading