AR-04 · SECURITY RESEARCHSecurity Research Archive
Security Research Archive
This is where security findings would be filed. None are, and the page says so rather than filling the space.
- Sheet
- AR-04 · Security
- Filed findings
- 0
- Evidenced
- 5 claims, all indexed
- Not claimed
- 7 entries
01Standing
What this archive can evidence about security is a wargame worked in public, a learning platform built to teach it, and two security decisions taken inside that platform’s own code. Everything else on this page is a boundary or a denial.
A security archive that holds no findings can still be honest about why. Everything below is either a pointer to evidence that lives in another part of this site, or a statement of something this archive does not hold. Nothing here is a summary of work you cannot go and check.
02What the evidence supports
Five claims, each with the artifact it rests on and where to check it. The work itself is filed in the field notebook and the workshop; this is the index to it, not a second copy.
| Claim | Basis | Evidence | Filed in |
|---|---|---|---|
| Worked OverTheWire Bandit, levels 0 to 13 | Verified | 19 commits across six days, 13 to 20 August 2026, in the cyber-security repository. Each level has its own written note; the log records what each one turned on. | Field log |
| Built a cybersecurity learning platform | Verified | YushaCyber — a Flask application of fourteen registered blueprints, carrying 48 test files. It runs locally and in Docker; it is not deployed and has no users. | YushaCyber |
| Authored graded lab content on web-application attack classes | Verified | SQL injection, cross-site scripting, CSRF and file-upload modules inside YushaCyber, each with its own test file. Writing a test for a lab forces the lab to have a correct answer. | YushaCyber |
| Authored graded lab content on networking | Partly verified | Five modules — fundamentals, reconnaissance, troubleshooting, topology and an HTTP deep dive — each with its own test file. The first-hand part is SSH, hosts and ports from Bandit 0; the rest is content written, not networks operated. | Register of subjects |
| Applied two security decisions in the platform’s own code | Verified | CSRF protection registered globally through Flask-WTF rather than per form, and rendered markdown sanitised with bleach against an explicit tag-and-attribute allow-list — because lesson and challenge content is markdown, which makes the viewer an injection surface. | YushaCyber |
03Simulated, not real
The most overstatable thing in any security record is tooling. A subject list containing nmap and Wireshark reads as scanning and capturing. What exists here is a simulator, written so a mission could be graded. Each entry states what was exercised and what was not.
- Port scanning
The flags -p-, -sn, -sV, -sU, -sT, -O and -Pn were exercised against a simulated network written for grading, with filtered ports, a host that drops ICMP, and an OS guess.
No scan of a real network is recorded anywhere in this archive.
- Packet analysis
A packet lab, plus the capture, filter, follow and packets commands in the simulated terminal, behind a 536-line test file.
No capture of my own is published.
- Capture the flag
YushaCyber’s CTF arena has a schema behind it — challenge categories, challenges, per-user solves and staged hints — and authored challenges to fill it.
That is an arena built, not a competition entered. No placement, ranking or team result exists.
- The AI mentor
A chat endpoint in front of a provider interface, with OpenAI and Anthropic implementations and a mock. It needs a key in the environment; without one the feature reports itself unavailable.
Nothing about it runs locally and nothing about it is trained here. It is a client, not a model.
04Not claimed
Checked against every repository in M08 rather than assumed. On a security page the absent credentials are the ones a reader most needs stated, because a tool list implies all of them.
- No certification, and no completed course.
- No CTF placement, ranking or team result.
- No engagement, client, or authorised test of anyone else’s system.
- No CVE, disclosure, advisory or report.
- No vulnerability found in software belonging to someone else.
- No professional security employment, and no years-of-experience figure.
- No proficiency level, score or self-rating anywhere on this site.
05The filing standard
The register below is empty because of the schema, not because the page has not been written. These are the constraints an entry has to satisfy before it can appear.
- Every entry declares a discipline — defensive, detection, analysis, hardening, ctf or writeup. There is no general category to fall into.
- Anything touching a live target must record its authorisation: own-lab, ctf, authorised-engagement or public-disclosure. Absent that field, the work cannot be filed.
- The environment the work was carried out in is recorded on the entry itself, so a finding can never be read apart from where it was obtained.
- A CVE identifier is accepted only in the real CVE-YYYY-NNNN form, and only where a disclosed identifier actually exists. It is never inferred.
- Nothing renders as fact until a human has marked it verified; drafts are excluded from the build entirely.
06Filed findings
Holdings · 0 entries
No security work has been filed yet. The schema requires each entry to record the environment it was carried out in and its authorisation, so nothing can be published here without its context.