Building 70 Projects ranging from beginner to advanced so anyone can — learn from, build upon, use as a reference, or even copy directly. Gamified Cybersecurity learning 👇
Security teams need a quick way to ingest raw logs, run them through ML models, and expose results via a lightweight API. Existing turnkey solutions are either too generic, require a lot of configuration, or lack an end‑to‑end test harness. This project delivers a ready‑made pipeline that takes log files, normalises them, runs an autoencoder and random forest model, and surfaces alerts through a FastAPI service.
What This Does
The ai‑threat‑detection folder contains a full backend and a lightweight React frontend.
backend/app/__main__.py starts the FastAPI server.
backend/app/main.py wires routes (/api/ingest, /api/alerts, /api/threats) to the service layer.
backend/app/services/threat_service.py orchestrates model inference (ml/autoencoder.py, ml/train_classifiers.py) and stores alerts in Redis (core/redis_manager.py).
frontend/src/App.tsx consumes the API via hooks in frontend/src/api/hooks/… and displays a dashboard.
The repo also ships with a Docker compose file (compose.yml) that builds both sides and runs them in isolated containers.
main.py imports app/api/*.py where each route handler calls a service.
The /api/ingest handler reads a log file, passes it to core/ingestion/parser.py → pipeline.py.
pipeline.py feeds data to ml/autoencoder.py (ONNX inference) and ml/train_classifiers.py (RF).
Results are wrapped in schemas/*.py and returned.
Alerts are queued into Redis via core/redis_manager.py; a background task in main.py pulls them and pushes over WebSocket (api/websocket.py).
The frontend starts on frontend/index.html. src/api/hooks/useAlerts.ts opens a WebSocket at /ws/alerts and updates the UI. The entire flow from ingestion to alert display requires three main hops: request → service → model → Redis → WebSocket → UI.
How To Use It
# clone
git clone https://github.com/moses-y/Cybersecurity-Projects
cd Cybersecurity-Projects/PROJECTS/advanced/ai-threat-detection
# build & run containers
docker compose up --build
The backend listens on http://localhost:8000. The frontend is served at http://localhost:3000. Environment variables are defined in .env.example; copy it to .env and adjust if needed.
Real‑World Use
Deploy the stack in a SOC for continuous log monitoring. Ingest logs from syslog or docker‑compose into /api/ingest; the service returns a JSON payload of anomaly scores. Alerts are pushed to a SIEM via the WebSocket or stored in Redis for later batch export.
Code Health & Issues
Security – Low: secret‑shaped paths found in PROJECTS/intermediate/credential‑rotation‑enforcer/src/cre/rotators/aws_secrets.cr, PROJECTS/intermediate/docker‑security‑audit/internal/rules/secrets.go, PROJECTS/intermediate/docker‑security‑audit/tests/testdata/compose/bad‑secrets.yml.
Test coverage – 772 test files, many targeting the FastAPI endpoints and ML inference.
CI/CD – .github/workflows/*.yml deploys the API‑rate‑limiter and other subprojects; no workflow for the AI‑threat‑detection stack.
Documentation – 101 doc files, but the AI‑threat‑detection README is minimal; detailed API docs are missing.
License – LICENSE present, MIT.
The dependency graph shows a clear separation: backend relies on uvicorn, fastapi, onnxruntime, redis, while frontend depends on vite, react, typescript. The only cyclic dependency is between app/main.py and services/threat_service.py, which is acceptable given the limited scope.
The Bottom Line
The AI threat detection stack is a solid, end‑to‑end prototype that demonstrates how to combine log ingestion, ML inference, and real‑time alerting. It is well‑structured, test‑heavy, and Docker‑ready, but the lack of CI for this specific project and sparse documentation are the main gaps. It is suitable for teams wanting a quick proof of concept or a teaching tool, but production use would require adding comprehensive API docs, tightening secret handling, and integrating a CI pipeline.
What the analyser found
Deployment readiness
6/7
✓Container image
✓CI pipeline
✓Lockfile committed
✓Test suite
✓README
✓License
✗No committed secrets
Composition
4,204 files
Go661
Python599
Markdown384
TypeScript302
TSX241
SCSS203
ReactDjangoFlaskFastAPIExpressRailsDockerONNX
Module dependencies
The 10 most depended-upon modules of 840, from static import analysis. Red outline marks a module in an import cycle.
5 of 39 declared dependencies are a major version behind. Resolved 39 of 39 against the registry.
Package
Declared
Latest
Behind
typescript
~5.9.3
7.0.2
2 major
redis
>=7.1.1
8.1.0
1 major
@types/node
^25.1.0
26.2.0
1 major
@vitejs/plugin-react
^5.1.2
6.0.5
1 major
vite
npm:rolldown-vite@7.3.1
8.2.1
1 major
Findings
LowSecret-shaped paths present; the code-health audit confirms or clears them PROJECTS/intermediate/credential-rotation-enforcer/src/cre/rotators/aws_secrets.cr, PROJECTS/intermediate/docker-security-audit/internal/rules/secrets.go, PROJECTS/intermediate/docker-security-audit/tests/testdata/compose/bad-secrets.yml
Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.
critical1
high4
medium4
low1
Rotate the credentials in the committed environment filecritical3 occurrences
A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.
Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.
An unlocked range means the artifact you tested and the artifact you ship can contain different transitive code, so a malicious patch release reaches production with no diff.
Fix: Run the package manager once and commit the generated lockfile.
Remove the committed .env and rotate what it holdshigh2 occurrences
A tracked .env is the most common route for a working key to reach a public clone, and it is the file the app actually loads, so the value is usually live.
Fix: git rm --cached the file, add it to .gitignore, rotate every credential it names, commit a .env.example with empty values.
Remove continue-on-error from steps that gate correctnesshigh
.github/workflows/lint.yml
line 413 on a correctness step
A failing test suite reports a green check, which is precisely the path this audit exists to close.
Fix: Delete continue-on-error, or move a genuinely advisory step into a separate non-required job.
An untagged or mutable base means today's build and last month's contain different libc and a different CVE set, with no record of which shipped.
Fix: Use image:tag@sha256:<digest> and enable Dependabot's docker ecosystem.
Gate pull requests on a dependency vulnerability scanmedium
.github/workflows
no dependency scan in CI
This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.
Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.
Set persist-credentials: false on checkoutmedium
.github/workflows/lint.yml
checkout keeps the token, then dependencies are installed
The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.
Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.
A process running as root in the container is root against every mounted volume, and it turns any container escape or writable-mount mistake from a contained problem into a host one.
Fix: Create an unprivileged user, chown what it needs, and end the Dockerfile with USER.
Set timeout-minutes on the workflow jobslow4 occurrences
.github/workflows/lint.yml
4 workflow(s) declare no job timeout
A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.
Fix: Add timeout-minutes with a realistic bound to each job.
Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.