| Area | What it is for |
|---|---|
| Content | Vendor packs, field guides, governance content, and reusable evidence material. |
| Detections | Detection rules, defensive analytics, signal logic, and security queries. |
| Docs | Design notes, standards, implementation notes, and operating guidance. |
| Projects | Project workspaces, prototypes, and active experiments. |
| Research | Research material, malware analysis, white papers, and experiments. |
| Scripts | Automation helpers, validators, collectors, and repeatable operations. |
| Templates | Reusable documentation, reporting, and delivery templates. |
| Workbooks | Dashboard, workbook, and visual analytics artifacts. |
| Security Policy | Security reporting and supported vulnerability disclosure path. |
| License | Repository usage terms and attribution requirements. |
Security research, detection engineering, data tooling, automation, and experiments.
Built for receipts, not vibes. The robot is friendly. The pipeline is not.
This is the public Zeid Data research lab for security-focused software, analytics workflows, detection engineering, malware research notes, automation scripts, templates, white papers, and workbook artifacts.
The operating model is simple:
collect -> normalize -> analyze -> validate -> document -> ship with receipts
If a tool cannot explain what it read, what it changed, and what evidence supports the output, it gets escorted back to the lab bench by a disappointed robot.
Evidence first
Outputs should be traceable to inputs. Prefer structured results, stable schemas, reproducible runs, and documented assumptions over hand-wavy "seems fine" engineering.
Defensive and authorized
Security material in this repository is intended for authorized research, defensive testing, privacy review, detection engineering, and audit workflows. It is not a guide for credential theft, unauthorized access, stealth, evasion, abuse, or bypassing protections.
Automation with guardrails
Scripts should be non-interactive where possible, explicit about inputs and outputs, safe to run in controlled environments, and clear about failure modes. If a command can break something, it should say what it touches before it touches it.
Robot humor, human accountability
The lab voice can be weird. The engineering cannot be. Jokes are allowed. Fake claims are not.
Start by inspecting the area that matches your goal.
git clone https://github.com/zeiddata-dev/Research.git
cd Research
find . -maxdepth 2 -name README.md -print | sort
find . -maxdepth 2 -type f \( -name 'requirements*.txt' -o -name 'pyproject.toml' -o -name 'package.json' -o -name 'Makefile' \) -print | sortThen read the module-level documentation before running tools. Different folders may have different requirements, assumptions, and safety boundaries.
Good additions should include:
- A clear purpose.
- Safe default behavior.
- Public-safe documentation.
- Reproducible commands or tests where applicable.
- Machine-readable output when the artifact is meant for automation.
- Explicit assumptions and limits.
- No secrets, tokens, private URLs, private logs, or personal data.
Do not open public issues for sensitive vulnerabilities. Use the repository security policy for reporting guidance: SECURITY.md.
Security research in this repo should remain authorized, defensive, and privacy-preserving. The lab does not need surprise crimes in the test suite.
This repository is not the special .github profile repository, so the reusable profile README draft lives here:
Copy that file into .github/profile/README.md in the Zeid Data GitHub profile repository when ready.
- Keep links real.
- Keep examples sanitized.
- Keep claims tied to repo contents.
- Keep generated assets local when practical.
- Keep the robot jokes, but do not let them drive architecture.
This repository uses the MIT License unless a subfolder states otherwise. See LICENSE.md.